Hawkeye

As the controller already is a MIDIbox NG, you could also do it on the controller itself then without the need for another 32-bit core. You would "just" need a bit of customization of the NG code base, that essentially performs the following steps: a) detect a packet sent out to your VST - this could be registered e.g. using a new META description keyword in your control file b) if that packet was detected, set an internal timer, that is always set to 3 seconds (if a new packet was detected and the timer is already running). c) if the timer expires, manually send out the "closing" MIDI data packet on the correct interface (this is just one MIOS function call and a few lines of code). For this, you would need to do a bit of C coding and looking around in the codebase, e.g. to learn how the configuration mechanism (META config stuff) works. I am myself completely out of time since about 19 months :-), can't really help you out on this one, all i can say is, that it is easier than you might think, especially if you already did some hacking! Best regards and good luck! Peter

Does it also happen, if you use your computer, e.g. using MIDI-OX as a translation device (thus avoiding USB OTG): Minilab -> USB Computer -> MIDI-OX -> USB MIDI Out -> SEQ MIDI In ? If it also happens using this method (stream forwarding in MIDI-OX), you could eliminate USB OTG causing the problem. If it does happen using MIDI-OX, you could also log the MIDI stream and find out what packets are being sent to the MBSEQ. Test this first, i suspect though, that it works out fine this way and that the problem might be somewhere in the USB OTG implementation, or that some strange condition arising like hitting a memory limit or dropping a packet causes it. Do you use the newest SEQ version and a STM32F4 (more RAM available)? Many greets, Peter

Hi Chris, if you can't do it on your VST host with a software tool, it should be a quite easy task to do it in hardware with a bit of MIOS32 coding. If you have an old 32-bit core lying around, you could write the MIOS app mostly from looking at TK.'s great coding examples: http://ucapps.de/mios32_c.html Just attach that core module between your controller and your computer, scan for respective messages to the VST, and if you encounter one, set an internal timer to send out a "close midi packet" after three seconds. Many greets! Peter

Thanks a lot, guys! :-) Andy: dunno about the detuning of the Dom (it is just used for the bass) - but the little one wiggled on a few knobs of the A6 and I saved the patch, best random generator out there, hehe :-). Glad the Strymons are there, you can feed them the worst patches and the output usually still sounds somewhat reasonable :-). ilmenator: yes, more sunshine, please! :-) Many greets, Peter

Yo folks, no time for anything (the little one keeps us well-occupied), just dropping by to wish a happy midsummer time to all northern friends ;-) and to dump some (mostly) analog output to the forums ;-). It may sound a little melancholic, that's the feeling i sometimes get from such perfect summer days. Good to see some new developments on the MBSEQ and Core front happening, keep it up! Enjoy and many greets! Peter

Very nice!

Oh, ok! :-/ Does it also happen, if you disconnect all other external boards, in other words using just the core, a USB cable and the Mac? Does it happen on your other STM32F4 cores, too? It might be anything from the SD card going bad, to power stuff, a Mac update or even a bad USB cable :-). Sorry to be of probably little help :-). Many greets, Peter

Hi, are you by chance using windows for the MIOS Studio file uploads/downloads? In that case, it is probably caused by the Windows USB MIDI implementation, that chopped off a packet or so, MIOS then reports a timeout, aka. that an expected follow-up packet or so is missing. Can you try, if the same problem persists when using Linux or a Mac? If you are not using windows, i am clueless :-). Port 0x21 probably is the hex representation of the USB-MIDI port you are using. Many greets, Peter

That is indeed a great MIDIble with a very cool frontpanel! Hoping for a demo video at some point in time! :-) Many greets! Peter

Also check the shift register ICs (correct alignment and type), installing wrong or misaligned ICs might cause the behaviour you are experiencing. Please also check your resistor networks, as these are used to pull up the digital ins. Good luck! Peter

If you are buying a new core, go for the STM32F4, it has more RAM, that might offer some benefits to go for larger scripts or ngc configuration files. But, if you have an old LPC17 in stock, you could try it with that one as well. Methinks you would need a fairly extensive MBNG configuration (or some special hardware, that is only supported on STM32F4, like multicolor LEDs, see MBNG manual) to hit its memory limits, so if you are not going for many banks/pages and are not planning for a very complex configuration, it will do just as well. Performance (speed) will be completely fine on both cores. Many greets, Peter

Hi jaack, welcome to MIDIbox! :-) I fully agree with jjonas, MIDIbox SEQ is probably what suits best. If you have a bit of C programming knowledge, it should possible to create what is required - many features are available by the software already and would "just need to be broken out" to direct user interface controls, e.g. wire a tactile switch to randomize the track notes, add an encoder for modifying "humanizer" values and so on. Tempo randomization (within limits, e.g. +/- 10% up/down from the current speed) would also be a quite simple feature, or you could use non-randomized tempo controls, MBSEQ supports an encoder to directly set the BPM. You probably would not need a full control surface interface, just the core and a few DIN inputs (again: read ucapps.de! :-)) Many greets, Peter

Glad it works now and that you took my advice of filtering the power supply lines and adding the ferrite to the data lines. :-) I never experienced the problem, because i am using a 78S05 capable of delivering 2 Amps and that is easily enough for the MB6582 (in conjunction with a heatsink) - i know why i sometimes prefer linear vregs and why i recommended it in about 5 of our 10 total private messages we exchanged on this matter :-). It is also a nice footwarmer in winter. :-) @Altitude: this might explain your VFD troubles we had a few years back... the Recom switcher seems to be a bit RF-noisy and the VFDs seem to be easily distracted by that noise. In a non-midibox project also a few years back, i had severe troubles with another switching 780X replacement, that totally bombed the 433 MHz band, but that is another story... Many greets, Peter

The firmware is up and running, if you can see the MIDIbox in MIOS studio, so MIOS is running... While i am not certain, that the display controller is incompatible, I say, there is a fair chance. It might be something else though, e.g. some bad solder spots on the core. To "debug" this, I'd therefore highly recommend to obtain a real HD44780 for testing purposes (e.g. a cheap 16x2 for ~ 3$/EUR from ebay) - it will also serve you well for other MIDIboxes, that you build later on :-). If that testing display works, you will have to replace the (more expensive) 40x2 panels. Many greets, Peter

If you don't find another problem, and although it is not highly likely, it might indeed be the controller, that is not 100% compatible, especially in 4-bit mode.I just did a quick google check and have found a few issues with compatibility of the ST7066U here and there. You should be able to source a cheap real HD44780 (it does not even need to be 40x2) from ebay for a few dollars to test... Regarding the interrupted SD card transfers, i bet you are using windows, this is a common problem with the MIDI USB drivers under windows - for the moment, pull out the card, change the configuration file on your computer and plug it back in. Good luck and many greets, Peter

You're not alone! I have both and think the touch sensors are just a bit quicker. Work on the next version of the Programma with Andy will still take some more time, but you might be able to obtain the ELO boards and transparent encoders from him - they are awesome! Many greets, Peter

Thanks a lot J - and happy Easter! Many greets to snowy Stockholm! :-) Peter

Hola, it has been a while, but times have been busy :-) ...finally found a use for that dust-gathering Virus C :-) (its vocoder really is not half bad ;-)) Thanks for watching and listening! Peter

Just to make sure the encoder is not wobbly and there is more rotational resistance when turning. I have the alphas (14 modified + 1 menu encoder unmodified) running under the base MB6582 firmware, imho it needs no MIOS alteration because of physical modification, but these are just my 2 cents :). Jumping values can also be caused by low-quality encoders with bad contacts causing bad pulses (Bourns have received some bashing in this forum in the last years) and may not be related to the detention modification. Many greets, Peter

Correct me, if am wrong, but methinks the MIOS detention mode selection is all about selecting the encoding of the physical encoder pulses sent when turning the encoder - it has nothing to do with physically flattening the "detention lid" of the encoder, which will not alter the pulse encoding. That's why the same mode is used for all encoders in the program. Basically, flattening that lid just makes the encoders turn smoother - removing them is completely optional - if they are not flattened, you can feel the encoders "click into place" after every step. I can still highly recommend the Alpha encoders, after many years, they still work flawlessly - they are a bit expensive, but worth their money :-). Many greets, Peter

Ok, TK. just fixed the problem, the mailserver is up and running again. The problem most likely occured during the last security upgrade process - all should be working again now! Many greets and have a great weekend! Peter

Managed to contact TK., we will have to delay fixing it until the weekend though, but we are looking into it! Many greets! Peter

Thanks for the information, i just sent TK. an additional email about it, because most likely, the "@TK." forum notification also did not get sent via email. Unfortunately, for the moment i cannot log in to the physical server to check it out, but if TK. grants me access rights again, i can have a look. A possibility is the missing DNS reverse resolver entry for the midibox.org IP, thus those emails might be rejected by most mail servers due to spam filtering. Many greets, Peter

A small side note: don't wire up the encoders in matrix configuration. The normal encoder pulses will be high-speed and may not be "caught" by the reduced sampling rate of an input matrix leading to erratic encoder behaviour. At least that is my latest tech info, please correct me, if i am wrong :-). No problem on the LED output side, though, 8x8 matrices are great with low-power LEDs. This also drops your estimated current consumption a lot, a single LED will then not consume 20mA, only 1/8th of that, because of the reduced duty cycle. Many greets, Peter

Yes, modern switchers are safe enough, if you do it right! :-) If you have any doubts about modifying already built MB6582s (yes, some things can definitely go wrong there!), better think of either a new external PSU with protection, that is otherwise identical to the C64 PSU (and which has high-quality high frequency switchers to avoid noise) or a protective ciruit after the old C64 PSU, e.g. a crowbar protection circuit with a fuse, that will protect against the critical case of the ancient 5V vreg going haywire. Reverse polarity protection: best with a high-current diode directly next to the input power socket. Undervoltage: no problem in the MB6582 context Overvoltage: should be no problem until a quite high DC voltage (e.g. 36V) is reached for most switchers, the input filter cap will usually blow first and give an audiovisual feedback of something going wrong ;-). Many greets, Peter