Should we replace MIDI?

DSP, Plugin and Host development discussion.
Post Reply New Topic
RELATED
PRODUCTS

Post

So, this may sound like a crazy idea because it's such a standard system at this point, but hear me out. Also, I'm not an expert on MIDI, so if I'm wrong about anything in this post, please let me know.

The first thing I'd like to point out is that the MIDI specs seem like they are significantly more complicated than they need to be. I may be wrong about this because I can't download their PDFs and see how long and convoluted they are without making an account (which by itself is an issue), so it would be great if you could let me know since I don't want to make an account that I may not even use for a while.

The second thing is that MIDI is strongly biased towards one system of tuning, and also quite biased towards one specific instrument layout: a standard keyboard with a pitch wheel and a mod wheel. This is an issue for players who want to play in a tuning system with a high density of notes, such as 53edo (53 equally-spaced notes per octave), since MIDI only gives you 128 notes per channel to play with, and mapping such a high-density scale to that few amount of notes will not give you much range to play with (so you'd either have to use more than one instance/recording of that instrument, switch scales on the fly, pick a smaller subset of notes from that bigger scale to use (like how we use major and minor scales from 12edo, but that means that making much more chromatic music from those large scales will be harder), or use multiple MIDI channels.

My solution to this would be a totally open, possibly even public domain system that people can see the specs for without having to sign up to anything and just use. Instead of having MIDI CCs and NRPNs, why not just have one regular type of control parameter that has a bit depth that you can specify? So for example, if you wanted the control to be some kind of switch, you could have it just use 1 bit. Or if you're developing something like a digital mixer and you want the gain parameters of each channel to have a really fine resolution, then you could use 16 or 32 bits for that control. There could also be per-voice control parameters, and note-on and note-off velocities would be included in those parameters, but the way they'd be controlled would just be set by whatever hardware and/or software you're using with this alternative to MIDI. And the note-on velocity parameter would also control if the voice is being played or not (i.e. a value of 0 = the voice is not being played). And instead of whatever system you use that is reading the protocol just looking at the number of the control, you could name the control and the system could look at the name associated with that control number on a per-instrument basis (the same with the bit depth of each control). These are ideas I had in mind that could contribute towards a more streamlined and easier-to-digest system than MIDI, even including the new 2.0 protocol.

I also know OSC is a thing but I don't know much about it. Let me know your thoughts, please.

Post

I think the topic title should read "midi 2.0", not just midi. The old midi specs are 40 years old, midi 2.0 came out less than 2 years ago. There's not a lot implementations of it afaik, so I say give it a chance at least.

So there is MIDI and OSC.
Q: Should we replace them competing standards?
A: Obligatory reference to xkcd 927

Is midi 2.0 overly complex? If you look at the bit level, then perhaps. But if you optimize for one use case, then other use cases suffer. Since bandwidth is no problem anymore, so isn't excessive data size. 16 bits is enough for all data sliders etc. Even VST dictates to use a float value for on/off controls.
So it is a comprimise. Generic specs always are.

Is that a problem? Well, as long as you don't need to implement anything but are just the user, it is not a problem. Compared to writing your own mp3 encoder, writing your own midi 2.0 processing is easier.

Is it a problem to ask for registration? You registered at Reddit and also here. I don't see a problem. I ran into the same hurdle there and decided I did not want to read the complete specs that desperately. And that might exactly be the purpose. If I were making something with midi, I'd register in a whim.
Perhaps allowing also google or facebook logins would be a step forward. With the added capability negotiation protocols added, I can see it's a complex specification and not digestible by all.

I don"t think the problem here is with midi 2.0. You can send note number 60 repeatedly and each instance can land exactly on an different target frequency.

What does you midi controller look like that spans 10 octaves with 53 notes each?
A matrix? Ribbon? Theremin?
Are you interested in academic discussions about limitations and things being suboptimal, or in getting things done regardless of imposed limitations?

Today I added another post on your previous thread regarding microtonality and midi 2.0: viewtopic.php?f=102&t=567879&p=8160646#p8160646
We are the KVR collective. Resistance is futile. You will be assimilated. Image
My MusicCalc is served over https!!

Post

MIDI 2.0 is still brand new. I haven't even seen any gear on the market that fully supports the protocol yet.
Orion Platinum, Muzys 2

Post

My thoughts include the fact that, even in 1997 when the book Beyond MIDI (MIT Press) was published, there were, according to the editor of that book, already "hundreds of codes for music" that had already been developed. She went on further in the preface to say that MIDI was "widely used, well documented, and works on almost every personal-computer platform." She also said that MIDI, among all the music codes, " is the most limited in terms of the number of aspects of music that it represents" and "is also the most remote from the music itself."

This, from 24 years ago, suggests that replacing MIDI anytime soon is not very likely despite its shortcomings, but if one wanted to do so, it would be a good idea to check out what else has already been done before re-inventing the wheel. It would probably also be a good idea to focus on the successful aspects of MIDI so as not to exclude them: wide use (applicability), portability, and good documentation. People often suggest replacing things as if it would be trivial to do so. IMO merely duplicating the success of MIDI would be difficult to achieve without copying large parts of it.

Regards,
Dave Clark

Post

Only when:

- there's humans capable of outputting MIDI 1.0 data faster than the data output rate specified for MIDI 1.0.
- all the people in the world can afford ( quality ) MIDI 1.0 devices.

Otherwise, it's just an endless loop of reinventing the wheel.
Free MIDI plugins and other stuff:
https://jstuff.wordpress.com
"MIDI 2.0 is an extension of MIDI 1.0. It does not replace MIDI 1.0(...)"

Post

umd wrote: Sat Aug 14, 2021 2:33 pmOtherwise, it's just an endless loop of reinventing the wheel.
+1

Post

(somewhere I have a full blown rant prepared about the fallacies involved in replacing MIDI with high level protocols in plug-in formats. Maybe I deleted it. But to me it's utterly clear that supporting MIDI is less effort than implementing new "supersets" for each plug-in format with their contradicting and sometimes deliberately exclusive designs. And yet, MIDI does the trick. Always delivers. Implement once, be done with it.

The rant would have been a sub chapter of a bigger rant about my doubts on plug-in formats which "try to hard". Those which are designed to keep plug-ins at bay rather than let them thrive. But I digress.)

Post

umd wrote: Sat Aug 14, 2021 2:33 pm - there's humans capable of outputting MIDI 1.0 data faster than the data output rate specified for MIDI 1.0.
The thing is, the original spec is only 31250baud, with 1+8+1 bits per byte, so you've got about 3125 bytes per second and with most messages (eg. note-on, CC) taking 3 bytes, it means each one of them takes about 1ms to transmit. Since there is no "time-stamps" with any of the messages (eg. a "note-on" happens when the message happens to arrive) this leads to quite significant jitter (arguably even at "human" time-scales) if you're sending a lot of stuff at the same time.

So traditional serial MIDI actually kinda sucks and increasing the data rate makes a whole lot of sense. That said, a number of modern devices can use USB links instead and I'd guess most of those run at much higher data rates... so I'm not entirely convinced the actual MIDI protocol as such needs to be changes, but ... seriously the original serial link is slow.

Post

Urs wrote: Sat Aug 14, 2021 2:48 pm (somewhere I have a full blown rant prepared about the fallacies involved in replacing MIDI with high level protocols in plug-in formats. (...)
A rant about replacing something that works is always interesting to read! :D
mystran wrote: Sat Aug 14, 2021 3:00 pm
umd wrote: Sat Aug 14, 2021 2:33 pm - there's humans capable of outputting MIDI 1.0 data faster than the data output rate specified for MIDI 1.0.
The thing is, the original spec is only 31250baud, with 1+8+1 bits per byte, so you've got about 3125 bytes per second and with most messages (eg. note-on, CC) taking 3 bytes, it means each one of them takes about 1ms to transmit. Since there is no "time-stamps" with any of the messages (eg. a "note-on" happens when the message happens to arrive) this leads to quite significant jitter (arguably even at "human" time-scales) if you're sending a lot of stuff at the same time.

So traditional serial MIDI actually kinda sucks and increasing the data rate makes a whole lot of sense. That said, a number of modern devices can use USB links instead and I'd guess most of those run at much higher data rates... so I'm not entirely convinced the actual MIDI protocol as such needs to be changes, but ... seriously the original serial link is slow.
Any current USB's protocol data output is bigger, but my question is... how often is that relevant?

Just an example... In our studio we have a lot of outdated-good-old-sounding-reliable machines all working together thanks to slow outdated protocols that... work and co-exist together. And still faster that we ( humans ) can play. Most of the people that come for a jam don't even know how MIDI works ( they just "heard about it" ).

I prefer that and focus on the music than having to deal with the burden of dealing with planned obsolescence.

( Also, it's easier to swap a good old MIDI cable than a USB one in a live situation :D )
Free MIDI plugins and other stuff:
https://jstuff.wordpress.com
"MIDI 2.0 is an extension of MIDI 1.0. It does not replace MIDI 1.0(...)"

Post

it is time for MIDI 2.0 to rise. as OP said, especially microtonal needs are not nearly fulfilled with MIDI 1.0. when you go ask those communities, sure they claim it's alright. they just only use synths that support .tun-files and collect as many .tun-files as they can so that it's a bit accessible. and then they compose some cringe pseudo-music concrete-kinda music and pretend to be really artsy. but once you have listened to sevish's music, an electronic artist, who actually manages to make microtonality sound just as good as anything else, you realize that it's not the microtonal community's fault, that most microtonal music sucks. it's just that microtonal capabilities are not nearly accessible enough to most musicians. it is gatekeeping the more intuitive people from going microtonal, so only real technical nerds get into it. and we all know that, while we love being technical and nerdy, these are often not the character traits that make the most emotional music. MIDI 1.0 must die for good and make room for MIDI 2.0, so music is not trapped in 12edo anymore. I don't care about hardware, protocols, or how much money it would make. just from a purely cultural perspective: we need MIDI 2.0

Post Reply

Return to “DSP and Plugin Development”