#1

I’ve been working with MIDI since about 1984 or 1985, including both hardware design and software development. Some time after 1987, I bought a used Casio MG-510 MIDI guitar and learned about Mode 4 and its ability to allow independent pitch bend of separate synthesizer notes on each string of the guitar, while also allowing global controls that affect all channels. It seems that Dave Smith imagined the possibilities way back at the beginning of MIDI - possibilities that are finally becoming available in many forms today.

What I don’t understand is all the buzz today around MPE. I have read the specification many times over the years, and while it does seem to be improving it also seems to miss out on many of the features that already exist in MIDI.

I could get into feature-by-feature details of how “MPE” already exists without requiring any changes to the original MIDI 1.0 Specification, but I think I’ll leave those details for later articles in this thread.

Instead, I’ll start with one basic question:

Why isn’t everyone simply using MIDI Channel Mode 4 for all of the multi-touch pressure-sensitive controllers that are on the market today?
In other words, what does Mode 4 lack that is (a) absolutely necessary for MPE, or (b) even marginally useful.

To illustrate my perspective, I should point out that I demonstrated the Soundplane for the second time in 2012 at the Mostly Modular Trade Association event called the “Synth Petting Zoo,” connecting to an Oberheim Matrix-12 synthesizer via MIDI. With the configuration that I set up, the Soundplane was tracking 10 independent touches and controlling pitch, volume, and timbre independently for 10 of the analog voices in the Matrix-12. Mode 4 was used for its note-per-channel support; channel pitch bend and channel pressure were used for X and Z; while a standard continuous controller was used for Y (I think it was CC1 or CC7). The advantage here was that I was able to work with a synthesizer that was designed and manufactured in 1984, and yet was able to access all of the potential of the Soundplane without sacrifice.

Can anyone shed light on what MPE brings to the table?

Brian Willoughby
Sound Consulting

#2

I talked to Roger Linn about MPE last year at NAMM, and from what I can recall the main points of it are:

  • Standardize so that the first channel is a kind of “global channel” where global sound parameters / CCs are sent, but not really used for notes.

  • Notes are assigned to the remaining allocated channels.

  • Y axis is sent on CC 74

  • Z axis is sent via channel pressure.

  • Pitch bend range is 24

The main point seems to be that instruments and controllers can just have an “MPE” mode where all of this is set up automatically and they should Just Work [tm].

2 Likes
#3

I don’t really have any answers here, but I’m super interested in the discussion. Do you have any suggested references for reading about Mode 4?

2 Likes
#4

strictly speaking you can say MPE is unnecessary, Mode 4 is ‘nearly’ there (and Ive seen panel discussions where the ‘midi pioneers’ have argued this)

but if you stand back, and say you dont want to musicians/consumers to have to worry about midi protocols this is harder to defend.

Ive had an Eigenharp before MPE days, and at that time, I had to have various configurations to work with different synths, due to different PB ranges, or receiving ‘timbre’ on different CCs, using poly pressure, or channel pressure - the Eigenharp is great at this because EigenD its software has a massive configuration matrix. (see below for screenshots of a small part of the config) so was flexible for every situation, it worked (still does) , but frankly it was a pain when you just wanted to play :slight_smile:

do you want that level of complexity for all users? and this is nigh impossible for a strict hardware only device.

so MPE simplifies, +/-48 PBR, CC 74 , channel pressure, you just set MPE mode and off you go.
(number of voices and PB range are sent automatically from controller to sound generator)

mode 4, is strictly monophonic voices, MPE allows for polyphony on 1 channel (e.g. use 8 midi channels, but allow multiple voices of each channel … ok, you loose note independence but its allowed)

global channel - EigenD allowed for this too, but for many synths, they didn’t understand this, this meant something like a ‘breath control’ would have to transmit the same data on all channels (so redundant data).

mode 4, doesn’t have any provision for splits

I also think some of it is ‘marketing’, especially since Roli got into the driving seat on the spec. the manufactures needed a way to communicate what expressive midi was, and what it required of synths… i.e. if you say you synth/VST is MPE compatible, it implies you can just plug it into your Seaboard/Soundplane/Contrinuum/Eigenharp etc.

Im not saying MPE is perfect, it definitely has its flaws… and who knows if the MMA will ever ratify it, but at least its something to ‘rally behind’

btw: Id point out the newer 1.25a MPE spec - its details have changed quite a bit from the original spec, that many saw.

Screen Shot 2017-03-17 at 12.57.20.png1096×534 250 KB
Screen Shot 2017-03-17 at 12.57.50.png240×587 37.5 KB

3 Likes
#5

Thanks for the screen shots (interesting to see high resolution velocity supported) and details, @TheTechnobear.

It seems that the best path to success would be for “MPE” to be a combination of a settings template and promotion of certain optional features of MIDI 1.0 to be required. I believe that these two pieces would completely satisfy the need to facilitate users not having to worry about the details.

Things like PB range, specific CC mappings, et cetera, would be part of a couple of templates. Even within the MPE text, it’s clear that support for both standard resolution pressure (via Channel Pressure) and high resolution pressure (via CC or perhaps a new high resolution pressure standard) needs to be available, which means users would have to pick from two or more templates depending upon the resolution of their controller (and perhaps based upon the support in their sound module, unless MPE were to require support for all templates). The community could even build templates for common MIDI sound modules.

As for the other aspects, a requirement to support Omni Off mode would allow both Mode 4 (mono) and Mode 3 (poly) to work for “MPE.” The only catch is that MIDI 1.0 made Omni Off optional, such that any given sound module is allowed to map one or more of the 4 Modes to a different mode if the synth doesn’t support the one requested. I would prefer to see MPE not change these modes - since they’ve already been defined - but merely to require that the synth have full Omni Off support in order to qualify as “MPE compatible.” This supports more hardware than defining new modes.

Similarly, the support for Global Controllers on the lowest channel number is also something that is already part of MIDI 1.0 - although it’s obvious that not all synths support it. Rather than have MPE define yet another way of doing global controls - such that there would be two methods that might be unsupported by a given sound module - why not have “MPE” adopt the original MIDI 1.0 Global Controller channel (as Basic Channel - 1, wrapping to Channel 16), but change it from optional to required? Reusing the existing standard means broader support than creating new standards, because a new standard will only work with new software and new hardware.

I believe that the MMA will ratify some sort of “MPE” if it supports existing hardware in the field. As I mentioned, the 1984 Oberheim Matrix-12 works just fine as it is, but would not work with the proposed 1.25a MPE draft. If the folks behind MPE can let go of a few arbitrary choices, it would be possible to define an MPE that works with older MIDI 1.0 gear and still have every single feature that makes the promise of “MPE” easy for musicians who don’t want to dive into settings details.

#6

Roger Linn recommends using the Linnstrument with Logic’s mono mode (mode 4, essentially) in Logic’s built-in synths. So I guess I’m not clear on what it is about MPE 1.25a that would prevent it from working with a Matrix 12. My perception is that MPE is kind of a subset of MIDI mode 4, with some optional extensions.

What am I missing about MPE that breaks backward compatibility?

1 Like
#7

Hi Kevin,

Grab a copy of the MIDI 1.0 Detailed Specification.

The following page numbers are from Document Version 4.2, September, 1995, available as a PDF from MIDI.org, although I’ve been reading my purchased print copy, which is Version 4.1.1 of the document.

Overview (Section 1)
Channel Modes pp. 6-8

Details (Section 2)
Control Change pp. 11-12
Channel Mode Messages pp. 20-24

Appendix
Voice Assignment in Poly Mode p. A-4
Release of Omni p. A-5

Tables
Table IV - Channel Mode Messages p. T-5

I will admit that even though I thought I was completely familiar with MIDI 1.0, I still learned a few things about Global Controllers and other relevant parts of the standard by reading the MPE proposal side-by-side with the MIDI 1.0 Specification, Document Version 4.1.1 (and I should study 4.2 to see whether there are any relevant changes). It’s really worth studying MIDI 1.0 to become familiar with everything. There are also additions to MIDI that are available as separate documents on the MIDI.org site, e.g., the High Resolution Velocity seen in TheTechnobear’s screen shot.

#8

Good question. MPE intersects with Mode 4, but it’s definitely not a strict subset (which is really my only complaint - some of the options remove parts of Mode 4).

MPE insists on CC70 and CC74 as 14-bit controls, when those are technically limited to 7-bit controls by MIDI 1.0 (better choices would be any of the undefined 14-bit CC numbers such as CC3, CC9, CC14, CC15, or CC20 through CC31, if new CC assignments are desired).

The Matrix-12 only responds to CC1 and CC7 or CC64 in addition to the standard Pitch Bend and Channel Pressure. Both CC1 and CC7 have the option of 14-bit support in MIDI 1.0, but MPE goes off into outer space by choosing CC70 and CC74. This is related to my suggestion of having templates, since it probably isn’t possible to pick a single pair of CC numbers that work everywhere - I’m merely pointing out that picking 7-bit CC numbers for 14-bit values is certainly not going to work anywhere without modifying MIDI parsers. I actually think that there would be more benefit to having (per-note) CC1 as the default for the third axis instead of a new CC number, but I’m not really bothered if another 14-bit CC is the standard.

Another problem with MPE is that it redefines the Global Controller channel to be slightly different (invalidating Global Controller channel 16) than the Mode 4 Global Controller in MIDI 1.0 - I don’t know whether the Matrix-12 actually implements the original MIDI 1.0 Global Controller channel concept, but I’m certain that no existing hardware implements the MPE alternate.

If we make the assumption that MPE will only be supported by new releases of software based MIDI sound modules, then I guess it doesn’t matter how much we deviate from the original MIDI 1.0 specification. But as soon as we want to support existing hardware, arbitrary mappings and other changes just make things needlessly incompatible.

MPE 1.25a also insists on Mode 3, not Mode 4. I just noticed in reviewing all of this that MIDI 1.0 missed the boat by defining the Global Controller channel for Mode 4 only. Despite the fact that the MPE draft admits that Poly Mode 3 defeats the per-note feature, I still think it’s a valid suggestion to the MMA that they approve Global Controller channel concepts for Mode 3 in addition to Mode 4. That would effectively mean that the Global Controller channel is an Omni Off feature, not just a Mode 4 feature. While I think that Mode 4 will be all we need for 99.9999% of multi-touch per-note expression, there’s no harm in extending the Global Controller concept to both Omni Off Modes - so long as it’s not changed from the MIDI 1.0 spec in a way that existing Mode 4 support would need to be revised. Personally, I think Poly On makes no sense for MPE, but as long as Mono On Mode 4 is supported without changes, I have no problem with adding the slight flexibility that Mode 3 offers in certain cases.

#9

I believe most implementations have made this optional.

Again, as far as I can tell, this global controller channel is optional in the implementations I am familiar with.

Unless this perception is based on working with actual implementations, I’d advise caution against getting too upset about this. The MPE controllers I’m familiar with that have DIN cable support appear to work just fine (in one way or another) with legacy instruments. Then there’s the Roli instruments which use MIDI over USB, so they’ll need a computer in the chain anyway (at which point remappings are possible ITB).

Shrug. I’m a player, not a manufacturer, so I guess I’m less excited about specs, and just grateful that instruments are getting more expressive.

#10

I have both the Linnstrument and Continuum, they’ve worked just fine with all the gear I’ve tried them with. Even better / easier with computer software. I think the number of people who own a Matrix 12 is relatively small, and the number of people who would use one with an MPE controller even smaller, so it’s probably not a huge concern if it doesn’t work out of the box.

#11

I did not intend to present the Matrix-12 as any sort of golden standard. My whole point is that MIDI has stood the test of time for over thirty years, and there’s no sense breaking things that could work. I merely used the Matrix-12 as an example of the oldest piece of gear that I know of that works with per-touch expression (because of MIDI being designed in a forward-thinking manner).

In other words, I’m not suggesting that MPE should be designed to fit the Matrix-12, but rather I’m suggesting that MPE should not break conventions in MIDI that already support per-touch expression.

By the way, I’m pretty sure that Roger Linn is following the MIDI spec.

#12

And his instrument works with MPE. So, no problem then?

#13

reading your comments @rsdio , I think demonstrates the real issue with the MIDI spec…
there are so many additions, annexes, and interpretations, that once you venture off the simple note on/off, cc etc, support by manufactures becomes pretty patchy… and that excludes those that go ‘off-piste’ with the spec.

you mention the Matrix-12 supporting mode 4, but how many others synths support it? what market % is it?

I think the likes of Roli, who are aiming at the consumer market, really just want a ‘MPE ready’ label, a plug and play experience, this is (slightly) in conflict with your model of ‘alternative/templates’. Its an argument of simplicity rather than purity.

(I think for Roli, lack of splits in mode 4 is important for there bigger keyboard, where you really expect it)

I will say most expressive controllers support a lot of configuration options, so that you can use with synths that don’t support MPE. they are being pretty pragmatic… Ive not had an issue personally.
(ok, I admit, I had to fork the soundplane s/w to do this, as that went 100% mpe)

#14

I don’t see how there is a lack of split capability in Mode 4. See page 7 of the MIDI 1.0 document. The way MIDI supports splits is called “Multi Mode,” and it allows for more than one MIDI receiver on a bus. Each “virtual” instrument has its own Basic Channel, and thus each physical device can have one or more virtual instruments, each operating in its own mode. Channel Mode 4 commands are sent to the Basic Channel of a virtual instrument, and the data parameter sets the number of voices. So, not only is a split allowed, but you can even have more than two zones.

My first keyboard, the EPS, allows up to 8 overlapping zones across its polyphonic aftertouch keyboard. What part of this existing capability is insufficient for Roli?

The MPE proposal is only compatible with a single MIDI receiver. As soon as you add a second sound device, the MPE-proposed messaging breaks down. To get into the specifics, MPE 1.25a wants to add a new Registered Parameter Number that will create a zone. But RPN is a Channel Message, and thus there’s no way to target this zone creation to a single device. In effect, the MPE-proposed RPN is adding a way to change the Basic Channel. Or, to put it another way, MIDI devices that follow the MIDI 1.0 spec will ignore any Roli zone split that isn’t on its Basic Channel.

If you look at page 20 of MIDI 1.0, you’ll see that the only allowed ways to change the Basic Channel are by hard wiring, front panel controls, or System Exclusive messages. I think Roli has a great idea that could potentially make things easier for musicians, but they need to change their zone split message to a SysEx if they want the MMA to ratify MPE. The concept would work equally well, and there are already Universal System Exclusive messages that are valid for all manufacturers. Using a new RPN simply doesn’t work.

I totally agree that splits are important. They’ve been part of MIDI since the beginning. I even agree that there is room for improvement. I just don’t think that the MMA is going to break several existing conventions by allowing an RPN to change splits when they’ve already outlined other ways to do this in MIDI 1.0 as it exists now.

#15

It’s not that simple. The MPE draft proposal is a rather large document that suggests many changes and additions. Some parts are great improvements, other parts conflict with MIDI 1.0 - so I don’t think it makes sense to adopt the entire thing just because some new products are compatible.

I get the impression that the software developer for the LinnStrument has a very good understanding of MIDI, and thus I assume that the product doesn’t violate the MIDI 1.0 specs.

It’s very likely that the LinnStrument is compatible with both MIDI and MPE, but it doesn’t implement the problematic parts of the MPE proposal.

Don’t get me wrong: I think it would be very useful to have a ratified specification that clarifies MIDI to improve interoperability. I just see that MPE hasn’t been ratified, and when I look at the details I can see why. I’m merely suggesting that there are ways to achieve everyone’s goals, but the ratification process needs to take all of the specific details into account. It’s not enough to look at the whole thing from a simple, high-level view and get it ratified. Even though the final goal is to have something that is simple and doesn’t require too much attention to detail, the design phase has to be very detailed. I don’t think MIDI would have lasted over thirty years otherwise.

#16

I assume MMA has a forum for the purpose working out these issues?

#17

Yes. I’m here to learn about how people use controllers other than the Soundplane, to make sure I’m aware of more use cases than my own experience.

It’s helpful to hear from folks like yourself who are using Logic in mono (Mode 4) mode with controllers like the LinnStrument. I have Logic Pro 8, so I should try it with the Soundplane.

#18

There are a few Haken Continuum users here.

I’ve used a seaboard, but it is probably the least MIDI compliant MPE instrument of the bunch.

Linnstrument, Eigenharp, and Continuum are probably the best MPE controllers for use with legacy MIDI instruments.

1 Like
#19

interesting, I didn’t know there could be more than one basic channel, and also that it could be changed.

but still, mode 4 is monophonic in the spec, not polyphonic, and mode 3 does not allow for the number of channels to be specified. Id suspect then MMA might be reluctant to alter the definition of mode 4.

it doesn’t standardise ‘timbre’ (Y) and doesn’t deal with pitchbend range (which is vital for continuous pitch) …but yeah I could see this could be just defined.

(Id avoid sysex, its a bit of a band aid solution… few want to handle sysex from another manufacturer)

It would be interesting to know where the proposal has got to, it seems to be between the MMA and Roli, so perhaps they are already hammering it out, and once thats done we will get a revised MPE spec.

on my part, for both Axoloti and EigenD, I decided not to update to the 1.25a spec, and rather wait until the MMA have had their say… as such, I don’t really mind, its pretty easy to change, once its agreed.

1 Like
#20

This is an important MIDI concept, and it’s what allows multiple receivers to share the same bus and still react uniquely. The whole Multi-Timbral concept starts with multiple virtual instruments that each have their own Basic Channel. But, if MIDI didn’t require the Basic Channel to be controlled in a specific way, then all instruments would respond to the same channels. It’s sort of a chicken-or-egg problem, and I think MIDI 1.0 solved it in the only way possible.

It’s a very interesting situation. I agree that it might make sense to add the number of voice channels to the Poly On (Mode 3) message, but I also think it’s moot.

Here’s why: In order for the Channel Mode messages to work, the receiving device must already be set to the matching Basic Channel. If you want a zone/split, then you need two virtual instruments, each with its own Basic Channel. But in order for that to work completely, you must have already set each Basic Channel to the start of the zone, leaving a channel for the Global Controller (Basic Channel - 1). By the time you set both Basic Channels properly (and MIDI requires that this be done in one of three ways), you don’t really need to set the number of voices any more. It’s like there’s not much difference between setting the number of voices explicitly or just sending “0” to mean “all” of the voices (in a virtual instrument). This could all be clarified, but it’s there in MIDI 1.0 already.

Regarding Pitch Bend Range, I really like this part of the MPE proposal: Clarifying that Global Controller Bend Range is set by a RPN message on the Global Controller channel (Basic Channel - 1) and per-note Bend Range is set by a RPN message on the Basic Channel (and affecting all voice channels). If you read MIDI 1.0, it’s arguable that all of this is strongly implied, even if it isn’t clearly spelled out. Thus, I think it’s a great idea for MPE to spell this out explicitly. Since this part doesn’t conflict with MIDI 1.0, there’s a great benefit to having “MPE” mean that support is required rather than optional.

I know that SysEx seems to be manufacturer-specific, but there is already the Sample Dump Standard (SDS) and other features of MIDI 1.0 that are handled by Universal System Exclusive (which are not manufacturer specific). Since it is specifically called out as one of the three ways to change the Basic Channel, then it seems to me that all the MMA needs to do is follow up on that and define the exact message format for everyone to use. Maybe it’s already around in one of the MIDI extensions and I’ve missed it.

There’s a lot of good stuff, here. It just needs to be ironed out.

1 Like