kyma•tweaky . Learn . BidirectionalMIDIStreamsOverOSC

Protocol for Bidirectional MIDI Streams over OSC

Most music software can already send and receive MIDI controllers and note events. The Open Sound Control protocol (second table down) specifies an argument type ,m as a 3 byte MIDI message. In this document, Symbolic Sound provides additional details that make it possible to define a bidirectional stream of MIDI events sent as OSC messages over the network.

MIDI/OSC Message Streams

Each message can have from 1 to 128 arguments. The address of the message can be any string. The type list must be ‘,m’, ‘,mm’, ‘,mmm’, etc.

Each argument is 4 bytes (MSB first):

The first byte is not required to be MIDI Status byte. MIDI data bytes with the value 0xFF are ignored, so use 0xFF to fill unused bytes in argument.

Multi-argument OSC/MIDI Messages

Most MIDI messages fit into one OSC argument (since most MIDI messages are 1 to 3 bytes long). However, system exclusive messages are longer than 3 bytes. Also, for efficiency, you may prefer to send more than one MIDI message per OSC message. For these reasons, you can also send multi-argument OSC/MIDI Messages.

To send a multi-argument MIDI/OSC message:

Once you send one of these multi-argument messages to a device or application, that device should respond using the same format in its return messages. (See Two-way communication between Kyma and OSC sources for details on a suggested method to specify destinations for return messages).

Kyma Paca(rana) Communication

If you are writing your code for compatibility with Kyma on the Paca(rana), here are a few additional notes that may be helpful:


Regarding this statement:

To send a multi-argument MIDI/OSC message: pack 3 bytes per OSC argument; pad the final OSC argument out to a multiple of three by using 0xFF (in the last data byte or last 2 data bytes). This does not preclude packing full MIDI messages one per argument, right? For example sending PC(25), CC(1,100), and AT(65) could be done using: {0x00, 0xC0, 0x19, 0xFF}, {0x00,0xB0,0x01,0x64}, {0x00, 0xD0, 0x41,0xFF} right?


Correct. A 0xFF is ignored no matter where you put it.

----- Revision r1.3 - 01 Mar 2010 - 22:00 GMT - CarlaScaletti
Copyright © 1999-2014 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding kyma•tweaky? Send feedback.