I like to think it's fit for purpose in describing how devices should work together. The specification needs some kind of unit test library: a set of described operations for a controller / a series of validation messages for a synth, that test each feature of MPE. That may be beyond the remit of the MPE Working Group, though.

I am really happy to see this work move forward. While the protocol details may not be disclosed before the standard is ready how about discussing the device interaction use cases? While Roger Linn and team are really smart something could still be overlooked.

For instance it takes a number of messages to make sure the sound engine is configured properly for the current configuration of the MPE controller. It would be nice if there was a way to request this information from the MPE controller. Such as having it send this information as a response to a device inquiry message (should the MIDI standard permit that).

Thanks for listening! 🙂

dslsynth wrote:

While the protocol details may not be disclosed before the standard is ready how about discussing the device interaction use cases? While Roger Linn and team are really smart something could still be overlooked.

For instance it takes a number of messages to make sure the sound engine is configured properly for the current configuration of the MPE controller. It would be nice if there was a way to request this information from the MPE controller. Such as having it send this information as a response to a device inquiry message (should the MIDI standard permit that).

Currently, the message that broadcasts MPE configuration defines how the MIDI channel space is divided: up to two zones, each with a Master Channel, and a number of channels that convey the note data. The Master Channel is used to send Program Change messages, pedal data, and so on. This fits (I hope) use cases where a controller instrument is plugged into a DAW and a multi-timbral synth is handling the data from it. Compatible instruments and controllers will have enough data from the setup message to configure themselves properly.

The MPE Working Group isn't attempting to change the way MIDI is currently used beyond stating how note-per-channel MIDI should be designed to be maximally compatible. For example, the message that defines zones won't be adequate to convey to an instrument how it should assign these zones across its playing surface, or how a synthesiser should respond to per-note Control Change messages. Such details will always be vendor-specific.

Hi,

I like the multi dimension controllers. To work with current specs, I understand the choice to work with note-per-channel.
But as far I understand with the versions of controllers out there now, isn't it so "we" only need 3 extra controls which are poly (as in PolyPressure).
Poly X = movement on the X-axis of a "key" (Like on the Yamaha GX1 solo keyboard)
Poly Y = movement on the Y-axis of a "key"
Poly pitch (or Z). For those controllers which have ribbons. Those ribbons could control something else than pitch right?

By having these messages, you don't need to take away the other channels which could be used for another synth. At the moment there are no hardware synths supporting this, but imagine in the future you can have a multi timbral synths with all the controls on any channel without the need to program the synth so that on multiple channels the same patch needs to be selected to be able to use MPE. And losing the multi timbral function because of the note per channel choice.

I my self use TouchKeys ( https://www.kickstarter.com/projects/instrumentslab/touchkeys-multi-touch-musical-keyboard) which work quite nice. I can imagine something like this can be implemented in a real keyboard (like Fatar keyboards). By using this touch sensitive material embedded, the PolyPressure becomes cheaper to implement AND having an X-axis and Y-axis for extra control.

If something is not clear, I am happy to explain more.

Best regards, Marcel Krol

Hi again,

Wasn't able to edit my post, so added a new one.

The midi spec is a bit full. From 8 (1000) till F (1111) all occupied. "You" probably don't want to use 0 to 7 as a start for whatever reason. (1000 - 1111 now, 0000 to 0111 not used)

As an alternative, "You" could change the Poly pressure (A aka 1010) and add a 3rd byte.
1st is note no.
2nd is type (pressure, X, Y or Z) and
3rd the value.

And probably doesn't even interfere with current synths.
Poly pressure is (A) 1st value is note 2nd is pressure value.
Maximum is 7F (127) so if 2nd will be type (X,Y,Z) and starts from 80 (81 and 82), then probably current synths ignore it as it is out of scope/value.

Best regards,

Marcel Krol

The reason that 0x–7x cannot be used as status bytes, and that a third byte cannot be added to the poly pressure message, is running status.

Sure it doesn't match current MIDI specs, but sending it to MIDI 1.0 devices wouldn't do harm if well implemented as they should ignore wrong messages. However if (until adopted as an addition) MPE aware devices can send and react on them, that would make it useful. Also F9 and/or FD seems to be free and could be used.

Multidimensional Polyphonic Expression (MPE) with use of the note-per-channel isn't really polyphonic anymore. It becomes MMME; Multidimensional Multichannel Monophonic Expression.

I understand F9 and F9 are in the system range and not channel range. I understand the "Running Status".

Good news! If the working group reaches a positive result and the idea is implemented it will be a real breakthrough. Even the already announced capacity will be sufficient for a qualitative change tools. But I worry about other issues. All these innovations will be associated with a significant increase in the volume of data transmitted. Do bandwidth standard interface withstand this increased volume of data without loss of quality?

I'm not sure of the need for the MPE spec to chew through multiple channels? (it maybe that I have misunderstood the spec)
Could this not be done by adding to the RPN list?

If I understand correctly we need 3 values? Note, x/y/z and value?
What if RPN is made up of
CC 101 => 1 - Ok we are dealing with an MPE/pressure message
CC 100 => note - the note 0-127
CC 6 => x/y/z - the pressure type
CC 38 => value - the pressure value

This way there is only a minor extension and no breaking of current standards works with old equipment and no need for using multiple channels...

I'll apologise now if I have missed something fundamental in my reasoning..
Andrew

Further to my previous post if we want 14bit resolution
CC 101 => x/y/z - the pressure type e.g. 1 note pitch, 2 timbre, 3....
CC 100 => note - the note 0-127
CC 6 => Value MSB
CC 38 => Value LSB

As in RPN only CC 101 = 0 is currently used
Andrew

When will the MIDI MPE spec be made public?

When will the MIDI MPE spec be made public?

I was wondering that. The January 28, 2018 announcement says "The MPE specification will be available for download in the coming weeks." It is now March. It would be good to have the final spec to implement from, rather then the old preliminary spec.

Hi,

It takes a little while to get all the paperwork finalized between the MMA and AMEI, but all of that is in process and the specifications for both MPE and MIDI-CI should be available for download soon.

Sorry for the delay and we can only ask for your patience.

Thanks,

The MIDI Association