Oooh, I missed that! Cool! I’d prefer IP and integration with existing standards personally, but that’s in part because I have existing installed infra — I wouldn’t turn up my nose at something like that becoming ubiquitous, and it can always be gatewayed.
I’d really prefer to avoid wireless, though. I know in a lot of studio contexts it would be great, but I just don’t trust it live, and avoid it on anything that doesn’t absolutely have to be wireless. Wires are nice and predictable.
From what I can see Midi 2.0 is still not released on Windows. On their tech blog Microsoft had a tentative schedule to release the first version by the end of 2023 but they are a bit behind which is not unexpected.
Once it does I can see a lot of possibilities. For instance, I have Novation Remote SL which I bought in 2007. It had a technology called Automap which tried to do some of the same things as parameter exchange. Support is long gone and Automap has been end of lifed, but what makes it interesting is that they publish the API spec to interact with the LCD screens and features of the device.
Once Python on Windows has support for MIDI 2.0 I think it would be very possible to create a MIDI 2.0 bridge to this device. So python would talk to the MIDI 2.0 instrument/plugin and serve as the gateway to the Remote SL which was discontinued before MIDI 2.0 even came into existence.
I think this bridge concept could be used for any controller which supported screens above encoders AND allows API programming interaction. Just need someone motivated to create the software bridge.
Ableton Live does something similar with the SL Remotes - the Ableton parameter names update on the Remote screens despite Automap being discontinued. I believe this is because Ableton has implemented the Remote API within a MIDI Remote Script.
Going off topic but good to know! Have an SL compact keyboard lying around. And a Push 1 for that matter.
I see that Waldorf is adding MIDI 2.0 support to the Iridium and the Quantum. Looking for more detail about this.
( NAMM post )
I watched that NAMM 2024 MIDI video. It’s strange to me how much they focused on high resolution of velocities, and spent so little time on property exchange. It was vaguely referenced once in passing, as if it’s not the killer feature of MIDI 2.0.
The Windows roadmap definitely had MIDI 2.0 slated for the end of last year, subject to change… and they’ve now given themselves to the end of this year to ship it. To gain very wide adoption this is just something we need, and really it can’t come soon enough. I think MIDI 2.0 could really take off once it happens.
I guess we’ll just have to wait and see, I am feeling impatient though and want it all to come faster.
I think high resolution midi cc is the best part of midi 2.0.
Property exchange is nice to have, but I can imagine it will only work so so, as everybody probably wants to customize the parameters they control anyway. Only when you have a midi controller with lots of dedicated controls for specific parameters, or a controller like Push where banks of multiple controls are selected with buttons, it would make sense. But for the current Korg Keystage, I don’t see any benefit of property exchange.
I see plenty of benefit. Just not as much as if it had encoders and maybe LED rings.
I think both resolution and property exchange are killer features.
I have faith that the controllers are coming. Definitely not here yet. We need loads of controls like endless encoders, faders, knobs, and buttons all with little screens or display strips so it can tell you what’s being controlled and the value.
The interface should make it very easy to move things around. It will save templates so you can easily recall. It will have the ability to easily cycle through many connected instruments and dynamically change seamlessly. One controller interacting with all your gear.
This is the future I want to see and perhaps Arturia or Novation will get us there.
so far my impression about MIDI 2.0 is that it was invented for customers to bother both hardware and software vendors about MPE support.
however, i don’t hear any real-world benefits of MPE. 
With all due respect, it is my impression that you are wrong on both accounts. But you are of course entitled to your opinion.
I remain skeptical in my lack of faith in it being adopted as a standard properly. I mean even midi 1, which of course is much simpler, still isn’t always implemented properly, for example there are still some companies insisting on using type B TRS, or not implementing note off handling correctly, or midi clock etc.
Midi 2.0 obviously adds a whole lot more complexity, I don’t have the optimism that companies will adopt everything properly.
Hopefully I’m wrong and just being overly cynical.
I’m very excited about the concrete improvements we’ll see with Midi 2.0 and not at all concerned that it’ll be a “meh” sort of thing after it happens. It will take time for all companies to implement it well, but ultimately it’ll provide a ton of functionality that’ll really improve our quality of life in the studio.
I appreciate very much that there’s a lot of focus on getting manufactures of both DAW’s and gear involved from the start and that it’s been a very deliberate process. It’s not going fast, but I can’t imagine there’s much, if any, money pushing this along, so it’s likely a lot of true believers putting in the time because they know it’s important.
My personal hope is that Midi-based timing gets somewhat more reliable/tighter, but in reading over some articles posted earlier in the thread, it sounds like jitter can be significantly improved upon, but latency will continue to be a bottleneck that goes beyond what Midi could solve within the spec itself. But still, a more robust standard that can offer more information and perhaps help to simplify timing problems and solutions is still a step in the right direction.
I’ve got nothing but optimism and hope around Midi 2.0 coming along. I enjoy reading the little updates as we move closer and closer towards it’s birth.
Historically, I think a lot of folks were implementing the spec from scratch. I’m guessing that for 2.0, we’re going to see a few open source implementations in different languages that get ported to whatever platform they need to run on, and manufacturers just using those. The way we develop software has changed a lot since midi 1.0, but I think the protocol dragged a lot of older practices with it. In a way, part of the problem was that it was so simple and every dev thought they could just bang out an implementation themselves — which they could, just not a fully correct one. That’s not to say that there won’t be plenty of midi 2.0 bugs too — it’s a complex new spec, after all — but they’re likely to be at a slightly higher level, once we get through an initial shaking out period.
I will say that it does have a bit of the smell of second system effect, though, as much as I do think it’s going in the right direction.
This is just me speculating, but maybe Electra One shows new MIDI 2.0 support at their Superbooth-booth.
Which also very well accounts for the room given with the new MkII hardware, with more processing power and memory.
The ERAE II configurable contact surface controller from Embodme is in Kickstarter right now and they are promising MIDI 2.0 support. ( See Q&A Video at 23:20. )
This should present some interesting challenges / opportunities in design. Do you get to set up surface elements that get negotiated in as you plug devices in ? It also has a host port so you could plug another controller into it, also potential a MIDI 2.0 controller. How this all works together with other systems seems an up in the air proposition, and at the moment i expect this to still be being refined at the target release date in September of this year.
I posted about the ERAE II over here.
Lemur
