4 ms·

> "The standard is 40 years old and good for another 40, it’s so perfectly suited to the task." That's true, if you consider the task at hand to be allowing an

by elihu 4y ago

> "The standard is 40 years old and good for another 40, it’s so perfectly suited to the task." That's true, if you consider the task at hand to be allowing any piano-like keyboard controller to connect to any synthesizer and just work. It starts to break down if you consider it as a protocol for general-purpose musical expression. No explicit support for any tuning other than 12-tone equal temperament. No support for unisons on a single channel. Some support for per-note expression, but there's not really a sane way to support volume swells that works in a predictable way across devices. I think it should be possible to improve upon MIDI and make something that's a lot more flexible without adding too much complexity. MPE is a pretty good temporary workaround, but it's not the kind of thing you'd do if you were designing for expressive instruments from the start.

eyelidlessness 4y ago
I’m quite interested in expanding what can be done with digital and programmable music/accompaniment, but I’ve never knowingly sent MIDI data over a physical wire, only software interfaces. So, grain of salt… I think MIDI is very well suited to build on top of, without needing to change the spec. Most if not all of what you discuss can be built in software (and hardware! but it might need to be purpose built for some tasks, which is admittedly a weakness of the aging spec) with MIDI’s existing features. Importantly, I think that can be done without introducing ambiguities that would require end users to pierce the abstraction layer. (I say this as someone who works on projects rooted in a relatively younger but also old-by-today’s-standards spec, with very good abstractions built atop, but breaks down for certain use cases in ways that came up just today in my weekly check in.) Granted being such a small, low level target means it’s easy to get those abstractions wrong. But as someone might say of a house, it’s got good bones. A motivated person with the right tools and skills can do incredible things. I’m not sure that’s a compelling argument that MIDI objectively should remain unchanged for the better part of a century. But it’s compelling enough I’d scrutinize any proposal to revise for its thorough in-spec alternatives.
- lioeters 4y ago
  I think the Open Sound Control (OSC) protocol addresses some of the issues with MIDI 1.0, like higher resolution values, tunings beyond 12-tone equal temperament, etc., without the complexity of MIDI 2.0. > OSC's main features, compared to MIDI, include: > Open-ended, dynamic, URI-style symbolic naming scheme > Symbolic and high-resolution numeric data > Pattern matching language to specify multiple recipients of a single message > High resolution time tags > "Bundles" of messages whose effects must occur simultaneously https://en.wikipedia.org/wiki/Open_Sound_Control https://en.wikipedia.org/wiki/Open_Sound_Control
  - hules 4y ago
    OSC is just a way of packaging messages with an optional timestamp, despite its name, nothing in OSC is specialized for audio applications. There is no pre-defined convention for "Note-On" messages, "Note-Off", "Sustain Pedal" etc... If someone had taken the time to define these messages maybe it could have been a replacement candidate, but without this it offers nothing more than json. Also OSC is typically transported on UDP messages (because it is easy to do), but that's a terrible transport since it is unreliable, and messages larger that some OS and network dependent size are just discarded, so you can only use it reliably for message bundles smaller than a few hundred bytes.
- elihu 4y ago
  > I think MIDI is very well suited to build on top of, without needing to change the spec. I disagree. I think MIDI uses a basic abstraction that's awkward for anything that's not piano-like, and attempting to fix it by laying things on top just muddles things. MPE works around MIDI's limitations, but it's not a very clean interface. Users have to be aware of whether they're using MPE or not. If they are, channels don't work the same way as when they aren't. (And interestingly MIDI gets things wrong in about the same way that standard music notation fails.) I think MIDI's main mistake is that it assumes that a key, a note, a pitch, and a voice are all unique and be used to uniquely identify each other. So, for instance a keyboard can send NOTE-ON 72 127 when someone hits the C4 key at full velocity, and then when they release it the keyboard can send NOTE-OFF 72. There's this assumption that there's only one C4 being played at once, so the keyboard can just say, "stop playing the C4 note" to get it to stop. This breaks down if you send two NOTE-ONs for the same note in a row (which I think is technically allowed), but sending a NOTE-OFF when there are multiple notes playing is undefined behavior. The way most synths actually work internally is that you have one or more voice engines that can be tuned to any arbitrary note. I think a more sensible approach is to just have the controller allocate voices explicitly, and then tune them however it wants. Voices can be referenced by a unique ID that's independent of pitch. For instance, the controller might send messages like, "hey, I want to allocate a new voice which I will call V1; please set aside one voice engine and tune it to 261.63 hertz". The controller might do this before the user even hits a key. Then when the user hits a key it might send a command "please apply a percussive envelope to voice V1 using such and such parameters." When the user releases the key it might send a command "please apply an aggressive damping filter to voice V1". And so on. The controller might want to allocate more voices than the synthesizer actually has, but that's fine -- modern synths generally implement some notion of voice stealing anyways.
tjr225 4y ago

by elihu 4y ago

eyelidlessness 4y ago

I’m quite interested in expanding what can be done with digital and programmable music/accompaniment, but I’ve never knowingly sent MIDI data over a physical wire, only software interfaces. So, grain of salt… I think MIDI is very well suited to build on top of, without needing to change the spec. Most if not all of what you discuss can be built in software (and hardware! but it might need to be purpose built for some tasks, which is admittedly a weakness of the aging spec) with MIDI’s existing features. Importantly, I think that can be done without introducing ambiguities that would require end users to pierce the abstraction layer. (I say this as someone who works on projects rooted in a relatively younger but also old-by-today’s-standards spec, with very good abstractions built atop, but breaks down for certain use cases in ways that came up just today in my weekly check in.) Granted being such a small, low level target means it’s easy to get those abstractions wrong. But as someone might say of a house, it’s got good bones. A motivated person with the right tools and skills can do incredible things. I’m not sure that’s a compelling argument that MIDI objectively should remain unchanged for the better part of a century. But it’s compelling enough I’d scrutinize any proposal to revise for its thorough in-spec alternatives.

lioeters 4y ago
I think the Open Sound Control (OSC) protocol addresses some of the issues with MIDI 1.0, like higher resolution values, tunings beyond 12-tone equal temperament, etc., without the complexity of MIDI 2.0. > OSC's main features, compared to MIDI, include: > Open-ended, dynamic, URI-style symbolic naming scheme > Symbolic and high-resolution numeric data > Pattern matching language to specify multiple recipients of a single message > High resolution time tags > "Bundles" of messages whose effects must occur simultaneously https://en.wikipedia.org/wiki/Open_Sound_Control https://en.wikipedia.org/wiki/Open_Sound_Control
- hules 4y ago
  OSC is just a way of packaging messages with an optional timestamp, despite its name, nothing in OSC is specialized for audio applications. There is no pre-defined convention for "Note-On" messages, "Note-Off", "Sustain Pedal" etc... If someone had taken the time to define these messages maybe it could have been a replacement candidate, but without this it offers nothing more than json. Also OSC is typically transported on UDP messages (because it is easy to do), but that's a terrible transport since it is unreliable, and messages larger that some OS and network dependent size are just discarded, so you can only use it reliably for message bundles smaller than a few hundred bytes.
elihu 4y ago
> I think MIDI is very well suited to build on top of, without needing to change the spec. I disagree. I think MIDI uses a basic abstraction that's awkward for anything that's not piano-like, and attempting to fix it by laying things on top just muddles things. MPE works around MIDI's limitations, but it's not a very clean interface. Users have to be aware of whether they're using MPE or not. If they are, channels don't work the same way as when they aren't. (And interestingly MIDI gets things wrong in about the same way that standard music notation fails.) I think MIDI's main mistake is that it assumes that a key, a note, a pitch, and a voice are all unique and be used to uniquely identify each other. So, for instance a keyboard can send NOTE-ON 72 127 when someone hits the C4 key at full velocity, and then when they release it the keyboard can send NOTE-OFF 72. There's this assumption that there's only one C4 being played at once, so the keyboard can just say, "stop playing the C4 note" to get it to stop. This breaks down if you send two NOTE-ONs for the same note in a row (which I think is technically allowed), but sending a NOTE-OFF when there are multiple notes playing is undefined behavior. The way most synths actually work internally is that you have one or more voice engines that can be tuned to any arbitrary note. I think a more sensible approach is to just have the controller allocate voices explicitly, and then tune them however it wants. Voices can be referenced by a unique ID that's independent of pitch. For instance, the controller might send messages like, "hey, I want to allocate a new voice which I will call V1; please set aside one voice engine and tune it to 261.63 hertz". The controller might do this before the user even hits a key. Then when the user hits a key it might send a command "please apply a percussive envelope to voice V1 using such and such parameters." When the user releases the key it might send a command "please apply an aggressive damping filter to voice V1". And so on. The controller might want to allocate more voices than the synthesizer actually has, but that's fine -- modern synths generally implement some notion of voice stealing anyways.

tjr225 4y ago