A few days ago I cloned VCVRack from github and compiled it on my manjaro linux machine.
It works well and I am impressed, however trying to use the MIDI-CV bundled plugin either from ascii keyboard, external DAW or usb midi keyboard round about half of the key presses are ignored.
I investigated by putting printf statements in the midi.cpp::InputQueue::onMessage() and in InputQueue::tryPop()
Midi-CV module ignores many noteON and noteOff messages.
This is caused by midi.cpp tryPop function returning false and the system apparently ignoring lots of messages despite the messages all ariving at
InputQueue::onMessage()
Has this been changed recently as I don’t see any reports of this problem anywhere?
This is not something I’ve ever heard of. Are you sure it’s not the usual issue where the MIDI-CV polyphony is set to something that doesn’t work with your patch?
Tried setting monophonic and various numbers of polyphonic notes.
I would expect the notes to latch on when a key is pressed with noteOn and off again with NoteOff when the key is released.
As I said the midi messages are all being received by the module code. Some are just being ignored.
I can also see the effect by connecting the cv output from the MidiCV module to the oscilloscope.
I can see other people are using this without problems, which is why I wondered if the code has been changed recently!
I had the same issue with both QWERTY keyboard and midi.
It turns out it is related to a feature I’m not sure to understand in src/midi.cpp at line 344 that drops frames if they are too far in the future. The comment above says:
// If next MIDI message is too far in the future, clear the queue.
// This solves the issue of unconsumed messages getting stuck in the future when a DAW rewinds the engine frame.
The issue I’m seeing is that the constant delta time threshold used is a multiple of block size so it’s linked to the buffering setting. As a result you can’t use a low buffer size even if you have a powerfull system because you will likely drop note on/off.
Raising this constant multiplier, like 100 times (i.e. 200 instead of 2) completely solves the issue of dropped midi event even when setting low buffer size such as 32.
If you can’t or don’t want to modify sources, you can raise the buffer size (this indirectly raises the delta time threshold). I noticed that raising the number of thread used can also have positive impact on event drops.
To be clear, here is my line midi.cpp:344
int futureFrames = 200 * APP->engine->getBlockFrames(); // raised 100 times the constant
It would be great if some dev could tell us the impact of raising this constant. If it is only useful when connecting to DAW this could be a totally optional behavior.
Sorry I’ve not been back here for a while.
thank you Subtoun for your workaround.
I have tried your suggestion and it does indeed work for me.
Looking at the comment just above line 344 it suggests that that code was added to solve a problem somebody was having. In our experience the code throws away midi messages that we are expecting to receive, so I suspect it was not thought through at the time, and clearly this module works well for many people without your fix!
For the time being I’m happy to work with your fix and compile the code myself.