(though, we really need the same clarification on PBR , would need to check full CI spec)
I will note however, this is (and always has been ) problematic, as it requires bi-directional midi… and some controllers don’t have hardware to do this.
k, in fairness, midi 2.0 requires this anyway, but may cause issues with backwards compatibility with mpe 1.1.
anyway, good to see it clarified.
now this is looking a bit more mature, I might download full spec to check out the details.
though without a wide range of daws/synths supporting, kind of feels pointless to start working on.
I’d also like to dig into the other parts of midi 2.0 that support per note expression, which could make mpe much less relevant.
Well in the full spec for this profile, pitch bend range isnt sent as part of the profile negotiation. Its still handled via later MIDI messages, if required. It is mandatory for devices to be able to receive and act on such pitch config messages, but it is optional as to whether a device can send them. And those messages should only be sent on manager channels. 48 is the default to assume if no such config happens.
In regards backwards compatibility, you’d need to explain to me a theoretical problem scenario in order for me to grasp it. Generally with this side of MIDI 2.0, devices just fall back to bog standard MIDI 1.0 if they dont receive a resonse to one of the new fangled inquiries.
In regards the full per note expression stuff built into MIDI 2.0, that renders both MPE and this new MPE Profile obsolete if implemented, yes its of interest. However its probably a much bigger leap for manufacturers, both in terms of the nature of the messages but also the vast scope of possibilities in terms of how many dimensions of per note expression are possible, etc. So maybe thats a bit bewildering to start with, and involves far more headaches in terms of nailing down this detail between devices and what exactly they support. I suppose if I was developing a synth where most parameters in the synth can work directly on a per voice basis, or I made good use of very much higher resolution and other aspects of UMP in MIDI 2.0 etc, I’d be looking at how to go down that path. Its very unclear to me how quickly such products will arrive and I expect less scope for retrofitting these fancy new ways into existing kit. If I was just updating an existing MPE device that already had the normal MPE concepts baked into it, such as just a handful of per note dimensions, and especially if some parts of my data pipeline/transport/physical interfacing meant I couldnt make use of the new UMP format of MIDI messages, I would be looking to implement this MPE Profile thing instead.
Of course I have no idea how many companies will even retrofit the MPE Profile stuff. We know that from a customer satisfaction and support perspective, auto-config is an attractive proposition. It would make sense to implement it in devices that are still sold and supported, if their interface supports bidirectionality. But yes we do have the usual chicken and egg MIDI 2.0 thing going on, where some reasonably proportion of the ecosystem (including many DAWs) needs to support this stuff in order for it to all work. Which companies actually want to grasp the higher resolution stuff as a marketing etc opportunity also remains to be seen. I’m being told that more expressive stuff is going to be baked into more forthcoming mainstream synth products this year, building on poly aftertouch having become more normalised in recent years and going further, but until I see the product details for myself I cannot factor those things into my thinking. eg whether its ‘somewhat watered down MPE for the masses’ or something that tries to go further than we’ve been used to, I cannot say, and wait with interest to find out whether any of that is relevant to this conversation.
Anyway if I revisit my old ‘write a converter to turn Haken/Osmose MPE+ into the new standard of higher resolution messages’ then I’m pretty confident it will be a hell of a lot easier to do that by using the MPE Profile than going down the full on MIDI 2.0 per note controllers route that was the previous option on the table. But as ever I still need a compelling synth to exist that makes use of this stuff in order for me to be motivated to bother trying. And I’d only be doing it as a stop gap/proof of concept pending the Osmose etc hopefully getting such support directly itself one day, if any of this stuff catches on. I also remain skeptical as to whether the extra resolution really adds much to expressivity from the likes of the Osmose in many playing scenarios, but then getting to test that skepticism and replace assumptions with actual experience is one of my motivations for bothering to try this.
Things I am still waiting on before bothering with such a prototyping mission:
More 3rd party MIDI libraries with 2.0 support. Although if I go down the profile route rather than full on MIDI 2.0 UMP, I probably have far more existing 1.0 options I can wrangle.
Waiting to find out which aspects of MIDI 2.0 Rolf from Waldorf is putting in the next Quantum/Iridium firmware.
Waiting to see if anyone else pleasantly surprises us, especially on the soft synth and DAW front.
If nothing happens with the right combination of the above within a timeframe that suits me, eventually I probably will get round to testing what the higher res messages from the Osmose are actually like by hooking them up to some visual software instead of audio software. Using Open Sound Control as the bridge instead of MIDI 2.0. That will be quicker to achieve and I will be able to rule out the possibility that my brain isnt good enough to easily tell the difference via sound, and also rule out any potential impact that long established normal practices of signal smoothing/slewing are having on any particular synths handling of higher res messages.
In my HC One VCV Rack plugin for Eagan Matrix, I send 14-bit resolution for the controls that support it (Macros, and Volume (= Post level). It does make a difference - 7-bit is audibly steppy, and 14-bit is much smoother. It’s unfortunate that the Recirculator controls are just 7-bit. So for the Eagan Matrix, I can say that the resolution does matter.
Beta firmware is now available for the Waldorf Quantum & Iridium family of synths that introduces some MIDI 2.0 support.
Sticking to features of relevance to this particular thread, there is initial support for high res velocity, poly pressure (poly aftertouch), per-note pitch bend, and various other high res stuff that is not per note (normal global pitchbend, mod wheel, cc’s). In the initial beta version there is not yet support for other per-note controllers that MIDI 2.0 supports, so we dont have an equivalent to MPE Y/Slide (CC74) and many more per-note dimensions of expression just yet.
I did some basic initial testing of this stuff using a few pieces of software on a mac to send things like MIDI 2.0 poly pressure and per-note pitch bend to an Iridium. I used Multitrack studio and Woodtroller for these initial tests. The tests were successful. If time allows and the right plan pops into my head, I will likely start to develop some software of my own to make further use of this side of MIDI 2.0, now that I have a hardware synth that can actually make use of it.
The latest Yamaha Montage has full MIDI 2.0 support, and Roland has an 88-key controller that supports MIDI 2.0 UMP output. Pete Brown has been using these for testing the upcoming MIDI 2 support in Windows.
I still get some MPE issues with my Waldorf Idirium (havent double-checked whether its my setup, but its more likely the continuation of some longstanding Quantum/Iridium MPE bugs) so I started writing an MPE to MIDI 2.0 converter. So the stuff that normally uses MPE multiple channels is converted to use the non-MPE MIDI 2.0 version of stuff, ie the per-note pitch bend, pressure and per-note cc’s on a single MIDI 2 UMP channel (although initial Waldorf beta doesnt support the per-note cc’s yet so Im not doing anything with MPE Y/Slide yet). Initial results are very promising indeed. To make this mission easy, given the current state of libraries to make MIDI 2.0 programming easy, I’ve ended up doing it on a mac, written in swift using the MIDIKit library. Next I will probably take advantage of higher resolution MPE+ from Osmose to turn that into MIDI 2.0 as well.
On the ‘not per note’ front, I’ve also dabbled with some Open Sound Control to MIDI 2.0 converter code (same dev environment as before, but with the addition of OSCKit), so I could take the output from a LeapMotion 2 using GECO to send OSC to my app, and turn it into high res MIDI 2.0 cc’s. This was a success too, although my arms get tired quickly when using the Leap Motion so I might not go far with this. Anyway I successfully sent the MIDI 2.0 cc’s to the Waldorf, because it does support MIDI 2.0 cc’s already, just not per-note ones yet.