Roger at his creation. Photo courtesy Roger Linn Designs.

Roger at his creation. Photo courtesy Roger Linn Designs.

“How can an instrument be truly expressive if it only supports MIDI?”

This seemed to be a frequently-asked question in our coverage of the upcoming Roger Linn Linnstrument. While OSC certainly has its merits, however, it is possible to get higher-resolution data via MIDI. You’re likely most familiar with MIDI’s standard 0-127 values, or the 7-bit data, as used in simple Control Change messages. A 14-bit message, by contrast, gives you over 16,000 levels of resolution – most for most tasks.

The way the Linnstrument works is to send that higher-resolution data for pitch, via standard pitch bend messages. And if you really needed that resolution for other messages, you can get it.

I’ll let Roger explain directly, since this was such a source of reader confusion:

Is 14-bit support possible? Or even desirable?

Roger: For X/pitch, it’s already there in MIDI Bend messages.
For Z/pressure, it current uses 7-bit Poly Pressure or Channel Pressure messages, which seems to work fine. If someone wants more, it’s easy to send an additional 7 bits of resolution in a CC.
For Y/timbre, 7 bits seems enough to report the vertical position within a 3/4” pad. But again, if someone wants more, it’s easy enough to send an additional 7 bits of resolution in a CC.

Is polyphonic aftertouch supported?

Roger: Yes, either in Note-Per-Channel mode or in Single Channel Poly Pressure mode.

In addition to note-per-channel, what other schemes are supported?

Roger: There are 3 MIDI modes:

1) Note Per Channel, in which each note and its X, Y and Z movements are sent on a separate MIDI channel. This works well with Logic Pro X’s MIDI Mono Mode, in which each voice receives Note On/off, Bend and Channel Pressure (and hopefully in future, a CC for Y-axis) on its own channel.

2) Single Channel / Poly Pressure, in which everything is sent on a single MIDI channel, but continuous X and Y messages are sent only from movements of the most-recent touch.

3) Single Channel / Channel Pressure, in which everything is sent on a single MIDI channel, but continuous X, Y and Z messages are sent only from movements of the most-recent touch.

Thanks. That clears things up. And, of course, it’s possible someone could write custom firmware to, say, support OSC for applications that can make it useful. I can also imagine a monome app – with velocity.


Roger Linn’s Linnstrument Could Finally Make Grids Expressive for Music [Hands On]

  • Nathanaël

    Awesome ! I hope we can see some videos of the newest version soon !

    • Peter Kirn

      Definitely. We just decided not to try to shoot it in the hotel lobby – less than ideal. ;)

  • Nathanaël

    Also there’s one thing that’s not totally clear, poly pressure is usually per note, so in theory using a single channel you can send continuous velocity data for each finger, is that the case ? This is how Animoog works (for the y axis of the pads) and it works very well…

    • Peter Kirn

      Yes, all the data is there because it’s note-per-channel.

    • Nathanaël

      But polyphonic aftertouch should work even on a single channel….

    • Nathanaël

      For example, here’s some MIDI hardware I built that supports polyphonic aftertouch on a single channel:

      it’s a bit hard to say but halfway through I’m sending continuous values for velocity so I can mix 2 or 3 colours and that happens on a single channel. This is a part of the midi spec that is not always understood but it’s really brilliant…

  • GovernorSilver

    Thank you for the update!

  • Jesse Engel

    I think this misses the point. I think the biggest issue with MIDI is not the resolution, but the akward way that it maps into the software paradigm. OSC is a protocol that is easy to write custom software around with plenty of libraries in scripting languages, and more importantly, human readable content of arbitrary type.

    All the interesting modern MIDI controllers map all sorts of abstract functionality into MIDI (like launchpad LED lights, softstep LED display letters, etc) but then that leaves it up to intrepid souls to dig through the manual and write their own OSC APIs (examples: Tom Swirly’s Softstep API, or Will Crossland’s Launchpad API

    This is lazy on the part of the developers, inhibits the creative use of their instruments, and is downright annoying for anyone that has tried to sit down and decode the strange and arbitrary mapping of midi in the manuals.

    As instruments become more expressive, and custom software to utilize all that new control is more accesible to musicians, it’s a downright shame that companies don’t include built-in OSC protocols, or at least offer OSC APIs instead of just manuals.

    • Robin Parmar

      Your point is an excellent one… but resolution IS also an issue. For smooth filter sweeps, amplitude without stepping, etc. FM synth parameters are often sensitive to changes down to one in a thousand, as are chaotic systems.

      I use Reaktor, which happens to have a great OSC implementation, but I am forced to deal with the fact my controllers, like the vast majority of those on the market, support MIDI only. When mapping controls the only way to get around the 8-bit issue is to have a coarse and fine control for the same parameter… but this is ugly and requires a lot of back-end shenanigans. (Since once the fine control moves the value the coarse controller needs to pick up at that new value without glitching.)

      The other hack is to cover the full range with the 256 values available and interpolate smoothly between them. But this means you cannot actually set the intermediary values, even if they are momentarily hit.

      The correct answer is for hardware manufacturers to implement OSC. ;-)

  • Tom Erbe

    this looks amazing, though i hope there is some sort of tactile interface (raised ridges?). i hate it when i have to stare at a controller while playing it.

  • wetterberg

    I am hoping to see an implementation of the playstyle you can get with the Continuum, where your initial placement of the finger is quantized to a midi note, but subsequent slides are free. This is a much quicker way of playing in tune, while still giving us the freedom of movement.

    Reg. the choice of platform, it’s largely an academic debate at the moment, isn’t it? I mean if it really will still be an arduino Due under the hood, then hacking it goes from being “inevitable” to being instant, more or less.

    Right now the key issue isn’t midi/OSC or any of that.

    … it’s price. I know what I’m willing to pay right now, but I’m wondering how mr. Linn wants to position his instrument. It he truly wants it to be the new standard, then he can’t be in the same bracket as these other instruments he compares himself to.