4 ms·

MIDI is an 8-bit protocol, operating at 31.25kbaud. False. That is but one transport option for MIDI data. USB-MIDI is another, much higher bit-rate protocol

MIDI is an 8-bit protocol, operating at 31.25kbaud. False. That is but one transport option for MIDI data. USB-MIDI is another, much higher bit-rate protocol. The standard doesn't include any means of transmitting expression data other than velocity on a per-note basis. False. MIDI provides polyphonic aftertouch as a standard (i.e. not NRPN or SysEx) message type. If you try and send too much controller information over a channel, the timing goes to pot as you run out of bandwidth. Again false, if you're using a more modern transport such as USB-MIDI. A MIDI message is just a single byte False; this tells me you haven't read the MIDI spec. This is not true of either the messages themselves (which are generally multi-byte messages) nor of the message types (which are a single nibble for the basic types, 7 bits for the controller types, and 14 bits for each of RPN and NRPN messages).

some1else 14y ago
Many OSC based applications for the monome[1] were ported to work with the copy-paste-avalanche of grid controllers (Launchpad, APC). The USB-MIDI data rate limitations are clearly visible when trying to change the state of 64 keypads at once. 64 individual signals with 8ms latency completely break the flow[2], compared to a single optimized OSC message. Your counterpoints are correct, but MIDI is a better choice over OSC only due it's widespread compatibility. However, it's pointless to stick to USB-MIDI in the long run. It couldn't support the more complex DIY controller requirements as far as 6 years ago, so I can only imagine the chasm increasing. A new inter-operable standard that surpasses MIDI and OSC was envisioned back on 2009 called ioFlow[3], but unfortunately it hasn't taken off yet. P.s.: The website the story refers to is returning a 403, so my comment is here only to support the claim, that starting out with MIDI in 2013 is not the best idea. Edit: Now that the site is online, I can respond to the product itself. It's probably a good fit for keyboard musicians, but I'd recommend the true hacker to pick up this indy marvel: Madrona SoundPlane-A[4], which has been in development for approximately 4 years. The concept is very, very similar. But it's not bound to the linear piano scale like the Roli. You can play it like guitar frets or better yet, explore 2 dimensional note layouts, such as the ones invented by Euler[5], popularized by Kaosscilator and now Ableton Push. Also, it runs on OSC, so you can enjoy the low latency, and build your own paradigms by transforming the signals in Cycling 74 Max or other OSC capable programming environments. [1] http://monome.org/ http://monome.org/ [2] http://en.wikipedia.org/wiki/Flow_(psychology) http://en.wikipedia.org/wiki/Flow_(psychology) [3] http://ioflow.berlios.de/ http://ioflow.berlios.de/ [4] http://madronalabs.com/hardware http://madronalabs.com/hardware [5] http://en.wikipedia.org/wiki/Tonnetz http://en.wikipedia.org/wiki/Tonnetz
- daeken 14y ago
  > The USB-MIDI data rate limitations are clearly visible when trying to change the state of 64 keypads at once. 64 individual signals with 8ms latency completely break the flow[2], compared to a single optimized OSC message. Can't agree enough. I picked up a Launchpad since it was cheap and looked fun to hack on. I wrote a Python module to talk to it and then watched it chugging along while writing a sequencer on it; the bandwidth just isn't there to do intelligent updating of the pads. It is a fun little device, though, and I can't wait to get my Push to continue the work (the protocol seems to be more sane, given what Ableton is doing with it)
lttlrck 14y ago
Nitpick but surely you can still try to send too much data over USB-MIDI and have similar issues. And given the nature of USB it might even be harder to estimate where that limit lies.
smosher 14y ago
MIDI provides polyphonic aftertouch as a standard (i.e. not NRPN or SysEx) message type. I've read the standard and this sounds very wrong to me. If it is in the spec then I know a few synths that are broken.
- colanderman 14y ago
  Most synths don't produce that message (status 0xAx where x is the channel), but rather the more generic Channel Aftertouch message (0xDx). (Edit: whoops, I'm bad at converting bin->hex.)
  - smosher 14y ago
    I was going to ask about the message details but I figured it would make me sound like an asshole, so thanks for that. I've looked for this kind of message specifically and not found it in the spec. Does it specify a note number or do something odd? FYI, I wasn't worried about synths generating the message but rather receiving it. It's not too hard to tell whether a synth has a concept of per-note aftertouch, but I guess if it's two distinct messages it's okay to be selective about which you support.
    - colanderman 14y ago
      Yes, the message format of polyphonic aftertouch is similar to that of a note on event (= note # + pressure). Channel aftertouch includes only the pressure. In case you're interested, I e-mailed to the address on your GitHub a copy of the message formats from the MIDI spec. I don't know where I found it (it's not freely available) or else I'd have linked it.
      - smosher 14y ago
        Thanks, that may come in handy.
      - unwind 14y ago
        This page: http://www.srm.com/qtma/davidsmidispec.html http://www.srm.com/qtma/davidsmidispec.html (which is quite obviously highly unofficial) mentions both 0xAx and 0xDx, calling them "Key Pressure" and "Channel Pressure", respectively. The explanation says: Some keyboards can detect a change in pressure on each key, while they are held by the player; these keyboards can report "key pressure" over MIDI. Some keyboards may sense the overall pressure on the device, such as with a weight sensor beneath the entire keyboard. These devices can report "channel pressure." Sounds pretty nice.

some1else 14y ago

Many OSC based applications for the monome[1] were ported to work with the copy-paste-avalanche of grid controllers (Launchpad, APC). The USB-MIDI data rate limitations are clearly visible when trying to change the state of 64 keypads at once. 64 individual signals with 8ms latency completely break the flow[2], compared to a single optimized OSC message. Your counterpoints are correct, but MIDI is a better choice over OSC only due it's widespread compatibility. However, it's pointless to stick to USB-MIDI in the long run. It couldn't support the more complex DIY controller requirements as far as 6 years ago, so I can only imagine the chasm increasing. A new inter-operable standard that surpasses MIDI and OSC was envisioned back on 2009 called ioFlow[3], but unfortunately it hasn't taken off yet. P.s.: The website the story refers to is returning a 403, so my comment is here only to support the claim, that starting out with MIDI in 2013 is not the best idea. Edit: Now that the site is online, I can respond to the product itself. It's probably a good fit for keyboard musicians, but I'd recommend the true hacker to pick up this indy marvel: Madrona SoundPlane-A[4], which has been in development for approximately 4 years. The concept is very, very similar. But it's not bound to the linear piano scale like the Roli. You can play it like guitar frets or better yet, explore 2 dimensional note layouts, such as the ones invented by Euler[5], popularized by Kaosscilator and now Ableton Push. Also, it runs on OSC, so you can enjoy the low latency, and build your own paradigms by transforming the signals in Cycling 74 Max or other OSC capable programming environments. [1] http://monome.org/ http://monome.org/ [2] http://en.wikipedia.org/wiki/Flow_(psychology) http://en.wikipedia.org/wiki/Flow_(psychology) [3] http://ioflow.berlios.de/ http://ioflow.berlios.de/ [4] http://madronalabs.com/hardware http://madronalabs.com/hardware [5] http://en.wikipedia.org/wiki/Tonnetz http://en.wikipedia.org/wiki/Tonnetz

daeken 14y ago
> The USB-MIDI data rate limitations are clearly visible when trying to change the state of 64 keypads at once. 64 individual signals with 8ms latency completely break the flow[2], compared to a single optimized OSC message. Can't agree enough. I picked up a Launchpad since it was cheap and looked fun to hack on. I wrote a Python module to talk to it and then watched it chugging along while writing a sequencer on it; the bandwidth just isn't there to do intelligent updating of the pads. It is a fun little device, though, and I can't wait to get my Push to continue the work (the protocol seems to be more sane, given what Ableton is doing with it)

lttlrck 14y ago

Nitpick but surely you can still try to send too much data over USB-MIDI and have similar issues. And given the nature of USB it might even be harder to estimate where that limit lies.

smosher 14y ago

MIDI provides polyphonic aftertouch as a standard (i.e. not NRPN or SysEx) message type. I've read the standard and this sounds very wrong to me. If it is in the spec then I know a few synths that are broken.

colanderman 14y ago
Most synths don't produce that message (status 0xAx where x is the channel), but rather the more generic Channel Aftertouch message (0xDx). (Edit: whoops, I'm bad at converting bin->hex.)
- smosher 14y ago
  I was going to ask about the message details but I figured it would make me sound like an asshole, so thanks for that. I've looked for this kind of message specifically and not found it in the spec. Does it specify a note number or do something odd? FYI, I wasn't worried about synths generating the message but rather receiving it. It's not too hard to tell whether a synth has a concept of per-note aftertouch, but I guess if it's two distinct messages it's okay to be selective about which you support.
  - colanderman 14y ago
    Yes, the message format of polyphonic aftertouch is similar to that of a note on event (= note # + pressure). Channel aftertouch includes only the pressure. In case you're interested, I e-mailed to the address on your GitHub a copy of the message formats from the MIDI spec. I don't know where I found it (it's not freely available) or else I'd have linked it.
    - smosher 14y ago
      Thanks, that may come in handy.
    - unwind 14y ago
      This page: http://www.srm.com/qtma/davidsmidispec.html http://www.srm.com/qtma/davidsmidispec.html (which is quite obviously highly unofficial) mentions both 0xAx and 0xDx, calling them "Key Pressure" and "Channel Pressure", respectively. The explanation says: Some keyboards can detect a change in pressure on each key, while they are held by the player; these keyboards can report "key pressure" over MIDI. Some keyboards may sense the overall pressure on the device, such as with a weight sensor beneath the entire keyboard. These devices can report "channel pressure." Sounds pretty nice.