by CopperPhil » 25 Oct 2013, 17:04
Got it. It took a lot of time but we know what's happening. Here is the test we made:
Your player -> VMIDI1 ------> VMIDI2 -> Your synth
\----> VMIDI3 -> MIDI-Ox
1) When I click on Play, the music starts and I see the MIDI stream in MIDI-Ox.
2) Then I click on Stop, I see the all note off in MIDI-Ox, then ActiveSensing (0xFE) messages are sent around every 300ms.
3) I wait for a while...
4) Then I click on Play, no music issued from the synth, but I see the notes in MIDI-Ox.
VMIDI2 and VMIDI3 are exactly the same... and so their behavior must be similar. The MIDI is issued by VMIDI3 when I click on Play at step 4), so there is no reason it is different for VMIDI2...
We did the same test with the version 1.1.
The only difference is visible at step 2). The V1.1 does not send ActiveSensing through VMIDI2/3.
=> So everything is clear: the issue is related to Active Sensing messages.
The CopperLan to MIDI bridges are generating Active Sensing message when they are connected. If they loose their incoming connection, the Active Sensing sending is stopped in order to tell to the MIDI application or equipment behind that they must shut down the sound. This is the standard MIDI protection about stuck notes, and it was missing in V1.1.
Taking a closer look at the code generating the 0xFE messages, it seems that it is really borderline. It can be problematic if your synth is shutting down the sound just after 300ms.
=> We have reduced the time between two 0xFE messages, it will be available in the next build. In the meantime could you increase the synth treshold time, or disable the Active Sensing processing?