AZSlow

General => Control Surfaces/ACT => Topic started by: azslow3 on September 09, 2014, 03:18:18 PM

Title: MIDI interpretation and MIDI routes in Sonar
Post by: azslow3 on September 09, 2014, 03:18:18 PM

While I have written some tips at relevant places in AZ Controller documentation, reasonable systematic general explanation how MIDI signal is processed  when SONAR is used with some Controller is worse a separate topic.

SONAR documentation chapters 20 and 40 is a good source of information about what SONAR does with MIDI. It is written by professionals, in good English and it is translated to several languages. The following is my own "interpretation", do not overestimate it.

Originated from Hardware world and unifying the number of wires, frequencies, voltages, etc. electrical parameters for successful equipment communication, when used in software DAW like SONAR MIDI can be interpreted just like a sequence of MIDI Messages. Hardware oriented part of the MIDI specification is almost ignored once the signal comes into the computer since we use USB, Fireware, Ethernet or some other protocols/equipment with completely different electronic characteristics (speed, packet size, distance). But the informational part of the specification is not dependent from the transfer method.

MIDI Message
MIDI information is transfered as continuous steam of bytes (each byte represent a number in range from 0 to 255). "Stream" means there is no special "begin" and "end" information transfered different way (which is called "packet" transfer, for example Ethernet, UDP, most "real time" protocols). The Stream with MIDI information is divided into Messages using simple convention: in case some byte has values in range 128-255, this is Status byte and it is either complete message by itself of it is the beginning/end of the message. Bytes with values in range 0-127 are Data bytes (for Message type indicated by previous Status byte).

MIDI specification defines the size and the meaning for many messages while leaving some space for manufacture specific messages (System Exclusive). It is important to understand that while Message Format is respected by hardware/software producers, the meaning of any message is just a suggestion for possible use. From DAW/VST/Control Surface perspective, the meaning is in many cases completely different. For example, MIDI Specification defines Message "Pitch Bend Change". It has format "224+<MIDI Channel> " followed by "2 data bytes with value". While in case you see "225" ("224+1") coming from your Mackie Surface there will be 2 data bytes with value, this value is not "Pitch Bend" but the position of the second slider. In other words, while sometimes Messages sent have MIDI specified meaning (especially on controllers combined with keyboards), that is not a rule. But the format (how long some message is and which parts of the message are "variables") is always the same.

The list of all defined messages you can get from http://www.midi.org/techspecs/midimessages.php (http://www.midi.org/techspecs/midimessages.php). It looks a bit cryptic for the first time, but it is easy to understand in case you know that byte is 8 bits and can be "converted" to "normal" numbers using formula "<bit0>+<bit1>*2+<bit2>*4+<bit3>*8+<bit4>*16+<bit5>*32+<bit6>*64+<bit7>*128".

MIDI Message "routes" inside SONAR
MIDI Messages in SONAR are either coming from MIDI track or from MIDI Input devices (set to be used in Preferences/MIDI/Devices dialog). They are processed differently.

Messages coming from MIDI Input devices:

• are passed to Control Surface Plug-in if the device is specified as the "In Port" in Preferences/MIDI/Control Surfaces. The plug-in can "interpret" it (for example, ask SONAR to "Play" once it is "C4" Note On MIDI message). The Plug-in can ask SONAR to not process the message other way, or not process any messages from this device other way (for example, Mackie plug-ins do that). Note that Plug-in can interpret the message but not block future processing. Also in case the Input device is the "In Port" for several Plug-ins, all "blocks" specified by plug-ins except the last one are ignored.
• In case the message is not blocked by Control Surface Plug-in, SONAR looks either it should interpret it by itself. For example as Remote Control, Matrix view MIDI Learn, etc. Think as about shortcuts defined for computer keyboard.
• In case the message is still not "consumed" by Control Surface Plug-in on SONAR itself, it is transfered to MIDI track(s). MIDI Tracks can be configured to receive messages from all Input devices (Omni) or from particular device. Future processing is the same as for Messages originated from MIDI Track

Note that SONAR has no internal tools to trace/debug the MIDI Message route up to MIDI Track input.

Messages from MIDI Track.
Messages can be either from the MIDI Track input directly (if "Input Echo" is activated for the track) or from the recorded material. During recording of armed MIDI track, messages coming from the specified input are saved with the corresponding time they was received. Please note that original MIDI specification is quite old, a transfer of one chord with 10 notes takes close to 10ms.

Either way, the messages are then passed to the MIDI Track output. Here is normally sit some VST, either used as synth or effect (in this case MIDI normally does not trigger sounds, but control processing parameters, for example for guitar effects). Again, how VSTs are interpreting the message is up to concrete VST, some are following MIDI specification convention, some not.

Recorded MIDI Messages can be inspected in the Piano Roll (Notes and CC) or in the Event List (all messages).

* I have not touched "Drum maps" there, that is Sonar way to "translate" MIDI messages.

MIDI Messages
Since each Status Byte is in range 128-255 and (always!) specify one particular message format, the number of such formats is pretty limited. In practice, it is less then 127 since not all numbers specify separate message type but different MIDI Channel (1-16) for the same type. So, the whole list is:

• 128-143 - Note Off, 3 bytes long, Note "number/key": 0-127 and Note "Value/Velocity": 0-127
• 144-159 - Note On, 3 bytes long, Note "number/key": 0-127 and Note "Value/Velocity": 0-127. Note On/Off are normally triggered either by Keys or by Pressure sensitive Buttons. When triggered by buttons, the system can not "see" it was not a key till it is on different MIDI Channel. Once you configure your button "MIDI Channel1/C4" to start "Play" (for example in ACT MIDI Plug-in), your key "MIDI Channel1/C4" will also trigger "Play" and it will no longer trigger C4 Note in your VST Synth. So Note messages from buttons (pads) are most practical to use as MIDI input for drums or "triggering" VSTs, not for control tasks.
• 160-175 - Polyphonic Aftertouch, 3 bytes long, Node "ID": 0-127, Note "Value": 0-127. Not many (if at all) keyboards trigger that these days.
• 176-191 - Control Change, 3 bytes long, "ID/Control number": 0-127 and "Value": 0-127. Most rotaries and sliders send that, also buttons do (using predefined Value, usually 0, for "button off", when registered). There are many possible problems there, so I explain it later.
• 192-207 - Program Change, 2 bytes long, "Program Number": 0-127. Since there is no "Value", "button off" does not "fit" into that message. Can be used on buttons for real Program switching (for example in life performance). Some plug-ins (like ACT MIDI) can not use buttons triggering such messages.
• 208-223 - Channel Aftertouch, 2 bytes long, "Pressure Value": 0-127. Many VST synth can use it. Some keyboards can trigger these messages as expected, by pressing keys, other (most cheap) keyboards just have a rotary which send such messages.
• 224-239 - Pitch Bend, 3 bytes long, "pitch change": +-0-8192. The only "simple" message type with 14bits value resolution. Synth are normally react on that message type. Most keyboards have a dedicated control element for it. Still, it can be used for hi resolution sliders/rotaries on dedicated controllers without keyboard (Mackie sliders trigger that messages)
• 240 - System Exclusive (ends with 247). Explained later.
• 240, 241, 242, 246 - MIDI Time Code Quarter Frame (2 bytes), Song Position (3 bytes), Song Select (2 bytes), Tune Request (1 byte) are special system messages for synchronizing/controlling hardware MIDI equipment.
• 248 - 255 are "real time" single byte messages. They can be transfered asynchronously inside other messages. Start/Stop/Continue plus Timing Clock are MIDI way of transport control. 255 is "Reset all" command. 254 is "I am there" message. To be fair, I have no idea either these commands are useful for Control Surface/SONAR software. Control Surface controls SONAR using Plug-ins which translate "normal" Messages into special SONAR API functions. So, for example, "Play" is either started using "Play" command execution or "Play" transport state change.
• there are 4 undefined (reserved) messages: 244, 245, 249 and 253. I do not think it is good idea to use them.

And in fact that was all possible MIDI messages, at least from format point of view (size and variables positions). There are System Exclusive messages, which can be use to transfer arbitrary information, but from format point of view, they are all "System Exclusive" (240, data bytes till 247).

14bit Control Changes (CC) and (Not) Registered Parameter Numbers ((N)RPNs)
These are not separate MIDI messaged, but a combinations of "normal" 7bit Control Change (CC) messages with special interpretation of some particular Control numbers.

The hardware/software either interpret all CC as simple or interpret them according to the 14bit/PN rules. It is easy to "violate" these rules from simple devices where you can assign arbitrary CCs to control. And that can produce very strange results on the receiving end...

In the "14 bit mode":

• First 32 and next 32 CCs are used in pairs to form 14bit values, so CC0+CC32 change the one(!) parameter "14bit CC0". The data delivered by CC32 is lower 7 bit of its value, by (7bit) CC0 is upeer 7 bit of its value
• "14bit CC 6" (so, CC6 and CC38 messages) are used by (N)PRN interpretation and should be avoided for other perpose
• One RPN parameter has 14bit "address" (id) and 14bit value. To send one RPN parameter, 4 CC messages are required: "address" is transfered by CC100+CC102 and then data are transfered by CC6+CC38. Note that the same(!) 7bit CC messages are used for all RPNs
• NRPNs are transfered exactly as RPNs. But the "address" is specified by CC98+CC99
• CC96/CC97 can be used to relatived Increment/Decrement (N)RPNs instead of setting absolute value (by CC6+CC38)
• There are still some place for 7bit only CCs, all CCs from 64 upwards, except used for (N)RPNs.

There are many problems coming from the fact that the same CC messages are used for different purpose. For example, what to do in case we have received just upper byte of NRPN address and then we see lower part of its data? Is lower part of the data is always transfered for 14bit CCs (according to the standard, that is not required)?
So for Control Surface purpose this mode is far from perfect. Unfortunately, there are only 16 14bit parameters in the basis specification (PitchBend on 16 MIDI channels). In case there are more then 16 hi resolution faders, you will need either 2 separate "MIDI devices", 14bit mode or SysEx. All three approaches are used in the real hardware.

System Exclusive (SysEx) messages
While they can be quite lengthy (compare to the other message types), unlike 14bit CC and (N)RPNs there are still transfered by one MIDI message. And so there is no problem with a sequence interpretation or skipped messages. Also since the length is arbitrary, the data part is not limited to 14bit. The price is the length (and so the time to send them, which 25 years ago was critical).

All SysEx messages have the format:
240  <1-3bytes manufacturer ID> <device/identified section> <data...> 247

Note that some subset is "reserved" and has common meaning, 240 126... 247 and 240 127... 247. MMC messages (many surfaces send them when you operate transport buttons) are in this set.

The interpretation of other SysExes is completely manufacturer specific.