Curious on future implementation. NAMM 2020 is delivering…
A little dissapointed it doesn’t have poly AT, but then again I sort of didn’t expect it.
Seems to be a premium midi keyboard so I guess it has good keyboard action.
But yeah, MIDI 2.0, I’m curious.
I found this article on the MIDI Accossiations web page, lots of interesting information about the new standard: https://www.midi.org/articles-old/details-about-midi-2-0-midi-ci-profiles-and-property-exchange
1 Like
weird announcement by Roland… as doesn’t specify how its going to support midi 2.0
I wonder if its just marketing, i.e. its got an upgradable firmware (what hasn’t there days!) , so they can add 2.0 whenever they want 
1 Like
I get the impression they’re actually just talking about MIDI-CI.
On to voting! and an Interesting chat as Nick Batt saying…
1 Like
yeah, interesting chat…
there has to be a market for bome, iconnectivity etc to produce hardware that can help this interfacing.
for me, I think the ‘biggest’ thing is going to be MIDI-CI, Im really hoping this will finally bring an end to the ideas of things like ‘midi learn’ , and allow auto mapping, to achieve a kind of industry wide NKS.
boxes like the bome box, could then hold device profiles for midi 1.0 instruments to provide that CI information…
the other thing, Id love to see is midi 2.0 tidy up ethernet midi… we need RTP midi to be standardised, and implemented and support properly - it’s really a bit ‘pot luck’ at the moment, outside of macOS/iOS.
which brings me on to one odd thing here…
Ive been interested in the bome box, but avoided it because it does not use RTP Midi for ethernet,
if they are really interested in pushing midi 2.0, that needs to change
1 Like
its 2020, hope it galvanise on a start of a new era, all ideas are there from plenty people an past years
1 Like
Yeah, interesting that the guy stated midi 2.0 is a foundation for future changes , to make future changes easier to push forward.
That’s great news , because whilst midi 1.0 has been great for integration, it feels like it always resisted change in fear for breaking things.
But with technology advances we need protocols that can embrace change, move forward.
Of course the question is … with flexibility we get complexity - midi was simple enough for end users and developers alike to understand.
( this is why we could easily ‘abuse’ it ;))
will this be true of midi 2.0? Or will the protocol be so complex most will have to treat it as ‘magic’
in fairness this is true of most protocols we use,
But it’s possibly a big change for us.
1 Like
I wonder if the vote was successful ( scheduled for 19th Jan) - sounded like it was basically a formality- but still 
I did notice MMA are talking about May 2020 as ‘midi 2.0 month’ - so perhaps that’s the date for final specs to be published.
(Hopefully publicly not just to members)
Was also reading about new jitter timestamps for 2.0 - that will (apparently) help with jittery connections - could be particularly useful for Bluetooth and WiFi.
Exciting times.
2 Likes
Curious also… anyone knows something ?
Yeah according to this tweet from Pete Brown of Microsoft the vote was successful, and the spec docs are undergoing final cleanup. https://twitter.com/Pete_Brown/status/1218973670409785350
3 Likes
It seems things are moving faster lately…
from the newsletter:
MIDI 2.0 Adopted at Winter NAMM 2020!
Introduction to MIDI 2.0™
Back in 1983, musical instrument companies that competed fiercely against one another nonetheless banded together to create a visionary specification—MIDI 1.0, the first universal Musical Instrument Digital Interface. Nearly four decades on, it’s clear that MIDI was crafted so well that it has remained viable and relevant. Its ability to join computers, music, and the arts has become an essential part of live performance, recording, smartphones, and even stage lighting.
Now, MIDI 2.0 takes the specification even further, while retaining backward compatibility with the MIDI 1.0 gear and software already in use. Here’s why MIDI 2.0 is the biggest advance in music technology in decades.
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.
Profile Configuration
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.
Property Exchange
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.
Built for the Future
MIDI 2.0 is the result of a global, decade-long development effort. Unlike MIDI 1.0, which was initially tied to a specific hardware implementation, a new Universal MIDI Packet format makes it easy to implement MIDI 2.0 on any digital transport (like USB or Ethernet). To enable future applications that we can’t envision today, there’s ample space reserved for brand-new MIDI messages.
Further development of the MIDI specification, as well as safeguards to ensure future compatibility and growth, will continue to be managed by the MIDI Manufacturers Association working in close cooperation with the Association of Musical Electronics Industry (AMEI), the Japanese trade association that oversees the MIDI specification in Japan.
MIDI will continue to serve musicians, DJs, producers, educators, artists, and hobbyists—anyone who creates, performs, learns, and shares music and artistic works—in the decades to come.
3 Likes
Interesting! How much of MPE or MPE+ would already be in the base “MIDI 2.0” spec and how much would/could have to be specified in a profile?
As far as In understood MIDI 2 compliance doesn’t automatically include MPE compatibility? (So could a controller or synth e.g. only support 32 bit values but not offer per-note capabilities and just announce that in the capabilities/properties etc.?)
I hope all these custom profiles and subsets don’t lead to the situation that only controllers and synths of the same manufacturer work together really well - and for everything else it’s essentially falling back to a very low common denominator, close to MIDI 1.0. So e.g. a common ground successor of MPE based on MIDI 2.0 (a profile?) that has a comparable (or even wider) spread as MPE and that guarantees a certain to-be-supported feature set (including per-note expression, high res, perhaps MPE+ -style control over interpolation behavior) would be good!
1 Like
Im waiting to see the full spec (not published yet)
there are a few interesting bits in here though…
section 1.5.x
the important bits are the new 32bit and 64 bit messages.
we can see that 1.0 will still be supported, by carrying it thru a fixed 32bit message,
this looks remarkably similar to how USB midi works i.e. its fixed to 4 bytes, even if a message is less e.g. channel AT) - I’d assume the term ‘MPE’ will be retained for this midi 1.0 functionality
for 2.0 support, we can get 64 bit message, and these are per note ( see 1.5.5) - so id guess they wont call it MPE , just “per note 2.0 messages”, and like hi-res it’ll just be see as a feature of midi 2.0.
(though, I bet this will create confusion, with people talking about MPE in midi 2.0… bit like the confusion around channel aftertouch and poly pressure, or was it channel pressure and poly aftertouch )
for sure, looks like its going to be an interesting transition…
i think the idea, is that midi 2.0 can be carried thru midi 1.0 transports … I guess concern here is not making things like midi (1.0) routers redundant overnight.
newer devices move to midi 2.0, but supporting 1.0 by wrapping it in the new universal packet.
I think theres going to be a big market in ‘translators’ and bridges for the 1.0 / 2.0, as bomebox already showed, there are lots of things you could do make midi 1.0 devices look like 2.0 e.g. by having customisable profile so they emit MIDI-CI
(hmm… that could be an interesting project for Beaglebone or rPI )
but really looking forward to seeing the details in the specs… which Im hoping will be released sooner rather than later.
3 Likes
Yepp, will be interesting! This being an official MIDI standard could help a lot with convincing people that it’s worth to support it.
That said: Have done a tool that visualizes how many velocity values are actually reached by a keyboard twenty years ago or so. It was quite disillusioning, the keyboard I had realistically had about 5-6 bit resolution, many values were never reached no matter how hard I tried.
So wrapping the 5 bit value of a simple midi-keyboard into a 16 bit velocity part of a note event might make the keyboard “MIDI 2.0 compliant!”, but not necessarily better…
But for good sensors (Eigenharp, Continuum, Soundplane&Co) we can already see today that more resolution (precision and time wise) can make a difference (OSC, EigenD, EaganMatrix etc.)
1 Like
Remember, velocity isn’t only for piano style keyboards. Any time you’re holding drum sticks or mallets, that’s a lot more control.
…but, yes. Working with older microprocessors, I’ve found that the noise floor on any sensor makes higher resolutions unreliable for continuous control. You basically end up filtering away extraneous digits. Curious whether the newer models can generate this kind of precision, or if hobbyist designers are stuck with 1.0 for a while.
No, my understanding is pretty much the opposite of this. MIDI 2.0 does not run over MIDI 1.0 transports. The new Universal Packet Format is for modern transports, so USB will be their main initial focus and there are currently no plans at all to try to make this work over MIDI DIN (since thats a serial form of communication, not packet based).
I know its a bit confusing because of the different layers involved, and their positive talk about various forms of backwards compatibility. But MIDI DIN connectors are not part of this, so anywhere they are still used in the system means a branch of the system that must fall back to MIDI 1.0.
Of course when I see the full spec it is always possible there will be slightly more wiggle room than I’ve been suggesting, but everything I’ve read so far suggests MIDI DIN is not coming to the MIDI 2.0 party.
1 Like