I’m unable to test this out for a while, but i still need the info, so: Using MIDI in for sequencing, is the release portion of the AMP envelopes exclusively triggered by a MIDI note off message, or could a note on message with 0 velocity also trigger the release phase?
Only the note off AFAIK. But you might be able to set the release to infinite and map the velocity to negatively effect the release time.
Not sure i follow… You mean having infinite release, and controlling release values with subsequent note on velocity values?
This is confusing me more than it should… I realize velocity 0 = no audible release, but i can’t shake the suspicion that an omitted note off value may result in unexpected behaviors.
I’m sure they’d list it in the midi implementation but I get the frustration, it could be so useful and seems so easy to include.
I missinterpreted the question but I think that you can achieve the effect that you’re after with the same steps by using an aftertouch message instead of velocity to lower the release time from infinite.
So the note would hang until it receives an aftertouch value.
Hm, i see…
It doesn’t help that there are at least three different CC values that deals with volume 
It’s a headache for sure. Some useful stuff in here if it helps though.
1 Like
I don’t have a Digitone but the MIDI specification states that a Note On message with zero velocity should be treated as Note Off, so the DN should do so.
What’s your concern?
6 Likes
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.
1 Like
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 .
1 Like
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.
2 Likes
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.
1 Like
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).
2 Likes
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.