Cherry Audio Forums

Steve W wrote: ↑Fri Nov 15, 2024 5:25 am Could be coincidence, but whenever the FA went to an output and whenever the FC went to an output, they were directed to the Ath (11th) and the Cth (13th) port respectively. It is almost as if the lower half of the command became the channel. The errant FA only showed up at the 11th [10 + 1] port and the errant FC only showed up at the 13th [12+1] port.

Respectfully, I'm pretty sure that the issue is with your code, Steve. ("Let he who is without sin cast the first stone").

I agree with Colin's analysis. You have to ensure that if you're parsing a System message, then the channel number returned by the GetChannel method is undefined, and should be ignored:
My suspicion is that the GetChannel method always returns the bottom four bits of the Status Byte, irrespective of whether it's a channel (80h to EFh) or system command (F0h to FFh). So, it's up to the programmer to decide if it's appropriate to request the channel number, after parsing the Status Byte.

I also suspect that if you were to use the wrong form of SetMessage to construct a System command, you might also get into trouble:
(i.e. If you specified the third form, would it unconditionally OR the channel number with the bottom four bits of the Status Byte, or even overwrite them entirely???)

utdgrant wrote: ↑Fri Nov 15, 2024 3:48 pm I'm sceptical about system real-time messages interrupting the individual bytes of a MIDI channel message within the VM environment.

I totally agree Grant. And with your point about ShortMessage getChannel() just returning the masked bits.

However, it could explain both Steve's experimental data and the mysterious asynchronous (thread-safety going south-like) behaviour I and possibly others have witnessed.

I've already spent a couple of hours on this today and need to make progress elsewhere (Custom Transport) but perhaps you or others could take up the challenge and see if VoltageMIDIJack::GetMessages() ever returns malformed ShortMessage objects when bombarded with say MIDI clock and a high volume of note on messages.

I think it's just a matter of looking through a long string of MIDI data bytes looking for any value that's >= 128 but that's not something I could quickly knock up a test bed for.

-- Edited to add...

And merging MIDI clock and high volumes of other messages to send in the other direction.

Hey Steve, I just looked at your screenshots again and noticed that your MIDI monitor was looking at the output from Song Control rather than Sync to MIDI Clock.

The only MIDI messages that Song Control sends out are ShortMessage.START, ShortMessage.STOP and ShortMessage.TIMING_CLOCK all of which are single byte system real-time messages, So the possibility I mentioned of one byte messages interrupting three byte long messages can't arise in this situation.

The same thing almost certainly applies to the Sync to MIDI Clock module, but I can be definitive about my stuff.

I also checked my code and everything is done in the ProcessSample() thread so there's no naughty calls to output MIDI messages from other threads. For instance although clicking on the play button is handled in the Notify() thread I just set a flag there to request a transmission in the ProcessSample() thread.

So the only things your MIDI monitor should see are FA, FC or F8.

I'm left curious about the intermittent behaviour you are seeing as how I imagine you'd code it the results would be consistent.

Thanks for taking a look and for the wonderfully detailed and thoughtful replies. My to-do list for today is overflowing, but I will make time revisit my preset with the comments in mind. Things were so much easier with asm coding. My tool works well as is for 2-byte and 3-byte commands using VMD /Java. I am sure I did not write special code for handling 1-byte commands, nor sysex. I did try a tool to list all midi data, but was spending too much time trying to get the layout "just right" which took away from the main purpose of the tool at the time I did it (at least a year and a half ago.) Again, thanks for the detailed comments!

beautiful to see that my post sparked some food for your nice brains.

the support suggested me too to keep using the FX plugin as workaround.