3 ms·
> 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 inexpens
by 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