MPE (Mid polyphonic expression)

[Markus Krause]

Today i ordered a MPE-controller. I got mixed feelings about implementing the MPE specification. My opinion is that it is not very well-designed and looks more like a dirty hack. Why?

- It only supports 16 voices properly
- It opens the door for bugs
- I can create incompatibilities between manufacturers
- It breaks the midi specification
- If a midi device is disconnected and re-connected it will play wrong notes, because the midi-in device can't know that MPE mode is currently used
- Why do they not use NRPNs?
- Why is "polyphonic key pressure / aftertouch" not used which does exactly the same and is a well-defined midi command?

What do you think?

[Jeff McClintock]

The MPE specification looks more like a dirty hack. Why?

Short answer: It is a dirty hack.

Long answer: Polyphonic expression was LONG overdue, and Roli did the best they could within the limitation of MIDI 1.0 to finally support it. I suspect also that MPE goaded the big companies into releasing the MIDI 2.0 spec (after many years of procrastination). MIDI 2 is "MPE done right" and doesn't suffer the same limitations.

I'm guessing Roli are now working on MIDI 2.0 support for Roli keyboards, and perhaps it's wiser make preparations for supporting MIDI 2.0 at this point (in addition to MIDI 1.0 of course).

[dusted william]

I love mpe I No way I could go back. I hope you do it!

[Markus Krause]

If the spec of MIDI2 different from the MPE spec that Roli uses?

[jussi_neuraldsp]

If the spec of MIDI2 different from the MPE spec that Roli uses?

MIDI 2.0 is quite different comparent to MIDI 1.0 (and it's extensions like MPE).

https://www.midi.org/articles-old/detai ... y-exchange

[Markus Krause]

Thanks for the link. So

Midi 2.0 != Midi 1.0 + MPE

Midi 2.0 = Midi 1.0 + Systex for Midi 2.0 data + bidirectional communication

The Midi 2.0 specification seems to be a lot better than the 'MPE hack' with midi channels.

From what i can read Midi 2.0 should work with the existing interfaces. Will it work also with VST 2.4 ?

[Tj Shredder]

Most of MPE is plain old Midi, just use Midi and assign all dimensions to the voice which received a noteon on the same Midi channel. Nothing will break... It could even do more than 15 voices if you could live with having two voices react on the same controls or let the older one ignore the controls (would be better probably...)
The voice limit is due to the limitations of Midi 1.0 there is no way around and its meant for expressive Instruments. 15 Voices are plenty for 10 Fingers, I am mostly happy already with 6 Voices... If you need more in a DAW context, use VST3 expressions...
MPE is the core feature which made me go back to synthesizers. I don't buy any synth without it anymore...

[S0lo]

I happen to have implemented MPE support before so I'll try to answer some of your questions:

- Why do they not use NRPNs?

They could have. The thing is NRPN (and also SysEx). Is just too open ended for what they want to do. This entails that they have to add more on specification/standardization which means that they have to convince vendors to adopt the extra new spec. The more minimal changes they make, the more probable that companies will adopt.

Second reason probably is that NRPN requires two CC messages (98 and 99) prior to each and every parameter change. These would be made to select the parameter/note combination you want to change. Then you send an additional CC that carries the new value. So each change would require 3 CC messages instead of 1. This would reduce available bandwidth to a third. And you can imagine how many messages there will be if each and every note the musician presses can have it's own multiple CC messages changing rapidly all the time.

On the other hand the current MPE spec sends only 1 CC embedding the note selection in the channel number.

- Why is "polyphonic key pressure / aftertouch" not used which does exactly the same and is a well-defined midi command?

Polyphonic aftertouch is only ONE parameter. What if you wanted to change 2,3,4... parameters per note concurrently?


MPE is a hack indeed. But it's a hack that doesn't seemingly break anything. It's only a hack on the sender/receiver side on how to interpret MIDI. Well thats at least as far as I understand it. I could be wrong

[Markus Krause]

I bought a seaboard blocks and MPE is implemented on Icarus2 now.
It works pretty well with the existing factory patches.

One thing that worries me a bit is that the Roli Seabord does not seem to be sending the MPE configuration message. How else should a receiver know that a MPE device is connected? Or must the host create this message and send it to the plugin?

[Markus Krause]

I did measurements with Bitwig. I found out that Bitwig does not stick to the MPE standard that the Midi Manufacturers Association proposes. It would be smart if they would do some changes, because it could cause trouble with various MPE compatible plugins.

The MPE configuration message should look like this:
B0 64 06 B0 65 00 B0 06 0F

What Bitwig does is this:
B0 65 00 B0 64 06 B0 06 0F
It is actually more like the RPN for setting up the Pitchbend-range

I contacted the authors of Bitwig about it.

[mystran]

The MPE configuration message should look like this:
B0 64 06 B0 65 00 B0 06 0F

What Bitwig does is this:
B0 65 00 B0 64 06 B0 06 0F
It is actually more like the RPN for setting up the Pitchbend-range

If you're parsing RPN/NRPN correctly, then this difference is completely irrelevant.

CC 0x65 sets the MSB (while leaving the LSB to it's previous value) part of the currently selected RPN index and CC 0x64 sets the LSB (while leaving the MSB to it's previous value). Since each of these just modifies a "separate" value, the ordering (or even whether they arrive together) cannot possibly make any difference whatsoever.

Same really applies to any 14-bit value: when you see an MSB change, only change the MSB and when you see the LSB change, only change the LSB. Trying to rely on them arriving in particular order or trying to rely on them arriving together (in any order) is simply not safe in general.

MIDI allows you to omit redundant status bytes, so over a serial link you might even see:
B0 65 00 64 06 06 0F

[Markus Krause]

Thanks a lot for the info. So what they're doing is at least not wrong from the technical side.

I have read the reason why the Midi Manufacturers Association did reverse the standard ordering of LSB and MSB compared to the common Pitchbend range RPN is that they wanted to make the Midi message look more different to avoid possible collision problems.

By the way your 4K demo for the Assembly is really cool. I was in the demo-scene too before i started programming only audio stuff.

Here is some old stuff from me that i coded at DOS times. I ported some stuff to a HTML canvas. It should work very well for 4k demos. You can reuse the code if you want:

https://www.tone2.com/ims-exclusive.html
https://www.tone2.com/electromania.html
https://www.tone2.com/edm-pop.html
https://www.tone2.com/top-of-the-clubs.html
https://www.tone2.com/electronix.html
https://www.tone2.com/trance-dance.html

[mystran]

I have read the reason why the Midi Manufacturers Association did reverse the standard ordering of LSB and MSB compared to the common Pitchbend range RPN is that they wanted to make the Midi message look more different to avoid possible collision problems.

You really shouldn't rely on LSB+MSB arriving in a particular order for pitchbend either.

[Markus Krause]

I don't rely on it

[Markus Krause]

Update: The authors of Bitwig have responded to my request to use the same ordering for the MPE initialisation message that the Midi Manufacturers Association proposes. They will implement it in the next update.