search

mixedinkey-opensource / MIKMIDI

MIDI Library for Swift and Objective-C Mac and iOS apps.
Other
492 stars 95 forks source link

Support for running status #301

Open MicheleLonghi opened 3 years ago

MicheleLonghi commented 3 years ago

I'm unable to receive running status control changes: after the first, subsequent CC are dropped. Thanks

armadsen commented 3 years ago

I need to dig into this. I believe sending running status is unsupported by CoreMIDI, but I was under the impression that receiving should "just work" and be handled at the CoreMIDI level. As long as the status-less messages are delivered by CoreMIDI into MIKMIDI, we could handle the rest at the MIKMIDI level.

orchetect commented 3 years ago

Core MIDI does not reconstitute received running status messages, you'd need to handle them in the parser.

armadsen commented 2 years ago

@MicheleLonghi: I'm finally getting back to this. I don't seem to have any devices here that send messages using running status. I'm curious what device(s) you're using that do.

armadsen commented 2 years ago

I got ahold of a device that (reportedly) uses running status, however, as I expected, the messages it sends are reconstituted before they ever hit the Core MIDI APIs. That is, the read callback passed to MIDIInputPortCreate gets fully-formed packets. It seems like the USB MIDI spec requires this at the adapter level.

@orchetect: I see that you've implemented explicit reconstitution of running status messages in MIDIKit. I'm curious to know what hardware/connection setup you know about that means this functionality is needed at the application level?

orchetect commented 2 years ago

It seems like the USB MIDI spec requires this at the adapter level.

Not sure if that's true but would be interesting to know.

I'm curious to know what hardware/connection setup you know about that means this functionality is needed at the application level

Through testing and countless hours poking Core MIDI, for legacy MIDI 1.0 (not UMP), de-facto you need to fully implement running status in the parser when receiving packets. Even just using some dummy virtual MIDI endpoints in isolated unit tests can confirm that Core MIDI won't reconstitute them. It somewhat makes sense, since properly implementing RS means that Core MIDI would have to maintain state for each port, and clearly they didn't do that and felt for some reason that should be handled by the consumer.

Some devices pack running status into a single packet, such as HUI control surfaces. And some MIDI keyboards I've used utilize running status globally.

TL;DR per MIDI 1.0 Spec:

  1. Parse running status within the same packet.

    ie: b0 2c 00 2c 01 2c 02 (equivalent to b0 2c 00, b0 2c 01, b0 2c 02) and it arrives as-is, requiring you to parse it out.

  2. Persist the status between packets in case ad-hoc running status messages arrive that omit the status, and clear the status when appropriate (Spec outlines when to clear status).

    ie: get a b0 2c 00, then packets following that contains just data bytes, ie. 2c 01 should be interpreted as b0 2c 01