5 ms·

Technically you could just employ CC to send extra info, say send CC with number representing how long the note will be, or the modulation type the note should

by ilyt 4y ago

Technically you could just employ CC to send extra info, say send CC with number representing how long the note will be, or the modulation type the note should get. We already have MPE abusing standard a bit to have per-note bending and such. The biggest problem in MIDI is IMO the fact there was no possible option for any standard negotiation between devices. You had MIDI IN and OUT, and at any time one or both could be connected to instrument/controller, you didn't knew where you were outputting it, and you didn't knew who send you control messages. That utter simplicity had benefits from interfacing perspective but it also made it impossible to expand the standard easily. There was no option for "MIDI 1.1" that would say improve some stuff but still had option to send MIDI "1.0" compatible signal if it detected that other side doesn't talk it. There was also no option for simple "tell me what CC 85 does on you" so every mapping between devices had to be done by hand or by loading someone's profile. It kinda had to be what it is, it was introduced in 1983 where extra transistors were pretty fucking expensive so simplicity of the protocol was huge benefit, I'm pretty sure simple MIDI keyboard could be implemented even with a bunch of logic chips without much problem.

noizejoy 4y ago
> no possible option for any standard negotiation between devices. While I agree for ease of designed use, I also think that’s one of the fantastic features of MIDI, because it makes it possible to use participating devices in novel ways, never anticipated by their manufacturers. For example, I sometimes use note pressure messages (a.k.a. polyphonic aftertouch) as a second set of 127 control change messages, rather than their documented design intent.
- ilyt 4y ago
  Right but you wouldn't need that hack in the first place in MIDI2.0 It does look pretty overcomplicated, but then the variety of use cases might be excusing it. Also the fact it has some kind of negotiation doesn't preclude doing clever things with it, just the fact you don't need to rename knobs differently for every single device you connect
  - noizejoy 4y ago
    > Right but you wouldn't need that hack in the first place in MIDI2.0 Yes indeed, but one of my favourite pastimes over the last while has been to buy inexpensive used (and no longer manufactured) midi controllers and use them together with ultra-modern software (DAW, virtual instruments and fx). My kind of hacks (and numerous others) will hopefully continue to extend the useful life of older MIDI capable hardware and lessen the burden of landfills a tiny bit. I’ve been very relieved and excited to read, that MIDI 2.0 is supposed to be very backwards compatible, so hopefully I can use my old hardware with ultra modern software for a long time. > Also the fact it has some kind of negotiation doesn't preclude doing clever things with it. In theory yes, but unfortunately I’ve seen too many cases of this type of simplification for straightforward use cases also preclude the facilitation of other use cases. If we make developers think and work too much about use cases, rather than just the power of the naked protocol, they often neglect the latter in favour of the former.
    - ilyt 4y ago
      >Yes indeed, but one of my favourite pastimes over the last while has been to buy inexpensive used (and no longer manufactured) midi controllers and use them together with ultra-modern software (DAW, virtual instruments and fx). I should probably dig that MIDI dashboard project out of pile of abandonded projects someday, once upon a time I bought cheapo midi matrix controller (Midiplus smartpad) then kinda... not really using it for much so I mapped which MIDI command lights what light and wanted to make a dashboard of various stuff out of it... I do like how trivial 1.0 is; implementing it on a microcontroller has been a breeze. >> Also the fact it has some kind of negotiation doesn't preclude doing clever things with it. >In theory yes, but unfortunately I’ve seen too many cases of this type of simplification for straightforward use cases also preclude the facilitation of other use cases. > If we make developers think and work too much about use cases, rather than just the power of the naked protocol, they often neglect the latter in favour of the former. That does worry me a bit with 2.0, it is absolutely "and the kitchen sink" of protocols and considering how even 1.0 implementations can be janky we might see a bunch of pretty badly designed 2.0 implementations
  - pishpash 4y ago

by ilyt 4y ago

noizejoy 4y ago

> no possible option for any standard negotiation between devices. While I agree for ease of designed use, I also think that’s one of the fantastic features of MIDI, because it makes it possible to use participating devices in novel ways, never anticipated by their manufacturers. For example, I sometimes use note pressure messages (a.k.a. polyphonic aftertouch) as a second set of 127 control change messages, rather than their documented design intent.

ilyt 4y ago
Right but you wouldn't need that hack in the first place in MIDI2.0 It does look pretty overcomplicated, but then the variety of use cases might be excusing it. Also the fact it has some kind of negotiation doesn't preclude doing clever things with it, just the fact you don't need to rename knobs differently for every single device you connect
- noizejoy 4y ago
  > Right but you wouldn't need that hack in the first place in MIDI2.0 Yes indeed, but one of my favourite pastimes over the last while has been to buy inexpensive used (and no longer manufactured) midi controllers and use them together with ultra-modern software (DAW, virtual instruments and fx). My kind of hacks (and numerous others) will hopefully continue to extend the useful life of older MIDI capable hardware and lessen the burden of landfills a tiny bit. I’ve been very relieved and excited to read, that MIDI 2.0 is supposed to be very backwards compatible, so hopefully I can use my old hardware with ultra modern software for a long time. > Also the fact it has some kind of negotiation doesn't preclude doing clever things with it. In theory yes, but unfortunately I’ve seen too many cases of this type of simplification for straightforward use cases also preclude the facilitation of other use cases. If we make developers think and work too much about use cases, rather than just the power of the naked protocol, they often neglect the latter in favour of the former.
  - ilyt 4y ago
    >Yes indeed, but one of my favourite pastimes over the last while has been to buy inexpensive used (and no longer manufactured) midi controllers and use them together with ultra-modern software (DAW, virtual instruments and fx). I should probably dig that MIDI dashboard project out of pile of abandonded projects someday, once upon a time I bought cheapo midi matrix controller (Midiplus smartpad) then kinda... not really using it for much so I mapped which MIDI command lights what light and wanted to make a dashboard of various stuff out of it... I do like how trivial 1.0 is; implementing it on a microcontroller has been a breeze. >> Also the fact it has some kind of negotiation doesn't preclude doing clever things with it. >In theory yes, but unfortunately I’ve seen too many cases of this type of simplification for straightforward use cases also preclude the facilitation of other use cases. > If we make developers think and work too much about use cases, rather than just the power of the naked protocol, they often neglect the latter in favour of the former. That does worry me a bit with 2.0, it is absolutely "and the kitchen sink" of protocols and considering how even 1.0 implementations can be janky we might see a bunch of pretty badly designed 2.0 implementations
- pishpash 4y ago