I just got my V2 unit (boy, is it beautifully made!), flashed the firmware to 0.13, and started some performance tests. I’m seeing a somewhat unexpected behavior and thought I’d mention it now while I continue to explore/troubleshoot. (This is using C++ and RtMidi 4.0.0, Windows, USB connection).
I’ve run a few tests but I’ll just describe a simple one:
Every 250 milliseconds I’m sending six alternating 127 and 0-velocity notes to blink a column of six digital buttons. Since that’s only 24 MIDI messages per second I wouldn’t expect to be close to the bandwidth limit. I’m not using any fancy timing tricks, but it’s still quite regular when I leave it alone. So far, so good.
However, when I turn a rotary encoder on the unit at even a medium speed, the blinking immediately becomes irregular. I’m not receiving and re-sending the encoder messages–this is just its internal update.
Slower blink speeds reduce this behavior, but even at 500ms (12 note updates/second sent to the unit) I notice it, although it’s more subtle.
I’ve haven’t tried all configurations, by any means, but setting the feedback mode to LOCAL doesn’t seem to help, and it seems to behave the same with the different encoder modes (fill, spot, etc.)
The strangest thing is that this happens even when I configure the controller not to send messages. It looks as though either polling the encoder or the internal feedback routine is dramatically affecting the timing of the MIDI processor.
Does it sound as though I’m hitting a hardware limit or a firmware limit (or bug)? Or am I doing something obviously wrong, either in my MIDI implementation or in the controller configuration? I know that MIDI has severe bandwidth limitations but I don’t think this test is close to stressing them.
I can give a more detailed description or video later if that would be helpful, and I’ll keep poking at this on my end. I haven’t looked at the relevant parts of the firmware code for clarification.
Thanks in advance for any help or insight!