A new, free software release for Novation’s Launchpad could make your device a lot more usable – and it shows how useful OSC can be for hardware, even if that isn’t OSC hardware. (Now, imagine what OSC-native hardware can do.)
There are plenty of misunderstandings about OSC and the monome out there. Among them, there’s the notion that OSC won’t work without “extra software,” or that the only reason to use OSC messages with something like Novation’s Launchpad grid controller would be to emulate a monome.
Here’s the secret: even if you still don’t know what OpenSoundControl is, the idea is to make messages readable.
Novation released the MIDI message mappings for its Launchpad — that’s a good thing! (See previous post.) But because of the utilitarian and somewhat arbitrary way in which MIDI describes devices, MIDI messages just aren’t terribly readable. For instance, one button is called 50h (in hex), or 80 (in decimal). Where’s 80? Uh…. yeah, no one knows. And simple grid devices like the Launchpad and monome illustrate just how abstract MIDI is. The Launchpad has an 8×8 grid of buttons. You might expect them to be numbered from 0,0 to 7,7, or 1,1 to 8,8. But that’s not actually possible in MIDI.
Will Crossland to the rescue. He’s been working on an OSC wrapper for the Launchpad in Max/MSP (easily ported to other environments if you like). This makes the Launchpad more usable and more logical. It’s just one of what I think could be plenty of efforts to use arrays of buttons on music controllers more fluidly and flexibly. That, in turn, could take the DIY musical ingenuity shown by the monome community to the next level.
Oh, and Will even has an open MIDI networking tool, also built in Max – relevant to the earlier discussion of the day.
http://www.chippanfire.com/SoccoChico/Software
Will’s full description follows.
I thought you might be interested in an OSC wrapper I have been making for the new Launchpad.
From the off, this IS NOT simply a way to make the Launchpad act like a Monome. Oh no. This is a wrapper for converting the MIDI communication provided by Novation into a more human readable (and memorable!) OSC formatted protocol. Additionally the wrapper incorporates a banking system that provides one layer of unaltered MIDI communication (for connection and use with Ableton Live, with all the expected features in-tact) and eight layers (switchable from the Launchpads surface) of OSC transmitting (and controlled) decoupled grid action.
The wrapper is based in MaxMSP, but uses it only for selecting MIDI IO ports, udp communication to the ‘localhost’ (via netsend/netreceive to make it Pd compatible) and a single [js] object with the actual handler/wrapper inside it. Oh, and there’s a local loopback function for testing you have the write MIDI IO selected for each Launchpad you hookup… The wrapper (theoretically, not that I own a fleet) supports up to six Launchpads, each uniquely addressable. If you get really greedy, the javascript could be altered to support more; it is just a 3d array of data elements at its core, currently limited to [6] in one dimension…. The limit of six is a reflection of the maximum number of control surfaces Ableton Live supports.
Specs at a glance:
– Supports up to 6 Launchpad devices, each individually addressable via OSC/MIDI
– Retention of the default MIDI mode for use with Ableton (via internal midi bus)
– 8 OSC mode ‘user banks’ (per device) where the Launchpad (well, technically the wrapper) sends/receives OSC using a markup similar to that used by another popular ‘grid’ device [though it does not directly support Monome markup, as row/col/frame etc messages are not used)
– user bank switching from the Launchpad via top row of buttons
– retains all data received on any bank (even if the Launchpad is not currently focused on it) and updates the surface accordingly when swiching banksAs the handler magic is ALL done via a single javascript file, ANYONE can edit the functionality in their favourite text editor. You then need only MaxRuntime to run the code inside. While this is not an ‘open-source’ solution by any stretch, it can at least be tailored to an individuals needs without spending any money. As the wrapper will communicate happily with Pure Data, an avenue exists for freeware development of OSC patches that use the Launchpad as an interface (via the wrapper).
The appropriate files (along with suitably concise/detailed) documentation can be downloaded from my website (http://www.chippanfire.com/SoccoChico/Software)
Finally, the OSC protocol I have used is fully detailed in the download. It is essentially an extended version of the basic subset (i.e. /press and /led) employed by the Monome. My intention is not provide a ‘Monome Emulator’; the similarity in protocol is both a courteous nod to the Monome creators, and logical progression. The Monome OSC protocol is clearly well thought and well suited to addressing a 2D grid so why reinvent the wheel? I’d expect any sensible grid based OSC controller to use a similar markup as the original is so well thought out…
I have added extensions that allow for the multiple device/multiple bank addressing, as well as some extra ‘data’ for the extended colour set available to the LEDs. If you want to use the wrapper with Monome apps you’ll have to get your hands dirty converting between the two OSC protocols (not that that would be too difficult). The lack of support for /row, /column etc messages is just one example of why this is technically an inferior device to the Monome; that said, i’d still be making a wrapper like this for the banking/multiple device features it enables if I had the budget to buy such a beautiful device…
p.s. Where I am saying OSC, at this stage I really mean ‘OSC formatted’. The implementation is limited to using the netsend/netreceive objects in Max (which perhaps limits their reception to Max/Pd?). I’m a bit too new to using OSC to say I am ‘definitely’ sending Full Packet Messages that could be picked up by any OSC client…. I’d be happy for someone with more know-how to take the final steps in making it truly OSC compliant…
I imagine this could generate plenty of feedback, so fire away.