MIDI 2.0 Means Two-way MIDI Conversations
MIDI 1.0 messages went in one direction: from a transmitter to a receiver. MIDI 2.0 is bi-directional and changes MIDI from a monologue to a dialog. For example, with the new MIDI-CI (Capability Inquiry) messages, MIDI 2.0 devices can talk to each other, and auto-configure themselves to work together. They can also exchange information on functionality, which is key to backward compatibility—MIDI 2.0 gear can find out if a device doesn’t support MIDI 2.0, and then simply communicate using MIDI 1.0.
Higher Resolution, More Controllers and Better Timing
To deliver an unprecedented level of nuanced musical and artistic expressiveness, MIDI 2.0 re-imagines the role of performance controllers, the aspect of MIDI that translates human performance gestures to data computers can understand. Controllers are now easier to use, and there are more of them: over 32,000 controllers, including controls for individual notes.
Enhanced, 32-bit resolution gives controls a smooth, continuous, “analog” feel. New Note-On options were added for articulation control and precise note pitch. In addition, dynamic response (velocity) has been upgraded. What’s more, major timing improvements in MIDI 2.0 can apply to MIDI 1.0 devices—in fact, some MIDI 1.0 gear can even “retrofit” certain MIDI 2.0 features.
MIDI gear can now have Profiles that can dynamically configure a device for a particular use case. If a control surface queries a device with a “mixer” Profile, then the controls will map to faders, panpots, and other mixer parameters. But with a “drawbar organ” Profile, that same control surface can map its controls automatically to virtual drawbars and other keyboard parameters—or map to dimmers if the profile is a lighting controller. This saves setup time, improves workflow, and eliminates tedious manual programming.
While Profiles set up an entire device, Property Exchange messages provide specific, detailed information sharing. These messages can discover, retrieve, and set many properties like preset names, individual parameter settings, and unique functionalities—basically, everything a MIDI 2.0 device needs to know about another MIDI 2.0 device. For example, your recording software could display everything you need to know about a synthesizer onscreen, effectively bringing hardware synths up to the same level of recallability as their software counterparts.
You are of course very welcome here and we appreciate your input! Please don’t be mad at people who disagree with you. If you think some statements are based on outdated information feel free to contribute your infos and arguments.
Let’s all discuss constructively and potentially agree to disagree.
Happy posting and music making!
I am a 64-year-old artist and professional scientist, my life has always been less about being right and more about being less wrong.
More than adequate information was indicated in the title and in the original posting.
The burden of proof is NOT mine but upon any rebuttal.
Official MIDI 2.0 Specifications
MIDI 2.0 is an extension of MIDI 1.0. It does not replace MIDI 1.0 but builds on the core principles, architecture, and semantics of MIDI 1.0. A foundational architecture for MIDI 2.0 expansion is defined by the MIDI Capability Inquiry (MIDI-CI) specification.
MIDI-CI allows Devices with bidirectional communication to agree to use extended MIDI capabilities beyond those already defined in MIDI 1.0, while carefully protecting backward compatibility. MIDI 2.0 is not a stand-alone specification. Manufacturers and developers must have a thorough understanding of MIDI 1.0 in order to implement MIDI 2.0.
Unlike myself, @greaterthanzero made declarative statements with no evidence. Nothing in English grammar suggests what he said was intended to further the discussion, but rather to dismiss it.
My post’s title clearly and unambiguously invites discussion. Can you point to anything @greaterthanzero said that adds value to furthering the topic’s discussion?
His bone of contention:
(Tools and resources that exist are proprietary, owned by companies who are rightfully more concerned with their own future than in helping us compete against them)
As if that precludes any further discussion, presuming only one specific form of capitalism exists, a demonstrably false assertion by virtue of the wide range of capital ownership types used successfully over centuries of custom, law, and practice in the US.
Moreover, there have always been degrees of proprietary and shades of open-source, with no clear lines of demarcation, why @greaterthanzero believes that is even relevant to a discussion on the current state of the art in MIDI 2.0 remains unclear.
There are legal instruments called intellectual property pools that are designed to smooth the path to collaborative rapid development between even the most aggressive competitors.
I have worked hard to create a fair, just, equitable cooperative organizational architecture that while not perfect, goes a long way towards remediating the dysfunctional patent and intellectual property law of the US.
Our cooperatively managed property pool also serves as a vehicle for the donation or purchase of licensing from outside the community, in a word, I offer cooperative capitalism, economic democracy for social democracy as a practical alternative to a world epitomized by Steve Jobs unhinged “I’m willing to go thermonuclear.”
To learn more: WIPO (World Intellectual Property Organization)
The global forum for intellectual property (IP) services, policy, information and cooperation. It is a self-funding agency of the United Nations, with 193 member states, their mission, like mine, is to lead the development of a balanced and effective international IP system that enables innovation and creativity for the benefit of all. An in-depth report on IP Pools, PDF format
About the original issue though, I believe in a free exchange of ideas as more than idle speculation as entertainment for idle curiosity. My studies led me to developed an organisational model of what is now called Participatory Action Research and Development within a cooperative cultural framework.
I seek out people without braces on their brains and who are willing to engage in an informed, productive discussion of how best to lead the target known as the future and contribute to our creation of tools that will serve them well.
Every minute I waste on people who don’t know the difference between being a sceptic and a cynic is a moment stolen from someone else whose imagination is capable of the heavy lifting and really deserves my encouragement and support. My question about remaining here was not about how I “feel” but a pragmatic valuing of time invested here.
“You never change something by fighting the existing reality. To change something, build a new model that makes the existing model obsolete.” ― R. Buckminster Fuller
I have invested considerable time and at no small cost in the collaboration to design and building an ecosystem that is only possible with MIDI 2.0. It is a series of guitar controllers, synths, effects, and amplification all in dynamic communication.
It is intended by design to continue being a self-sustaining enterprise while offering a platform where not all, but the majority of key features relevant to artistic expression, hardware and software, remain open and hackable.
I personally would prefer you toned down the drama a lot (I fail to read anything anything but a normal, civil conversation in what greaterthanzero wrote). Just my 2c. With that out of the way, I think most of us in here are very interested in midi 2.0, so I am sure your input and insights are very welcome.
My current (probably flawed) understanding of the state of Midi 2.0 is:
There is currently no hardware that use it. The a-88 is midi2.0 ready, but does not actually send/receive it.
Support is added to Mac OS core midi, but not windows. So hardware would need dedicated drivers on windows.
VST3 sdk v3.7 added support, but as VST3s don’t actually use midi at all, it will be the VST host that needs to actually implement the Midi 2.0 support.
Multitrack studio is the only midi 2.0 DAW/VST host.
MIDI 2 will ask a MIDI 1 MPE device if it speaks MIDI 2, and receive no response because it does not. Your MIDI 2 device will then revert to MIDI 1 protocols, and drop to MIDI 1 capabilities.
I didn’t mean to imply any conflict between those standards. I was responding to NothanUmber placing MPE in the past, as the no-longer-necessary stopgap that it will someday be. His assessment was premature.
And because he had opened this comparison, I pointed out a key difference, which I didn’t feel needed a lot of context or explanation, because I know he’s well aware of it.
Namely, that the vast majority of the instruments discussed on this forum were developed before MPE was even formalized, by scrappy independent developers that don’t have the tools to get started working on MIDI 2.0 yet.
I mean, it took close to a decade for MPE to reach wide enough usage for Ableton to even acknowledge that there was value in supporting it (and much longer for polyphonic aftertouch). And almost none of that momentum came from the companies we’re relying on to bring us into the MIDI 2 enabled future.
The revolution does not start when a spec is announced. It starts when developers who are willing to take bold risks are able to do so without impediment.
That transition has yet to occur.
I mean a lot of things. I’m mostly referring to platforms like max, pd, processing, arduino, and so forth, that people are wildly transforming MIDI 1.0 with, not yet providing any hooks for those developers to perform or respond to MIDI 2.0 Capability Inquiries. Without which, the extended capabilities of MIDI 2.0 are lost.
Again, my whole point was that MPE experienced rapid growth in the indie sector because it had no such barrier to entry. And it’s probably worth mentioning, most of the companies we’re relying on to push MIDI 2.0 forward still don’t support half of MIDI 1.0’s capabilities.
But, sure. Let’s talk about products.
Well, that explains part of where you’re coming from.
I hadn’t seen that video before. All of the claims I had seen coming out of NAMM were merely that it was “MIDI 2.0 Ready”.
Which is to say, all of the claims I had seen coming out of NAMM were significantly more accurate.
But again, these developers can’t actually test their work in any meaningful way, because the only controller which claims to support MIDI 2.0 does not actually do so yet. So, it might take longer, even after the work is done.
(I wouldn’t expect anyone to assert that their products are compatible until they can confirm that they’re compatible.)
And yet, here we are having one.
You’re welcome to believe I didn’t intend for that to occur. But I will ask that you not put words in my mouth.
Not at all! I was trying to have a discussion and be helpful.
Nothing I posted sounded like a question because it was intended as a counterpoint. To further discussion. It’s… well, it’s the basis of most discussion, really. These aren’t obscure rhetorical techniques I’m using.
And yet, you oppose it. I’m discussing the title. You’re speaking of me in third person.
“The Future Is Now” was a declarative statement with no evidence.
My statement was that the advent of MIDI 2.0 Capability Inquiry presents a speedbump to the growth and adoption of MIDI 2.0, because huge swaths of brilliant and prolific developers are not yet able to work within that requirement.
…and that’s a logical fallacy.
It goes to the bold claim; not to the call for temperance.
But as you point out, I didn’t ask for proof.
See again: This.
(Hello. You and I are having a discussion. I wouldn’t normally point that out, because I think it’s self-evident, but I’m willing to adapt.)
I don’t know where that assertion came from, but it is contrary to my point.
Only one form of capitalism is currently affecting MIDI 2.0 progress, and it has historically done so at a snail’s pace. I’m holding that in contrast to the wide range of capital ownership types used successfully to propel MPE to its current adoption.
And I wish you success in all of these ventures.
When you release them, thereby establishing a functioning MIDI 2.0 ecosystem that does not yet exist, I will gladly join you in declaring the future to have begun.
But for now, it’s still abstract.
The spec is real, and the hope is real, and this stuff is the future.
But it isn’t now.
Their facts were straight. That was a voice of dispassionate reason. I can’t speak to their adulthood, but I will try my best to appeal to yours:
Please spend a few days away from this thread before replying again. And then, please come back to help further the discussion. You need to calm down and stop lashing out before admins step in. Because once they do, the discussion is over. And that’s not what any of us want.
I think the move to Midi 2.0 is starting, but its a long road.
I posted a while back about a new DAW (Mutlitrack Studio) that supports Midi 2.0, which is an interesting and vital step.
Generally, everyone sees the need for Midi 2.0, and I do think the spec is very comprehensive.
but its a bit chicken n’ egg for many musicians - until there is widespread adoption, you dont feel the benefits, but widespread adoption, well needs people to adopt and support it
its great that Midi 2.0 can live side by side with Midi 1.0, so at least incompatiblity is not an issue.
I think MIDI-CI will be the thing that starts the momentum, in particular, I know a few products that want to bridge midi 1.0 and 2.0… the idea being to use meta data so that a hardware product (like a midi router) can broadcast MIDI-CI for ‘legacy’ hardware.
This I think is almost vital, as it kind of brings MIDI 2.0 benefits to potentially thousands of older instruments, which are still cherished and loved - that is where ‘adoption’ can start.
as I said a few things are trying this now, as they are in thier own way collecting the required meta data - e.g. Im looking at this with Electra One.
but its a tricky area, with no standardisations on how this meta data could be stored - personally, Ive started ‘importing’ from a few different sources.
then the other side, is (hardware) manufactures are having difficulties releasing new products due to the pandemic.
I’d guess as this eases (next year? namm 2022) we wll see a flurry of new equipment, which hopefully will included midi 2.0 support.
similarly, Id suspect the next release of daws might be eyeing up the midi 2.0 spec.
anyway, midi-2.0 is on its way, but it’ll take a while for widespread adoption…
Out of the big names, I guess Steinberg are in a good position to be one of the early adopters. Cubase has a history of being viewed as the best DAW for anything midi, a reputation they probably have incentive to maintain. They already have expression-per-note editing and hardware controllers. So here is hoping for a midi 2.0 capable Cubase 12 launched alongside some controllers taking advantage of those features in the not too far future.
most of the big daws have known this was coming for a while, so I expect are moving in that direction.
as you say, Cubase are traditionally really ‘hot’ in this area - but I think Bitwig, and Ableton are pretty well prepared (now)… also Traktion, no doubt will just ‘get it’ via JUCE support.
one thing is, Midi 2.0 is many things, so will they concentrate on the high resolution, and ignore midi-ci intially… as few device support, or go ‘all in’.
you’d think it be reasonably easy to add midi-ci support for vsts - this could be massive for midi controllers, and lead us away from ‘dumb’ midi controllers to ones with intuitive displays.
which leads me to wonder about Native Instruments, i’d love to see somehow thier work on NKS, somehow contribute/move forward to MIDI-CI.
of course, this is where ‘commecial interests’ and ecosystems may initially stifle progress, why would NI make it easier for competitors to step into this space?
but I hope they see it as a way to their (controller) products support open hardware.
finally, there will be some ‘hiccups’ along the way,
even with the simplicity of midi 1.0, there’s been assumptions, misunderstandings, lack of conformance which creates ‘spotty’ compatibility. it will take a while for developers to ‘get it right’ (esp. as its a large spec!).
but this is a natural stage for ‘new tech’ , the early adopters and tech savvy won’t mind so much.
but many will hold off to ‘let the dust settle’ , and frankly to prove that it really brings them benefits - yup here are a lot of sceptics out there
an exciting time, of course only time will tell if its ‘revolutionary’ or not,
for me… the day I stop having to map ‘dumb’ midi controllers to parameters/cc, and the whole hardware, software, controller divide - disappears, becomes seemless and automatic - that is when midi 2.0 will have ‘arrived’ for musicians (as opposed to hybrid musician/developers like me )
Eric from Keith McMillen Instruments here. One misconception about MIDI 2.0 is that it only refers to the new 32bit packet format, but many of the exciting things like capability inquiry, profiles, and property exchange will likely all happen in the old 1.0 format as they are rolled out.
This 32bit Universal MIDI Packet (UMP) will take some time to be adopted. Microsoft, Google and Apple need to write USB drivers that support it, and companies need to see the advantage of writing the code for it. This will be a similar process to MPE adoption, once a big player (for MPE it was Ableton) comes on board, there are more reasons for others to support the standard. We are already seeing MPE adoption grow, and the same will happen with the UMP packet once the big tech companies have USB drivers that support it. But it will be a slow process.
Speaking of MPE, work is continuing on the spec and a profile for property exchange is being developed. While both property exchange and profiles are “MIDI 2.0” standards, these are both going to use MIDI 1.0 messaging. For example, RPN0 defines pitch bend range, and RPN6 is used to set the number of member channels in an MPE Zone. Right now with MPE/MIDI 1.0, there is no way for a controller and a sound source to negotiate these settings. With a profile, we will establish a standard way to share this information using property exchange. So for example, a Sequential Prophet 6 and a K-Board Pro 4 will be able to establish a bi-directional connection, and the Prophet 6 can set the KBP4 to use a single zone with 6 member channels, and the KBP4 can set the Prophet 6 per-note pitch bend range to +/- 2 semitones, and both can confirm that the other has accepted those changes. Again, this all happens with MIDI 1.0 messaging using a combination of SysEx and RPNs/CCs. When the 2.0 UMP is more universally adopted, there may be an expansion of the MPE profile that includes methods for translation between MPE and UMP.
This is all going to play out over time, but in the short term you are going to see Profiles and Property Exchange being the next phase of MIDI 2.0 adoption.
Not a lot of surprises in the first half, but the reality check is appreciated.
(Prototyping tools are still trickling out, with widespread 2.0 adoption expected in about five years. Individual features will continue to proliferate over 1.0 in the meantime, as backwards compatibility remains a priority.)
The second half is a bit rosier, with OS level support in place now on most computing platforms.
Microsoft planning to open-source their MIDI 2.0 drivers is an especially pleasant surprise. That should help tremendously.
yeah, BomeBox announced their latest firmware supports midi 2.0 CI.
k, these is not unexpected, as they promised this 2 years ago
but good to see if come to fruition.
anyway, a couple of interesting points here, from a company actually doing 2.0.
there are tools provided by the MMA that allow you to verify compatibility.
let’s hope these verification tools will ensure better compatibility, less room for ‘interpretation’, than midi 1.0 provided. in fairness, I do think this is likely, software engineering has come a long way in this area, than when midi 1.0 was introduced.
I guess, the MMA could have created midi 1.0 verification tools, but perhaps that was politically a no-go, as some big names could have failed.
b) Midi 2.0 CI bridge
This idea has been knocking around every since midi 2.0 ci was announced.
basically, you load some kind of profile for midi 1.0 devices on a midi hub (like) device, and it will broadcast this as midi 2.0 ci to connected devices.
so, within (many) limitations, your existing midi 1.0 devices will look like midi 2.0 devices to (e.g) your daw…
I think this is massive, over time, gone will be the days where we need to remember CC mappings to synth parameters, they’ll just show up… like parameters in vst do.
whilst this doesn’t bring any new ‘functionality’ to musicians, its quite a move forward on ‘quality of life’
anyway, this is basically what bomebox is doing…
but they will be the first, I think we will get a ton of these kind of hubs doing this.
(Id assume iConnectivity would already be working on this!)
on my side, Im waiting for DAW support on midi-ci, as this will actually make these devices kind of useful.
once, we see announcements in this area, I’ll look with Martin as adding this functionality to the Electra One, which would be perfect of this task.
Electra One is in a particular good place for this, as it already has a ton of ‘instrument profiles’ developed by the community… so it has the meta data ready to be published over MIDI-CI.
c) midi 1.0 → midi-ci , need for device meta-data
this is potentially going to be a hot topic, I think for midi 2.0 ci.
the likes of bomebox, are going to need device profiles for existing midi 1.0 devices to do this bridging.
currently (afaik) there is no standard for this, and many different ideas how it should be done.
every device/software product that needs something like this (and there are a few) invents its own file format/standard. and then basically asks the community to create and share - so its only as useful as the strength/participation of your community.
this is ok, for fairly simple synths etc, but really I think many end-users will be quite disappointed in this.
it be nice, if there could be some collaboration in this area - unfortunately, I doubt this will happen, as this ‘repository of profiles’ could become the key selling point between these devices. (*)
anyway, I pretty hopeful… I think as soon as the DAWs start supporting CI, then I this’ll be the catalyst for change - as they’ll be at least one decent use-case for it. I think this could happen in fairly short order.
this’ll encourage manufactures to start adding fuller 2.0 implementations, and so we’ll getting full midi 2.0 implementations e.g. for increased resolution.
(*) given midi ci ‘just works’, one you have the profiles and add it to your hub, theres really not a lot else, you ned the hub to do… so the quantity/quality of these profiles could be the real draw to particular hubs.
I think this is why BomeBox wants to get in early… even if at present, its of little use without daw support (from all the big names)
I think it is a better idea to talk about this stuff in terms of bridging devices between the world of MIDI 1.0/MIDI DIN and MIDI 2.0, like thetechnobear talks about in his post, rather than the slightly misleading idea of MIDI 2.0 features proliferating into MIDI 1.0. There are plenty of MIDI 2.0 features that only work with the new packet-based messages, where there is no DIN support, and various MIDI 2.0 features are never going to be a part of MIDI 1.0. Clever use of bridging devices will enable some discovery of older devices capabilities, and will allow MIDI 1.0 devices to exist within a modern MIDI 2.0 network of devices, and so I think its better to think about it that way. Much of the touted backwards compatibilliy is along those lines too, and users shouldnt really expect stuff beyond that or they are likely to end up confused or let down.
There is plenty of technical detail in the various aspects of MIDI 2.0 and sometimes I make mistakes or encounter confusion when trying to explain this stuff in detail. Probably I should try to be less of a details nerd about this sort of topic for now, and just wait until more devices and instruments with some MIDI 2.0 features are actually available to users, because this will enable them to understand what benefits are on offer in a proper context. That video is a good update though and covers plenty of useful territory including why things havent progressed further yet, eg no Windows support yet at the OS level of things.
Or to put it another way, the area where its fine to talk about stuff proliferating back into the MIDI 1.0 world to a certain extent is where we think about the ‘device discovery’ stuff and a chunk of the ‘auto config’ stuff this will enable. At least for devices where development is still active and the developers actually want to enable this stuff in future in existing products. Eric provides good detail about that in an MPE context earlier in this thread, and Geert Bevin also spoke on the same theme in the Linnstrument forum recently - about how the MPE group are still working on the 2.0 CI profile for MPE devices, and how they plan to add such stuff to Linnstrument firmware when the time is right.
I could of sworn I saw a link to a relevant Github repo where Microsoft was working on this from this video the first time I watched it, but I can’t find it now. Anyone have that? I found some very stale repos of Brown’s, but nothing more.
Pete posted in the GearSpace MIDI 2.0 thread a few times recently. It doesnt sound like they are ready to share full detail of their MIDI plans yet, but he said that he would share a github link when they make this new stuff public. Here are direct links to a couple of the posts: