Sysex MIDI messages in PortMidi #1773
Labels
Comments
theGreatWhiteShark
added a commit
to theGreatWhiteShark/hydrogen
that referenced
this issue
May 17, 2023
After reading into both MIDI specs and doc as well as PortMidi api doc I came to the conclusion that the separate handling (and mere existance) of `SYSTEM_EXCLUSIVE` and `SYSEX` MIDI type must have been an accident. This fix should enable MMC MIDI control using PortMidi (I have no hardware to test this). Fixes hydrogen-music#1773
theGreatWhiteShark
added a commit
that referenced
this issue
May 21, 2023
After reading into both MIDI specs and doc as well as PortMidi api doc I came to the conclusion that the separate handling (and mere existance) of `SYSTEM_EXCLUSIVE` and `SYSEX` MIDI type must have been an accident. This fix should enable MMC MIDI control using PortMidi (I have no hardware to test this). Fixes #1773
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Operating system + version : Windows
Audio driver + version : PortMidi
Determining the actual type of an incoming MIDI message in CoreMidiDriver::midiProc and PortMidiDriver::PortMidiDriver_thread are both done by the first byte of the incoming message. The only difference is that CoreMidiDriver assigns type
MidiMessage::SYSEXfor a certain range of values and PortMidiDriver assigns typeMidiMessage::SYSTEM_EXCLUSIVE.But the result is totally different since
MidiMessage::SYSEXis used for incoming MMC_x events in theMidiMapwhileMidiMessage::SYSTEM_EXCLUSIVEare explicitly discarded.SYSEX and SYSTEM_EXCLUSIVE are treated as synonyms in all references I came across during a short search.
It feels a lot like this was done on accident but, unfortunately, it is there since the beginning of our git history.
The text was updated successfully, but these errors were encountered: