When sending many CCs to the E1 right after another (more than a hundred, to update the values of a complex preset), I noticed that some of the CCs sent are ignored by the E1, and sometimes even misinterpreted. E.g. an RPN is reported where CC is sent
This problem disappears when waiting for 10 ms after sending each CC. Looking at the logs it appears that incoming 14bit CCs (that are always mapped on CC parameter number 0…31) are processed first, even if 7bit CCs are sent earlier. And it seems (but havent thoroughly checked) that the bug happens when sending CCs to the E1 over several different MIDI channels (note that the log messages that the E1 generates do not mention the MIDI channel)
I believe as well you need to build in some delay between each message, especially if thie midi source is a fast machine like a modern PC. Try to go down to 2 or 3 ms instead of 10. That might be sufficient i f no other traffic is around.
If you have control over the multiple channels sending MIDI data at the same time, then there’s two things to try:
make them send the MIDI data one after the other (first channnel 1, then channel 2…)
or else make the delay variable, ie. use 3 ms if one device is tranmitting , but use 23= 6 ms if both are transmitting at the same time, 33 = 9ms if three devices are in play etc…
@martin at what conditions might the E1 be unable to process all incoming MIDI data?
I’ll try to reduce the delay a bit more in a later version. Right now my main concern is code stability, and fine-tuning the controls on the E1 (value display mainly).
And I need to think about how to improve performance when switching between several devices/effects frequently. (Uploading presets does take some time even when using the fast, external, mode so perhaps some kind of caching as suggested by @flyweight is necessary after all.)
Back in the workshop. I am going to add extra logging so that I can see the channel info for these messages and will try to put the MIDI inputs under the stress.