Loopy Pro: Create music, your way.
What is Loopy Pro? — Loopy Pro is a powerful, flexible, and intuitive live looper, sampler, clip launcher and DAW for iPhone and iPad. At its core, it allows you to record and layer sounds in real-time to create complex musical arrangements. But it doesn’t stop there—Loopy Pro offers advanced tools to customize your workflow, build dynamic performance setups, and create a seamless connection between instruments, effects, and external gear.
Use it for live looping, sequencing, arranging, mixing, and much more. Whether you're a live performer, a producer, or just experimenting with sound, Loopy Pro helps you take control of your creative process.
Download on the App StoreLoopy Pro is your all-in-one musical toolkit. Try it for free today.
Comments
@SteveElbows OK, I stand corrected, apologies. I think it's still true to say that the MPE spec changed significantly / was published around 3 years ago:
https://forum.loopypro.com/discussion/50175/midi-polyphonic-expression-mpe-version-1-1-released
I think my observarions about mono mode etc., stand.
Perhaps it's better to say there wasn't really an official spec prior to this?
For sure peoples MPE implementations vary in terms of how sophisticated they are. On paper MPE has always supported more than one note per MIDI channel, so the bit you highlighted is not new to 1.1. Although you then lose the ability to modulate shared voices on a particular channel independently of each other. And naive implementations will still just assume one voice per channel. Which in most situations that people are actually using MPE in, turns out completely fine. Especially for synths that have less than 16 voices in the first place.
As a developer you are of course entitled to judge this stuff however you want, but I can tell you that wording changes in 1.1 did not stand in the way of an increasing number of MPE synths arriving on the scene as the years went by. And in terms of user satisfaction, the stuff you highlighted has rarely ever come up. People are usually content with basic MPE support, and complaints usually revolve around how the user interface for assigning the MPE expressive dimensions to mod destinations has been done by a given developer, or certain developers missing out support for one of the MPE expressive dimensions completely, or hard-wiring it to a particular destination. Or critical bugs that spoil the baseline MPE functionality.
The configuration message isnt new either, and people are also used to apps that dont support that aspect at all. People are used to matching channels, MPE pitch bend range etc configuration between their synths and their MPE controller manually themselves.
Yes, I see the configuration message been in that spec since 2018 (when it was first published) but it was new to me, and pretty scary looking. I'd misread the 1.1 annoucement from 2022 as the whole thing being new.
The rough timeline was that a draft MPE spec came out in 2015, and in the intervening years quite a lot of people started using it, long before it was formally ratified and published via official MIDI spec group in 2018. I wont try to pick apart the detail of the revisions during 2015 or later, but I believe the most significant changes happened early in 2015, so most developers wont feel like they have been dealing with moving goalposts in the MPE era.
The configuration message is probably not even known about by some users either, given that they cannot rely on it being implemented. I could perhaps say a similar thing about the lower zone and upper zone concept, since quite a lot of synths exist that pay no heed to that stuff at all. The bog standard assumptions are usually based around a single lower zone, where channel 1 is for global messages and the other channels are used for the MPE voice channels. Some synths (usually hardware ones) that have less voices also use a fixed range of MIDI channels to match. For example the Sequential synths that support MPE and have 6 voices, only listen to channels 2-7 for MPE notes. And users are told to set this stuff up manually on their MPE controllers. 48 has become something of the standard assumption when it comes to pitch bend range, but MPE controllers and synths usually still allow users to change that when necessary. Some DAWs such as Ableton make assumptions about 48 being used for MPE, and you have to jump through a few hoops to get round that if required.
As for the future via MIDI 2.0, we have yet to see which parts of MIDI 2.0 catch on and are widely adopted. That spec actually offers 3 different routes to handle this sort of per note expression: 1) The same MPE as we already have in MIDI 1.0. 2) A slightly modified form of MPE that still uses multiple channels, but features a few additions such as the possibility to increase the resolution by using a few pairs of messages for the expressive per-note signals. 3) The completely new MIDI 2.0 UMP way of sending high resolution per note expression signals, of which there can be very many rather than just a few, and there is no reliance on having to use multiple MIDI channels to achieve this.
The latter which I labelled 3 above obviously has far more potential and makes sense, but also poses some questions about support and interoperability. By this I mean that the limitations of existing MPE do provide a more modest target for developers to hit, rather than a somewhat daunting, almost open-ended landscape that MIDI 2.0 per-note expression provides. ie there is quite a difference between developing an instrument where you know there are just a handful of per-note dimensions of expression to deal with, compared to a potentially huge number. It is plausible that this will eventually be dealt with via the MIDI standards people agreeing on one or more 'profiles' which define a more limited subset of specifications for stuff like the per-note expressivity signals, and how many of those an instrument should support when offering support for the profile in question. Theres also quite a lot of ongoing MIDI 2.0 work going on in areas such as the DAW and plugin side of things, where common paradigms and use of language need to be developed on top of the main 2.0 specification. So it might be a very long time before we see much action on this front, and meanwhile MPE retains the advantage of being reasonably widely supported these days.
Actually I slightly botched that 2.0 explanation because when I started going on about Profiles, the thing I labelled as (2) is also achieved via a MPE Profile that they already ratified last year. So my use of language may cause confusion. Multiple versions of (3) that restricts things to a more limited subset of all that is possible with UMP per-note messages could still be done via further Profile(s) in future though, but those will be scenario-specific and likely wont have MPE in their name.
Anyway even when talking about the (2) MPE Profile, things quickly get more complicated than you'd have to deal with to offer the sort of MPE support people are used to at the moment. This MIDI 2.0 version of MPE allows multiple zones rather than just a lower and upper zone, allows optional use of higher resolution, involves even more automatic configuration messages and bidirectional communication, and allows for way more than 16 channels (since MIDI 2.0 supports 16 groups of 16 channels per group). And some other complicated stuff that I have no intention of attempting to describe right now. It does remove certain ambiguities and could make life easier for developers in some ways, but only once support exists for it in MPE controllers, since those controllers are expected to adhere to the messages that synths etc send to them as part of the auto-config process. To give just one example: "The Profile is receiver centric. The receiver will report back the range of Channels that it can support, and the Sender will adapt."
wow @SteveElbows, interesting stuff - thanks for sharing that.
This also explains (but doesn't really excuse...) my very limited understanding of MPE as simply being channel 1 being a global channel, then say 2-9 for an 8 voice poly. And... I'm sure when researching this, I'd found so many technical guides online limited to literally just that as an implementation spec, hence the whole thing about zone config messages etc., being a bit of a suprise / shock to me this year. I guess much of that stuff I'd consumed was written during the period from 2015 onwards... Quite why I didn't end up getting the real thing via MIDI.org, I don't recall.
I've often been left with the impression that many developers did similar, or just took the basics or what other developers had done before them and ran with that. In many common situations these 'relatively naive' implementations still end up doing exactly what users require, and so there isnt that much impetus to get bogged down in the extra tedious detail of the formal spec.
And honestly I think its still really rare to see soft synths that give zone options at all, most dont even give channel range options. Im not sure I can think of any iOS examples that do off the top of my head, and on desktop the only ones I can claim with confidence do offer zone and channel range options are ones by Arturia. I suspect this is because of a combination of the above reasons, but also that most of these synths dont have the same voice quantity limit as you are talking about, or if they do, they handle it in traditional voice allocation ways not specific to MPE, rather than handling it by only listening to a more limited number of MIDI channels. There are probably customer support reasons why it may be better to do that as well, so you dont get users who are using MPE controllers that may be outputting to the full channel range of 2-16 complaining about some missing notes. So perhaps that is one example of where the most naive MPE implementation possible may be going a bit too far in the naivety department!
Another possible reason that soft synths may not bother with those options is that they assume that when people want to mess around with different zones, they might do it via any zone functionality built into the host DAW. Some DAWs dont have their own fancy MPE support, they just pass all channels through to the plugins, but some such as Ableton do have options that let you specify a zone and channel range per plugin if required. One reason why DAWs like Ableton had to add that functionality is that they also mess around with the channels all the notes in MPE tracks may use, rather than just using exactly the same channels as the MPE controller was originally sending. Presumably they do this to cater for a situation where someone may want to overdub MIDI recordings from a MPE controller in MPE tracks. ie allow a track to be built up in layers of multiple takes. The same MIDI channels could end up being used for more than one note at the same time in that scenario, as more layers are built up via overdubbing, especially if the MPE controller being used always starts off by using the lowest available channel for the first note that is held down. By dynamically reallocating the channels used by each note in the recorded MIDI tracks, Ableton gets around that issue. And this also caters for people manually drawing MPE note etc info into the timeline, so that people dont have to think about specifying channels at all when doing that. But then the DAW developer has to add their own options that restricts the range of channels that come out of these tracks and go to MPE instruments, since the channel settings used on the MPE controller itself cannot be relied upon due to the dynamic reallocation performed by the DAW. There is a definite split between desktop DAWs that have their own MPE layer that does this sort of thing, and those that just leave the MIDI alone and pass it all through. On iOS its fairly rare to even find a host that explicitly acknowledges having MPE support, so most that do happen to end up supporting MPE fall into the latter category, they are just passing everything through on every channel being sent by the MPE controller.
Posted to wrong thread. Sorry folks.