(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.