Sounds promising, my gripe is that it may screw with note stealing or other aspects, but i suppose the note on with 0 velocity = note off equivalence applies to note stealing and the likes as well…
I’m rewriting some old code, and just learned about the running status feature in the midi protocol. This means that if i can reduce note handling data to (a single initial) note on command, i’ll be able to shave off a third of all midi note data. It would be a pretty significant optimization.
In case you can’t get a definitive answer from a DN owner, I would suggest creating a support ticket on Elektron’s website to get the information direct.
That’s sensible advice! 
Appreciate the feedback y’all!
Keep in mind that not all devices might support this, especially newer ones.
But more importantly, you can’t reliably merge devices that send midi this way.
The performance optimization that this gives is mainly usefull for midi DIN connections because it’s inherently slow.
On a USB MIDI 1.0 connection you can send 48 bytes every millisecond, or 16 note messages(most USB MIDI devices use this even if they say USB 2.0).
Those 16 notes take 16ms on a DIN connection without the use of running status.
With running status you could shave that down to 11ms.
USB MIDI 2.0 widens that to 384 bytes, which is 128 standard 3-byte messages.
This is what the Digitone uses as far as I know.
So, unless you’re gonna use a direct MIDI DIN connection for your application, ask yourself if it’s worth the extra effort.
Also, (NOTE_ON, velocity 0) == NOTE_OFF .
Hmm… I didn’t know that. How can one tell what gear supports it, besides trial and error?
I see your point regarding connection speed, but there’s also the aspect of code optimization. As far as i understand, running status could free up processing resources, which are somewhat limited on an embedded system. Unless i’m mistaken?
Running status is part of the MIDI specification and supported by all serious devices.
Some very early MIDI device in the 80ies misinterpreted this feature.
Saving 30% communication bandwidth is nice.
I don’t see how. On the receiving end you still have to handle a note like a note, so every midi message, status byte or not, has to be identified and handled accordingly.
Maybe you can save a couple cycles on a microcontroller when sending, but I doubt it.
Like I said, the savings are mostly relevant on a DIN connection.
It is true that a lot of devices support it on the receiving end because it’s part of the midi spec, but there are barely any devices that use this for sending midi.
If you test all your keyboards, controllers and sequencers, you’ll probably find that none of them uses it.
It is used in midi file storage, because it saves storage space which was very expensive in the early days of midi.
The only modern midi connection that supports running status is BlueTooth LE MIDI.
If you’re using USB MIDI, every midi message that doesn’t have a status byte will get one before sending, negating all your efforts.
So, unless your code is for a device that receives midi over DIN or BLE, I wouldn’t bother.
But in those 2 cases, the midi spec dictates that you implement it.
It’s the only reason why (NOTE_ON, velocity 0) == NOTE_OFF.
If you want a place to save bandwidth, look at NRPN messages. These are implemented with their own form of running status which saves 50% of the bandwidth and actually works with USB MIDI.
However, keep in mind that this will fail when merging.
NRPN can also be supplemented with a null function message, but that will cost bandwidth, not save it.
You’ll have to use a hardware device that actually uses DIN as a serial connection.
Something like an Arduino midi monitor could do that and put it on a display or send it over USB serial.
You could make it as simple as blinking a led light when the status byte changes, that would tell you enough when you test a single device.
Running status will not show up in CoreMidi, iOS or Windows.
CoreMidi doesn’t even allow it. Windows translates it for you, negating your efforts. Even if it was used you wouldn’t see it because most API’s just give you the full message.
USB MIDI adds the status message before transport making it full messages again.
Running status for NRPN is easily observed though, because the first 2 messages for Control MSB and LSB (CC 99 and 98) will be missing when operating one control at a time.
In case someone wants to know, i just received the answer from elektron support.
The gist is that elektron follows the MIDI specification, meaning that their sequencers supports running status, and uses note on messages exclusively (i.e. no note off messages at all).
I’ve noticed that their sequencers send only note on messages, but that doesn’t mean they’re actually using running status apart from that convenience.
I’m curious what it does on the DIN output, I’ve got no reliable way to check right now.
I do know that it doesn’t shorten NRPN messages on DIN output the way it could, but I can’t check for actual running status.
I bet it is supported on DIN input though, since you confirmed they follow the midi spec.
Running Status can work on any MIDI transmission protocol (USB or DIN).
Running status is a convenient short cut in transmission of data which saves time and makes it easier to minimize delays of transmitted MIDI data from the actual performance.
With Running Status, after the first message, additional messages of the same type (i.e. Note On messages on the same MIDI channel) are sent without repeating the status byte for every message.
Receivers must understand that if a data byte is received as the first byte of a message, the most recent, or “running” status is assumed.
A transmitter may or may not be programmed to take advantage of Running Status. Using Running
Status, notes may be turned off by sending a Note On message with zero velocity . It is the responsibility of the receiver to always recognize both normal and running status modes.
No, it can not.
It’s not allowed on USB.
USB-MIDI is basically a transmission protocol for MIDI data over a USB hardware connection.
For sure USB-MIDI Event Packets are always 32 Bits long and always include a Code Index Number so Running Status has no impact on the size of USB-MIDI Event Packets.
But, USB-MIDI converters can handle running status MIDI data so it is not the case that it is not allowed it is simply that USB-MIDI uses fixed length messages because it is more efficient.
Yes, because USB MIDI Event Packets are not allowed to contain a running status message. If you tried, the message would be ignored or cause an error.
Cheap ones can’t. But besides that, you’re talking about a converter.
A converter will add a status byte to every message when converting from DIN MIDI to USB MIDI, before it ever hits the USB controller.
When converting USB MIDI to DIN MIDI, messages will always contain a status byte unless the converter implements it’s own running status.
But from the USB side, you simply cannot send or receive a running status message.
It’s not just a transport protocol for the same MIDI data because running status would get lost on conversion.
There is no such thing as a “running status message”.
When a Status byte is received and processed, the MIDI receiver will remain in that status until a different Status byte is received. Therefore, if the same Status byte would be repeated, it can optionally be omitted so that only the Data bytes need to be sent. Thus, with Running Status, a complete message can consist of only Data bytes.
The USB-MIDI converter provides the link between host and USB-MIDI function and is basically a software driver so I don’t understand when you say “cheap ones”.
The USB-MIDI protocol does not take advantage of Running Status because event packets are always 32 Bits long. So even a single byte of MIDI data would be sent as a 32 Bit package and the unused bytes are padded with zeros. USB speed and bandwidth are such that it simply does not need to reduce MIDI data.
If MIDI data is received over DIN, and is then forwarded on over USB, one of the functions of the converter is to the transfer the MIDI events, parsed into 32 bit messages for standardized transfer over the USB and for easy handling by MIDI devices. The MIDI data itself is transferred transparently, without any changes.
If MIDI data is received over USB, and is then to be forwarded on over DIN, the data is re-packed and there is no reason why Running Status cannot be employed because it is simply the omission of unnecessary Status Bytes.
Which is what I mean by a running status message, a message sent using running status that doesn’t have a status byte. It’s just semantics.
Cheaply made USB to 2 DIN plugs converter cables. Those often have problems converting DIN to USB when running status is used.
According to the USB MIDI spec, there is no Code Index Number for Note on or Control Change messages that are only 2 bytes long.
That’s what I mean when I say it’s not allowed.
The Status Byte is expected, so it has to be put in when parsing to a 32bit USB MIDI Event Package, which means any use of running status gets lost before transfer.
There is a special case if you want to send unparsed midi data, but that would mean using the whole 32 bits for a single midi byte for no good reason.
I agree, all I’m saying is the way you format your midi data on the USB side has no influence on this. Running status has to be implemented after reception of the USB packet.
OK we are obviously both aware of the relevant specification. 
I think your assumption is that when data only messages are converted to USB-MIDI a status byte is added.
My assumption is that when data only messages are converted to USB-MIDI a status byte is not necessarily added.
Unfortunately reading the spec does not absolutely clarify what actually happens as Running Status is simply is not mentioned.
The spec does say “The first byte in each 32-bit USB-MIDI Event Packet is a Packet Header contains a Cable Number (4 bits) followed by a Code Index Number (4 bits). The remaining three bytes contain the actual MIDI event.”
I think that if the actual MIDI event only contains data bytes that is all that will be used.
Die hard nerd talk going on here 
I think if you would implement it this way, it could work just fine for midi reception.
You could just assume running status and handle it that way.
But there is one little sentence in the spec that makes me think you can’t get away with this for sending midi, thus also making it invalid for reception.
On page 16 above the index table:
The Code Index Number(CIN) indicates the classification of the bytes in the MIDI_x fields
The Code Index Number for i.e.: Note on states 3 bytes.
If each of those bytes has a set classification, missing the Status Byte and padding with zeroes would mess up the order, making it an invalid message.
I think that’s why Running Status isn’t mentioned once in the whole document, it doesn’t exist in USB MIDI. The documentation could be a bit more clear about this though.
The spec does indeed show 3 bytes for the “Note-on MIDI-x Size” but that could indicate the maximum byte requirement of a Note-On message? The spec also states “The MIDI data itself is transferred transparently, without any changes.” Adding status bytes could be viewed as altering the original MIDI data?
Playing and releasing a 4 note chord generates 8 MIDI messages which could be transmitted as 3 bytes for the first message and 2 bytes for each of the subsequent 7 messages. Generating a status byte for 7 messages seems a bit inefficient?
As you say this a quite a nerdy in the weeds discussion and I suspect what actually happens is difficult to determine and is certainly not something that actually matters or will make a difference either way. 
I see it more as “running status ceases to exist” as soon as a MIDI stream hits a USB connection.
The connection is still transparent because no data is lost, in fact, you get some reconstructed data for free. 
At first, you would think that.
Until you look at the handling of sysex in the example.
There are actually 3 different Code Index Numbers for a sysex message that ends with 1, 2 or 3 bytes.
If padding with zeroes was automatically recognised, this wouldn’t be necessary given that the 'end of sysex', 0xF7 is also present in the event packet.
It seems that way, until you realize you need a Status Byte anyway for setting the Code Index Number.
And if you’re converting from DIN to USB, you’re already keeping track of the last Status Byte in case the device on the input uses running status.
If it was actually efficiently implemented, you would be able to send those 8 midi messages with running status in 6 packets instead of 8.
What seems more inefficient to me is that in most cases, the first 4 bits of the Status Byte sits twice inside the 32 bit Event Packet.
Or why do we even need Code Index Numbers? MIDI DIN works fine without them right?
I think it comes down to some internal logic in the way USB controllers work, and most processors calculate with 32 bits minimum so there’s a connection there.
Transmitting MIDI this way also seems less prone to errors, since you know exactly what information will be in which place, so no extra interpretation of the data is needed.
Oof, sorry for the long and post.