Thanks for the update 🌻 Think Midi 2.0 will come. Maybe MPE has it slowed down a little and as well there should be more people showing what you can do with Midi in general instead of selling My New Sample Packs ;)
I've written some Web MIDI API applications for vintage Korg and Roland synths. Editors and patch libraries. These will of course not need MIDI 2.0. But when it comes to Web MIDI API, I'm thinking about whether it's just to construct a MIDI 2.0 message and send in the existing Web MIDI API or whether the Web MIDI API must also be adapted to MIDI 2.0.
The big IT-platform / OS providers are all working on it now but I havent't heard so far if there is something going on regarding Web API. But I am pretty sure that it will be backwards compatible.
Hopefully it won't end up like Bluetooth midi on Windows (still no driver , only an app from the MS Store seems to work and companies make their own drivers for their devices ), or OSC control adoption My point is that if there will be an API and a built in plug'n'play driver then we might see devices such as Push/Maschine integrating seamlessly with other DAWs, within different OS , hardware synths (supporting Midi2)
I think people at the midi association lost common sense. Their documentation is VERY hard understand, it's so convoluted and written in the most boring and discouraging way possible. They could come up with something so much simpler and enough for everyone. Also as a small manufacturer making about 100k/year, spending $600/year on membership is kinda steep. I see the $600 tier is for companies making up to $1M/year. They should really add lower tiers for smaller companies. Small companies are often first to make innovative products.
Simple, MIDI was implemented as a full OPEN standard that wasn't gated from anyone... the spec fits in 100 pages and has everything from hardware to the protocol and only leaves the exact software implementation to hands of the device/software manufacturers. Only defining things that are already RESERVED for standard things midi supports. Midi 2.0 is far from this. You need expensive, restricted hardware for development, there's no specific hardware layer defined but it's open ended, everyone wants different things and you need billion things... OSC could have been Midi 2.0... but they decided that "no! we'll remake the wheel!" so there we go... makes things slow, and it's never going to be as robust or highly adopted as midi 1.0 was :(
The MIDI specification was never available openely. You had to be a paying member of the MIDI association to get the specs. The MIDI 1.0 specs were only made available some years ago to non-paying members.
It seems as dead as it can be. Been searching for years now to see anything new. Nothing! The VST 3.7 standard released in 2020, three years ago, makes support for implementing Midi 2.0 in plug-ins. But even Steinberg themselves hasn't bothered to include support in Cubase for Midi 2.0. And very little else is happening for any plug-ins or most DAWS. That shows how little the need for it seems to be from the developers side of things. And with MPE kind of fixing some of the "selling points" of Midi 2.0, it doesn't make it easier. Kind of like the extremely slow transition (Still ongoing) from Ipv4 to Ipv6. Many benefits with Ipv6. But no need to move to it for, what is it, 15 years time? Support have to be on many levels for Ipv6. The ISP, the router at home, the operating system etc. Instead trying to find workarounds for the (what should be) full address space. Same thing is happening with Midi 2.0. It is still seen as "good enough" and neither the hardware side nor the software side seems to think there is an urge to move on.
I think it is not that bad. As I explained in the video, everybody is waiting for OS support which is the key nowadays. Mac is already there for some time and some weeks ago Microsoft finally opened up their open source repo for MIDI 2.0 support on Windows. This was linked with the final updated MIDI 2.0 specification. Linux should be there too in the not too far future. Which means that finally DAW developers can start to implement it as well as manufacturers of all kinds of controllers.
@@mossgraber That seems curious. I mean the support for MIDI 2.0 has already been there for three years from when VST 3.7 was released. And some DAW:s already support MIDI 2.0 in Windows (Bitwig and some other DAW that I don't remember the name of now) . Is it really totally dependable upon Windows MIDI 2.0 native support? I mean on a similar note, ASIO fixed low latency audio drivers long before Windows came with something even near to that and it still can be used without any dependence at all for the Windows audio drivers. And when I buy a new hardware instrument or a controller I almost always install a separate USB midi driver, it isn't Windows itsel that provides it. Windows midi drivers are often very basic and not really usable (and won't work at all for many external keyboards/Synths)..
@@Magnus_Loov No DAW has real MIDI 2.0 support so far. But at least the clever manufacturers prepared for that by improving their internal data structures, which are then sent to things like VST or CLAP. Yes, you are right, everyone could come up with their own driver and API, which would mean that each device would need to be supported separately in a DAW.
@@mossgraber...something that in reality is happening a lot. MPE-devices have to work differently spreading out over several midi channels for spreading the expressions per key. I myself have just bought a very special type of wind-bite controller that works in several "dimensions" at once besides the breath pressure. There is also "Bite pressure (yes, really how hard you bite into the thing) and head tracking on the device (nodding or tilting the head are two of the extra controller opportunities). Then we have Reason which actually do have very extensive list of "per device pre-configuration". For responding VST-i:s there off course also is interpolation going on where the 0-127 limited range get smoothed out for things like filter sweeps (cutoff frequency). Then we also have Studio one that somehow takes pride in being a no-midi DAW, ie they somehow convert midi messages all around to have much better timing and higher resolution for all kinds of messages. Problem is that it isn't compatible if you wanna export a midi-file from it. So it's already a mess in all kinds of ways that to me seems to be very hard to "get out of", just like all the "dirty circumventions" done for ipv4 to avoid ipv6. Things continuing to work and doing kinda the same thing as MIDI 2.0 promises. (or at least a sub portion of it) Although MIDI 2.0 have one thing going for it that ipv6 lacks: Backwards compatibility to MIDI 1.0. Ipv6 isnt' backwards compatible to ipv4 so that is one thing where communication protocols differ in difficulty in transitioning! I WANT MIDI 2.0 to succeed but I know how much inertia there is when moving from one long standing standard to another. Fun fact: ipv4 and MIDI 1.0 were both made standard protocols in 1983! The "big swtich" to ipv4 was made on 1 January of 1983 (ie they forced people on NSF-NET/Internet to switch protocol or it wouldn't work).
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
Thanks for the update 🌻 Think Midi 2.0 will come. Maybe MPE has it slowed down a little and as well there should be more people showing what you can do with Midi in general instead of selling My New Sample Packs ;)
I've written some Web MIDI API applications for vintage Korg and Roland synths. Editors and patch libraries. These will of course not need MIDI 2.0. But when it comes to Web MIDI API, I'm thinking about whether it's just to construct a MIDI 2.0 message and send in the existing Web MIDI API or whether the Web MIDI API must also be adapted to MIDI 2.0.
The big IT-platform / OS providers are all working on it now but I havent't heard so far if there is something going on regarding Web API. But I am pretty sure that it will be backwards compatible.
Hopefully it won't end up like Bluetooth midi on Windows (still no driver , only an app from the MS Store seems to work and companies make their own drivers for their devices ), or OSC control adoption
My point is that if there will be an API and a built in plug'n'play driver then we might see devices such as Push/Maschine integrating seamlessly with other DAWs, within different OS , hardware synths (supporting Midi2)
It seems that at least there is now a plan. Let's hope for the best 🙂
thanks for the update... opensource development in secret ?! wtf... midi 2.0 dev seems very political
... until it is opened up 🙂
I think people at the midi association lost common sense. Their documentation is VERY hard understand, it's so convoluted and written in the most boring and discouraging way possible. They could come up with something so much simpler and enough for everyone. Also as a small manufacturer making about 100k/year, spending $600/year on membership is kinda steep. I see the $600 tier is for companies making up to $1M/year. They should really add lower tiers for smaller companies. Small companies are often first to make innovative products.
I have seen worse specifications but I know what you mean.
Simple, MIDI was implemented as a full OPEN standard that wasn't gated from anyone... the spec fits in 100 pages and has everything from hardware to the protocol and only leaves the exact software implementation to hands of the device/software manufacturers. Only defining things that are already RESERVED for standard things midi supports.
Midi 2.0 is far from this. You need expensive, restricted hardware for development, there's no specific hardware layer defined but it's open ended, everyone wants different things and you need billion things...
OSC could have been Midi 2.0... but they decided that "no! we'll remake the wheel!" so there we go... makes things slow, and it's never going to be as robust or highly adopted as midi 1.0 was :(
The MIDI specification was never available openely. You had to be a paying member of the MIDI association to get the specs. The MIDI 1.0 specs were only made available some years ago to non-paying members.
It seems as dead as it can be.
Been searching for years now to see anything new.
Nothing!
The VST 3.7 standard released in 2020, three years ago, makes support for implementing Midi 2.0 in plug-ins.
But even Steinberg themselves hasn't bothered to include support in Cubase for Midi 2.0.
And very little else is happening for any plug-ins or most DAWS.
That shows how little the need for it seems to be from the developers side of things.
And with MPE kind of fixing some of the "selling points" of Midi 2.0, it doesn't make it easier.
Kind of like the extremely slow transition (Still ongoing) from Ipv4 to Ipv6. Many benefits with Ipv6. But no need to move to it for, what is it, 15 years time?
Support have to be on many levels for Ipv6. The ISP, the router at home, the operating system etc. Instead trying to find workarounds for the (what should be) full address space.
Same thing is happening with Midi 2.0. It is still seen as "good enough" and neither the hardware side nor the software side seems to think there is an urge to move on.
I think it is not that bad. As I explained in the video, everybody is waiting for OS support which is the key nowadays. Mac is already there for some time and some weeks ago Microsoft finally opened up their open source repo for MIDI 2.0 support on Windows. This was linked with the final updated MIDI 2.0 specification. Linux should be there too in the not too far future. Which means that finally DAW developers can start to implement it as well as manufacturers of all kinds of controllers.
@@mossgraber That seems curious. I mean the support for MIDI 2.0 has already been there for three years from when VST 3.7 was released. And some DAW:s already support MIDI 2.0 in Windows (Bitwig and some other DAW that I don't remember the name of now) .
Is it really totally dependable upon Windows MIDI 2.0 native support?
I mean on a similar note, ASIO fixed low latency audio drivers long before Windows came with something even near to that and it still can be used without any dependence at all for the Windows audio drivers.
And when I buy a new hardware instrument or a controller I almost always install a separate USB midi driver, it isn't Windows itsel that provides it.
Windows midi drivers are often very basic and not really usable (and won't work at all for many external keyboards/Synths)..
@@Magnus_Loov No DAW has real MIDI 2.0 support so far. But at least the clever manufacturers prepared for that by improving their internal data structures, which are then sent to things like VST or CLAP. Yes, you are right, everyone could come up with their own driver and API, which would mean that each device would need to be supported separately in a DAW.
@@Magnus_Loov Pete has some in-depth articles about the topic on his blog: devblogs.microsoft.com/windows-music-dev/author/petebrown/
@@mossgraber...something that in reality is happening a lot. MPE-devices have to work differently spreading out over several midi channels for spreading the expressions per key.
I myself have just bought a very special type of wind-bite controller that works in several "dimensions" at once besides the breath pressure. There is also "Bite pressure (yes, really how hard you bite into the thing) and head tracking on the device (nodding or tilting the head are two of the extra controller opportunities).
Then we have Reason which actually do have very extensive list of "per device pre-configuration".
For responding VST-i:s there off course also is interpolation going on where the 0-127 limited range get smoothed out for things like filter sweeps (cutoff frequency).
Then we also have Studio one that somehow takes pride in being a no-midi DAW, ie they somehow convert midi messages all around to have much better timing and higher resolution for all kinds of messages. Problem is that it isn't compatible if you wanna export a midi-file from it.
So it's already a mess in all kinds of ways that to me seems to be very hard to "get out of", just like all the "dirty circumventions" done for ipv4 to avoid ipv6.
Things continuing to work and doing kinda the same thing as MIDI 2.0 promises. (or at least a sub portion of it)
Although MIDI 2.0 have one thing going for it that ipv6 lacks: Backwards compatibility to MIDI 1.0.
Ipv6 isnt' backwards compatible to ipv4 so that is one thing where communication protocols differ in difficulty in transitioning!
I WANT MIDI 2.0 to succeed but I know how much inertia there is when moving from one long standing standard to another.
Fun fact: ipv4 and MIDI 1.0 were both made standard protocols in 1983! The "big swtich" to ipv4 was made on 1 January of 1983 (ie they forced people on NSF-NET/Internet to switch protocol or it wouldn't work).