Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MIDI Protocol - How to handle realtime, interleaved, messages #161

Open
ChristopherHaws opened this issue May 13, 2023 · 0 comments
Open

Comments

@ChristopherHaws
Copy link

Hey there! I tried asking in Gitter, but it seems pretty inactive so I figured I would ask here. :)

I am attempting to implement the MIDI 1.0 protocol using Bedrock. I have a use case where I need to connect to a networked audio mixer (which uses MIDI over TCP) but I also want to be able to support MIDI over a serial bus or other transports that might be relevant. Bedrock immediately felt like the right fit!

The main roadblock I am running into is that I can't figure out how I would use MessageReader.TryParseMessage to parse interleaved messages in the data stream since it only supports outputting a single message at a time.

Per the MIDI spec:

Real Time messages can be sent at any time and may be inserted anywhere in a MIDI data stream, including between Status bytes [most significant bit = 1] and Data bytes [most significant bit = 0] of any other MIDI messages. Giving Real-Time messages high priority allows synchronization to be maintained while other operations are being carried out"

There are only a handful of realtime messages so they are fairly easy to detect:

  • 0xF8 = Timing Clock
  • 0xFA = Start
  • 0xFB = Continue
  • 0xFC = Stop
  • 0xFE = Active Sensing
  • 0xFF = System Reset

I was wondering how you would go about reading these messages? My first thought was to create a middleware to read just the realtime bytes and forward non-realtime bytes downstream to the IMessageReader, but I couldn't figure out how to set this up. It also felt wrong since my understanding is that middleware should not be transport or protocol specific.

Any help would be greatly appreciated! I will be open sourcing the protocol implementation once I have it working. :)

Thanks for this great project. I hope you eventually get time to keep working on it! ^_^

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant