Recently, the idea of converting MIDI Control Change messages to Sysex on the fly has come up a couple of times. One could use this to control a synth such as a Roland MKS or Yamaha DX7 that only accepts Sysex for control with a regular MIDI knob controller.
The following is a simplified example of doing this with
MicroMIDI.
@i = UniMIDI::Input.use(:first)
@o = UniMIDI::Output.use(:first)
MIDI.using(@i, @o) do
node :roland, :model_id => 0x42, :device_id => 0x10
*@my_map =
[0x40, 0x7F, 0x00],
[0x41, 0x7F, 0x00],
[0x42, 0x7F, 0x00]
receive :cc do |message|
command @my_map[message.index - 1], message.value
end
join
endDefining a Node
I won't get into too much background on Sysex but there are two concepts that one must understand in order to generate Sysex with MicroMIDI.
The first concept is what I call a
Sysex Node: there are up to three bytes of data used in each Sysex message to identify the synth/module/destination/node/etc where the message is intended to be sent. This is not unlike the MIDI channel in a regular short message except that it's three bytes. Two of those bytes pinpoint the make and model of the synth while the third byte identifies the individual synth (device ID) in case you have multiple Yamaha DX7's or whatever the case.
MicroMIDI allows you to define these bytes as a sticky value using the
node function.
Since I'm only using one synth for the entire example, I call the
node function before setting up the input event to catch Control Change messages. (If you are using multiple synths and multiple events you would call node in each event block). The arguments represent the
Manufacturer ID and the optional
Model ID and
Device ID. The Manufacturer can be referred to by a symbol (as above) or a string if its name is found in the manufacturer constants in
midi.yml (by all means, add yours and do a pull request).
Now here's the annoying part: different brands and synth models use this Node data differently. For instance, I believe some devices don't understand messages with a model ID in them. In those cases just leave out whatever needs to be omitted from your messages. As I learn more about this myself, perhaps I can have this function streamline accepting the proper data for major synth types.
Command vs Request
The other concept to understand is that Sysex messages can (in theory) either be a command or request. This is pretty simple, and if you are creating a controller program you'll deal mostly in commands. In the case of the example above, we send a command
command @my_map[message.index - 1], message.value
When using the
command function, the first argument is the sysex address and the second is the value to assign. The value can either be a number, as in this case, or an array of bytes.
When making a request, the first argument is also the address but the second argument is the size of the response (in bytes) that you expect to receive
request 0x43, 43
If all else fails...
Due to the fact that Sysex hasn't had a truly concrete spec, some devices will use messages that don't really adhere to the command/request format. In those cases, you can just use the generic
sysex command like this
sysex 0x1, 0x2, 0x3, 0x4
With no node specified, this will give you a message composed of
F0 01 02 03 04 F7
In other words,
sysex will create a message and not perform any validation or add a checksum to it. You can still use
node with these message-- it will append those bytes immediately after the
F0 start byte as it would with a command or request.
tldr, Sysex is tricky to to objectify
If you'd like to gain a deeper understanding of how sysex messages work,
this is a good tutorial (if Roland-centric) and I often referred back to it while creating MicroMIDI and the libraries that support it.
http://github.com/arirusso/micromidi
Next: More MicroMIDI Tricks
