Even before Max for Live was available, hackers had found a way of interacting with “secret” APIs inside Live for custom control, allowing them to customize Live’s behavior and make it work more seamlessly with hardware. That included providing something Ableton themselves had not: real, native control of Live via OSC, for more control than MIDI alone can provide. I was assured such hacks would continue to work, and sure enough, they have. Here’s how to get started.

You may wonder, of course, why even bother now that Max for Live is available? Max for Live is a powerful environment for creating instruments, effects, sequencers, and other devices within Ableton Live, and via its access to the Live API, it can even be a tool for customizing how Live works. But it adds an additional layer of abstraction, it is somewhat limited in how much it can manipulate interaction with hardware, and anyone wanting to use your creations will need to own Max for Live and not just Ableton Live. And not only that, but some people will simply prefer scripting in a language like Python to working with visual patching. (There’s still reason to consider M4L, too; see the full link to its “API” for Live, below. But we do have multiple options)

So, with that out of the way, here are the current solutions:

Make your own MIDI remote scripts.

Hanz Petrov has written an intensive introduction to creating your own MIDI remote scripts in Python, using the new Framework classes:

Introduction to the Framework Classes
http://remotescripts.blogspot.com/

Use OSC, via the Live OSC API Hack (or MIDI)

Ableton doesn’t have native support for OSC — unfortunate, given that’s now a feature of major visual applications (Resolume, VDMX, GrandVJ, Modul8, and others). But while we keep bugging Ableton for OSC to be on equal footing with MIDI, you can make use of a special Python hack that provides an OSC API to Live.

If the above scripting seems intimidating – and I can certainly see why it might be – the LiveOSC API is refreshingly simple. Because you can simply send OSC messages directly, controlling Live with tools like iPhone apps or Processing sketches or even hardware could become comparatively simple – and yes, simpler than working in Max for Live. If you only have MIDI, there’s even a MIDI API, too. Here’s where to start:

Complete documentation of the LiveAPI project [assembla]

http://monome.q3f.org/wiki/LiveOSC

Why it’s nice: you can send something as simple as /live/play/clip (track, clip) and trigger a clip. That’s even more direct than the usual MIDI interface.

Most importantly, this now works with Live 8.1. See the video below for an example of this in action:

mlrV4live tutorial (&casio madness) from StevieRaySean on Vimeo.

Check out his Arduinome build documentation, too. (Arduinome is an authorized clone of the monome using readily-available parts.)

The Max for Live way: Live Object Model

Complete LOM documentation at Cycling ‘74

And yes, it makes my head spin a little, too. (Or perhaps the word is “oscillate.”)

Max4Live.info (Michael Chenetz) has done a great job of making this a bit more manageable. In the video below, he explains how to use the interaction between Max for Live and Live; there’s also a tutorial on sending messages to a control surface like the Launchpad. But note that some of this can actually more complex, and more hardware-specific (APC/Launchpad-only) than the hacks above. It’s a case in which the hacked version actually works a little better than (cough) the official version.

Max For Live Paths, Objects, and Observers from Michael Chenetz on Vimeo.

My own challenge for myself: just make the Launchpad intelligently control device parameters, something it currently doesn’t do. I’ll let you know how it goes.

Thoughts on the merits of these different approaches? Projects you’ve made using one or another? We’d love to see them.

Didgeridoo from bar|none on Vimeo.

You can’t quite dance to it, but bar|none has a beautifully-shot video of a strange, invented instrument constructed with some of the technologies we saw last week. As noted then, new support for OSC in the powerful Kyma sound system means the ability to control imagined instruments in more sophisticated, higher-resolution ways. Just days later, bar|none responded to my post with one of his first experiments. It’s just the beginning of his work, so judge it accordingly – think of the first emanations of a newly-created musical instrument – but it’s a reminder that far-out ideas are possible when you combine custom soundmakers with expressive control.

The controller is Jeff Snyder’s Manta, a touch-sensitive controller with velocity sensitivity and a 6×8 array of hexagons. Jeff showed off his instrument at Handmade Music Monday night here in New York; I hope to follow up with a closer look at the Manta soon. Notably, the Manta is not an OSC device; it’s an HID USB device, just as a typical mouse or keyboard is. HID, the standard drivers for which are included in every desktop OS, also supports high-resolution data, so it’s a second alternative to MIDI for input.

My first Kyma X patch for the Pacarana. Kyma is unreal and let’s you do almost anything in Sound Design. I took a concept of a didgeridoo patch on my modular and built it back in Kyma but with even more expression. This is still a work in progress.

The touchplate is a Snyderphonics MANTA. I spent some time coding some algorithms in MAX to enhance the performance control of the patch using velocity, aftertouch and polyphonic aftertouch + controls using OSC to Kyma.

The Manta is a fantastically wonderful controller. It shows it’s [sic] flexibility and feel here.

The patch is microtonal meaning pitches are in divisions of the western concept of half and whole tones.

Since that video, he’s been trying more sonic ideas:

Been messing with this sound and here’s a version where the didgeri is resonating as if it were a metalic vibrating tube as well. This is just trying to see the kind of sounds I can get out of the patch.

soundcloud.com/barnone/karplusdigeri

This makes me wish I could afford this setup, but if, like me, you’re on a tighter budget, the ideas here could easily be applied to other rigs. Keep the experiments coming!

Updated: bar|none aka Chris Lloyd shares his camera of choice: it’s a Canon 7D with a 50mm 1.4 lens for the “Bokeh blur effect,” a tip from stretta.

Connecting stuff is one of the things musicians naturally do with gear. So, there’s really no reason that musical gear shouldn’t network as easily as Web servers. And yet a basic protocol, built largely on existing standards, meets with responses like this:

“We’ll support OSC when there’s hardware out there.” “Name one piece of hardware that supports OSC other than the Lemur.”

OSC has some major advantages as a network protocol, as a way of connecting software with software, software with hardware, and yes, even hardware with hardware. It doesn’t have to “compete” with MIDI – you can even send MIDI message data over OSC, thus taking advantage of features OSC has that MIDI doesn’t (like time stamps, which your tools could use to calculate latency even if you don’t use them directly). Yet I’ve been listening to this argument for years now. “Any computer” counts as an OSC device, but even when tens of millions of iPhones and iPod touch devices hit the market (not to mention other mobiles), software developers were still pointing to a (completely absurd) “lack of hardware.” How tens of millions of gadgets can count as “nothing,” I don’t know, but maybe it’s because a lot of them were phones, not music devices.

Well, here’s a combination that ought to get someone’s attention. With the iPad about to launch next month – likely to be followed by more multitouch devices running Android, Linux, and Windows – we’re not just talking phones any more. And the folks at Symbolic Sound, makers of the insanely-powerful sound generation Kyma environment, are adding a proper OSC implementation. Even if you have no interest in the (wonderful) Kyma, now available in more-affordable Paca(rana) devices, this is one to watch.

What you can do:

Use OSC directly, via a direct connection and even onboard Ethernet on the Paca(rana). That opens up the use of devices like Lemur, and, yes, iPad.

Use MIDI over OSC from your existing MIDI devices and software. Explanation (again, worth reading even if you aren’t in the market for a Kyma):
http://www.symbolicsound.com/Learn/BidirectionalMIDIStreamsOverOSC

In this case, the OSC connection acts as a virtual MIDI devices, with three merged inputs and one output. The same is possible on other devices, too, however, meaning that combining OSC and MIDI doesn’t have to be a chore.

Details on the software update:

OSC-enabled Kyma X.74 is a free software update for registered Kyma X owners. OSC communication requires the Paca or Pacarana sound engine. Kyma X.74 also comes with additional features, including an 11-times speedup in the Virtual Control Surface, support for the MOTU Ultra Lite Hybrid mk3, TC Electronic Impact Twin, and Prism Audio Orpheus converters, track-pad compatible menus, refinements to the Tau resynthesis, and more.

Open Sound Control (OSC) for Kyma: Bidirectional communication between Kyma, iPad, Lemur, and other OSC-enabled devices & software

And if you’re using Max and Max for Live, you can use a custom external for MIDI over OSC in that environment, as well. (That said, control of Live could be more intuitive if Ableton were to evaluate native OSC control support in Live, as currently exists in nearly all mainstream live visual applications. There’s an unofficial method that demonstrates just how powerful this can be — see comments.)

Max and Kyma

Kyma is still a high-end solution, but at least the entry-level Paca – still absurdly powerful – is now down below US$3000. If I had $3 grand handy, I’d certainly consider buying one. I don’t, so I think of it as that Steinway grand I can’t afford or fit in my apartment. That doesn’t mean I can’t pay attention to what it does – and, indeed, OSC implementation like this could apply as well to a $5 or open source app, to mainstream hardware or DIY solutions, as much as the Kyma.

The phrase is overused in the media and culture today, but I think it’s appropriate here:
“Just sayin’.”

Thanks to Lowell Pickett, Martin Wheeler, and others who sent this in.

Argos Interface Builder, v0.20 from Dimitri Diakopoulos on Vimeo.

You know the game: you decide you want exactly 8 knobs and 10 faders. But your hardware interface has 8 knobs and 8 faders. And then you realize you could use 4 more knobs.

The appeal of touch interfaces is clear: you get controls that grow and change. So now, a generation of mobile apps is working on giving you that flexibility on touch devices. The iPhone is just the start: now the iPad, with greater real estate, will go head to head with 5″, 8″, and laptop-sized screens running Android, Linux, and Windows.

Argos is an early-stages (but usable), free and open-source tool that could help you be ready. Built in openFrameworks, the C++-based cousin to Processing, the app lets you drag in basic widgets like buttons, sliders, toggles, and x-y pads, and assign them to OSC. That opens up control to various music and visual apps. (The OSC assignment tool does bear some similarity to that on the Lemur, though it’s simpler.) The openFrameworks roots should make this easier to port to multiple platforms.

http://argos.dimitridiakopoulos.com/

Developer Dimitri Diakopoulos, a BFA student at CalArts, is looking for developers and actively working on making this work on the iPad and its additional screen real estate – with other platforms possible, too. (If some of the PC “slate”s simply run Windows 7, you might be able to just switch the thing on, no port required — and run the app you’re controlling on the same machine if you so choose. We’ll have to wait to see what ships.) Stay tuned for more news on this, but this is well worth a look now. (Synthtopia was on top of the story earlier today.)

I’m personally interested to see if the protocol established by open iPhone app mrmr could allow over-the-air template sharing, and whether all these apps can interoperate with TUIO, the touch protocol developed for the reacTable. I said it earlier today, but there is some real potential in convergence, so I invite anyone who wishes to join that conversation. The trick is, you want to initially let people do their own thing, but then take all those “my own thing” solutions and put them together into an actual standard. If you try to impose the standard first, it might not actually work in the real world, but if you fail to standardize, you lose the advantage of interoperability. On the other hand, I think this very quandary is best solved by small groups of passionate developers, not overly-formalized process.

Augustus Loop is a tape delay effect with some out-there features – try a one-hour maximum delay setting, tap-in length, virtual tape features, the ability to sync multiple instances, and lots of unusual sound design features. It can do things that even tape wouldn’t imagine.

Version 2.2.0 has some nice new features. It incorporates 64-bit support, although unfortunately that 64-bit support is Mac-only for now.

Also new in version 2.0 (2.2 is the 64-bit bump):
A skinnable, scriptable GUI
OSC support for full control with OSC (grab your iPhone, folks)
MIDI and OSC scripting in Lua, for customizing control

Those are some trends I’d like to see more of. It proves that plug-ins can be more open to user customization, and that even a tiny, independent developer can embrace the flexibility of OSC as a control protocol.

Demo times out after 15 minutes; US$49 for the full version. Mac + Windows (AU + VST).

Explore the goodness and some of Expert Sleepers’ other unusual plugs:
http://www.expert-sleepers.co.uk/augustusloop.html

RFID tags may have negative privacy associations when they’re used without someone’s knowledge. But embed these simple identifiers intentionally, and they can be a cheap, flexible way of tagging the world around you. Add OSC support with a free tool, and you can make anything into a basic music controller. That’s what Martin Kaltenbrunner – best known for his work on the ground-breaking ReacTable music table – has done with his own free software. It’s simple enough that you can easily make use of it, or take it as an opportunity to brush up on OSC and Pd.

This sort of odd, out-of-the-blue example is the perfect illustration of why OSC matters. Quietly, gradually, OSC is describing the world around computers in intelligent ways. In contrast to MIDI, with its resolution limits and arbitrary categories (vibrato rate?), OSC can standardize anything. What previously required advance standardization can now be truly open and even improvisational. The old way of standardizing: go in front of some sort of committee for approval. (RFID tags for music? Not likely.) The new way: go ahead and do the implementation, gather feedback, and if it works, other people will follow your specifications to ensure their stuff works with yours. In this case, Martin plans to add the RFID tagging to his TUIO2 protocol, which made what would have been just a cool one-off project (ReacTable) into a viral phenomenon of work with touch and tangible input. Martin writes:

I just released a new application, which intends to simplify the construction of tangible user interfaces based on RFID readers. Using this tool, the RFID add/remove events can be processed by any OSC
enabled application.

You can download the nfOSC tool from here:
http://code.google.com/p/nfosc/

The demo video shows the nfOSC application used together with the quite affordable touchatag RFID reader. A simple PD example patch receives OSC messages from nfOSC and starts a sample loop, when an RFID tag is detected by the reader device, the loop is stopped when the according tag is removed.

At the moment this tool just defines two simple ADD and REMOVE messages including the RFID tag IDs, but I am planning to integrate the tool into the future TUIO2 toolkit.

On its own, of course, it’s a simple hack, but I can imagine this having powerful implications when used in combination with another control method. And if you like the way the implementation works, you could use this same technique to apply to some other controller.

7up 2.0 – Introduction from makingthenoise on Vimeo.

What if the world of musical performance suddenly started moving a whole lot faster? That’s certainly the case among a handful of monome- and grid-wielding electronic artists.

In an evolutionary breakthrough, what previously had appeared in a period of months is showing up in a period of days, as long-simmering ideas come to the fore. Spurred by the blank-slate, minimal grid of the monome (and its design as mirrored in similar controllers from Livid, Novation, and Akai), musicians are re-imagining the step sequencer in new permutations. Many of these creations in recent days have been coming to Max for Live (site | cdmu tag), taking advantage of the potent combination of Live as a host, third-party plug-in instruments as sound sources, and Max’s own capabilities with sequencing and sound. But it would be a mistake to see this as a phenomenon limited to Max for Live. Other development efforts, built in free tools, work from the ground up instead of the top down, and may use code in place of patches. These efforts are running in parallel, taking ideas from one another, responding to each other as a challenge. And that could make the coming months very interesting, indeed.

What’s exciting to me is that a set of ideas is emerging that may go beyond any one tool. Even past the grid, what we see is people beginning to refine the idea of live electronic performance into reusable, modular components. There is a greater sense than ever that what computer performance is treads a line between composition and live playing. At the heart of that concept is embodying both in an “application,” and making that application work on the grid.

7up 2.0 Arrives, in Max for Live

The biggest news is that 7up, the popular multi-page, multi-module performance app for the monome, is reaching a big new release. 7up 2.0 builds upon an earlier version written as a standalone application in Java.

7up takes the grid and builds a single performance tool that has multiple functions. One strength of this approach is that, even with 7up’s various capabilities, controller assignments are fixed. You can learn 7up and build muscle memory with it. Equally significant, you get a set of predictable modules for various tasks, as pictured. stretta’s work, also using Max for Live, goes another direction, making the monome a generic controller for any number of performance “applications.”

For people working with Live, 7up is more functional in Max for Live than it was as a Java standalone. Among other things, creator Adam Ribaudo (makingthenoise) notes:

• 7up components install into your normal device library
• Drag and drop components to start using them
• Extensible components mean community members can build their own in Max
• Virtual MIDI no longer required

More:
SevenUp site, with documentation + more
monome message thread

stretta, Live, and the Musical “Application”

maxforlive: monome integration from stretta on Vimeo.

Matthew Davidson, aka stretta, has long been both a virtuoso performer and master developer for the monome. Now, he’s going one step further, to try to make the undifferentiated grid of the monome work as a fully-functioning control surface, integrating multiple applications without ever having to leave the monome’s buttons.

It is one thing to adapt max patches for maxforlive but it is another thing entirely to construct them so they can handle multiple instances without stepping all over each other by accessing the same data. Then there is the issue of telling monomeserial which instance has control of the monome hardware.

I wanted to make it elegant to use. For example, if you click on a track in live that has a monome application running, that monome application is in focus on the hardware. It is this level of integration that makes maxforlive so appealing. So, now you can run as many obos, polygomes, stepfilters, or automatorgators as you like, and the monome switches between them effortlessly.

“Applications” and “musical compositions” take on interchangeable meanings. When stretta uses his “polygome” creation, it is an instrument, a composition of sorts, and – in the context of Live – a device. We’ve long lived with the ability to introduce new sounds and instruments into a studio simply by connecting them. With Max patches operating as modular compositions, you can drag and drop interactive musical ideas. (Okay, granted, such things appeal to the small portion of the population who can express their ideas in Max patches, but if you do count yourself among those numbers – or if you’re just lucky enough to be stretta – it’s all pretty amazing.)

Watch what happens as stretta drops polygome into a Live set:

maxforlive: polygome from stretta on Vimeo.

This certainly illustrates the advantage of Max for Live, for those who want a host for Max patches. As stretta puts it:

maxforlive simplifies monome workflow. For example, if you want to use polygomé with a DAW, you must open your DAW software, open polygomé, set up sync in polygomé, set up sync in your host app, set up MIDI output routings from polygomé, set up MIDI routings in your DAW. There is a lot of overhead. With maxforlive, you simply drag polygomé into your track as a MIDI effect. Then you can start playing immediately. There is no setup. Everything is in sync.

stretta hasn’t yet released this new version; that will come soon, so stay tuned.

…and Parallel, Free Software Solutions

Here’s an illustration of how the Max inside Live world might intersect with people working in very different ways. Inspired by the same problems stretta is trying to solve, there’s an effort to build tools well beyond Max or Live.

Brian Crabtree (tehn) has raised discussion of potential for a new monomeserial that would use OSC in a standard way to talk to multiple “applications,” across ports. That could be a number of Max patches running in Live, or a Max patch and a Processing sketch, or anything else. And it could ultimately have implications for hardware other than just the monome.

monomeserial next revision

See also this application, which handles OSC routing:
MonoRoute Software Release

Ohm + Max for Live

LividStep: step sequencer made in Max For Live from Livid Instruments on Vimeo.

For another view of how you might make a grid work with Ableton Live, here’s a glimpse of Livid’s Ohm64/block hardware in action with Max for Live. In this case, the grid itself replaces the mouse for what you might have done previously onscreen, arranging a sequence. Livid Instruments writes:

This details the major functions of Livid’s Max For Live device, LividStep, including playback, how to: add and change sequences, control timing, navigate Live, and control instruments, all from the Livid controller.
The device works in Ableton Live with Livid ohm64 and block MIDI controllers. The device creates an eight step sequencer on one row of the 64 button grid. Fill eight live tracks with eight devices to fill the grid. Each sequence has independent time control for a huge variety of rhythmic possibility.

And, if you make it to the end, yes, the irritation at those who don’t use a Livid controller is real and palpable :)

Livid’s patches are open, so this approach doesn’t have to be limited to Livid hardware.

Little Scale’s Standalone Sonic Creations

Little Scale’s efforts for the Novation Launchpad are aggressively simple, and beautifully so. Sebastian Tomczak is known primarily in the chip music scene, so the minimalist aesthetic is definitely part of his work. (Not to be confused – as I did initially – with Ripple, a framework of musical tools built by Morgan Packard in SuperCollider.) It illustrates that there doesn’t really have to be a UI; the Launchpad sequencer can run purely on the monome. (Add embedded hardware into a monome case, and you could have your own DIY musical instrument, standalone, without a computer as such. But that could come later.)

Sebastian is doing interesting like this “waveform editor”. It could certainly also be a prime candidate for a SuperCollider version.

Both of these projects were built with Max 5 standalone, though they could work nicely in Max for Live or other environments.

Gridism?

There’s just a handful of people involved, scattered geographically around the globe, but something is definitely happening – even as these artists work in relative isolation.

I think you can thank, in part, the limitations of the monome grid. Deciding to restrict the interface, and building something from scratch – whatever the development tool you use – is causing people to really focus on the musical idea they wish to express.

Of course, that means you don’t need a monome or Max for Live or anything else. The real power here is focusing on what you’re controlling live, and using restrictions in one place to breed creativity elsewhere. (Translation: what can you do with an 8×8 grid with no velocity sensitivity? Be creative.)

For anyone whose complaint about OSC aka OpenSoundControl is that it lacks broad hardware support, I have one word for you:

Unicorns.

OSC now runs on magical unicorns. (Would a unicorn not want high-resolution, human-readable messages encoded with time-stamps? I think they would. And because OSC is transport-independent, it can absolutely run on magical Unicorn Beams.)

No idea what this post is about? Don’t worry — I’ll have a talking unicorn narrate a proper, sophisticated, complete introduction to OSC for beginners soon. They’re magical, so they can make complex topics lucid to any audience.

Yesterday, I wrote, entirely tongue in cheek and not expecting anything to actually come of it:

I think maybe I’ll start running screaming headlines with things I want in them, if only for good luck. Tomorrow on CDM: “You Know What Annoys Me? The Fact That We Don’t Have Unicorns. Magic Unicorns. Who Speak OSC.”

Today, via Twitter, Max patcher and audiovisual Merlock Andrew Lovett-Barron of Toronto wrote to me:

@peterkirn I made you a unicorn that speaks OSC.

And here it is, for your enjoyment, in Max 5 patch format:

http://andrewlb.com/max/Oscicorn_for_CDM.maxpat

This is, of course, very silly. But it’s an excuse to pitch Andrew’s site, which has lots of patching and coding goodies and visual creations:

http://andrewlb.com/

And perhaps more importantly, OSC now has a mascot. That means t-shirts, plushies, costumes, the lot. Your job: what should the name of this unicorn be?

All MIDI has is an antiquated DIN cable. Oh, yeah, that and millions of compatible devices. We hope OSC support won’t be as rare as unicorns.

Side note: please don’t troll this post, tempting as that may be. It’ll make the unicorn cry.

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 banks

As 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.

Laptop musicians are feeling out of sync — literally. But we can work together to help the situation.

Computer music making can be an isolating experience. But when users try to use their eminently-mobile tools to play together in the same room, they often find that the technology resists. MIDI, as a serial protocol, isn’t designed for networked environments. Software interfaces are designed to be visible to only one user. Sharing between users rarely figures into designs. Input points are made to be single-user only.

And most importantly, just getting a couple of computers to sync can be a Herculean task — one that seems to have gotten worse with advanced computer software rather than better. In short, for all the technology we have today, we’ve actually regressed from the state of interoperability 20 years ago.

I’ve been hearing more and more frustration over sync, as people begin to collaborate with multiple computers as they would with a small ensemble of instruments. Ableton Live is the most frequent example, but it’s only one case – and I suspect part of the fault is that people are more likely to try to sync multiple copies of Live. When I spoke to Depeche Mode’s Martin Gore in the spring for Keyboard, Martin complained that they had trouble syncing his Apple Logic sessions with other band members using Pro Tools and Ableton. This weekend in Los Angeles at the DubSpot sessions, Glitch Mob’s Justin Boreta talked about the issues that group has had with multiple copies of Live.

Synchronization is, by definition, a tough thing to do. But musical engineering is replete with challenges; it’s no longer acceptable to simply say “live with it” and walk away. It seems we need both better shared knowledge about what sync is how to make it work, and better engineering solutions on the software and protocols side to support the way users want to work. And yes, we need a new sync standard that goes beyond what’s presently available in MIDI alone.

Focusing this discussion, I just got an essay in my inbox that I think focuses the issue. I will try to speak to Ableton’s engineers about the matter, but this isn’t really about Ableton alone, so I’m posting it here first. We could use more data about how you’re working with various software and hardware, what techniques you’ve developed, and what frustrations you’ve had. We have a wide community here of users and developers (and a whole lot of you are both).

Mark Kunoff writes:

I’m writing to you today about an issue which I believe has been a sore spot for many Ableton Live users – *reliable* syncing of two or more computers – particularly for those of us who are attempting to sync for the purposes of *live performance*.

My musical partner Patrick Petro and I (together we perform as “Othership”) have been struggling with this issue for several years now. At present time, we have a decent solution using midi time code. Initially we attempted to use Midi “clock” but our friend Steve Duda (partner of Deadmau5 in BSOD) informed us, “using Midi clock is as reliable as syncing to a boat motor.” He informed us that in BSOD, he and Deamau5 have reliable sync between their 2 laptops using MTC, although the main drawback is the inability to fluctuate tempo – you must run at a consistent tempo the whole time. (You may be aware of this already, but Steve is the person responsible for ‘Molar’ the incredible step and loop sequencer for the Monome, was a programmer for Devine Machine and has worked for many renown artists in the music industry such as Trent Reznor. We are very fortunate to benefit from his consultation!)

Currently we are both using Macbooks and syncing via Ethernet with Audio File Engineering’s “Backline” app to generate MTC. This method has been about 95% reliable, but after reading an article on Ableton Tweets (http://abletontweets.com/post/126300941/why-midi-sync-over-ip-may-not-be-a-good-idea and our response – http://abletontweets.com/post/224247258/midi-sync-in-ableton-live-why-so-complicated) we are going to acquire a dedicated external device to generate MTC such as a Motu Timepiece.

I feel strongly that Ableton has not addressed these issues sufficiently and could do a better job of educating their user base as to the challenges that face performers in achieving reliable sync. I’m not expecting a walk in the park, but as of yet Ableton has not provided comprehensive documentation regarding these issues and places most of the responsibility on users to figure it out for themselves. We are (and have been) perfectly willing to educate ourselves but for the most part this issue remains elusive to the majority of Ableton Live users.

The Ableton Live forum posts regarding sync are fraught with dissension and are excruciating to read to say the least. I feel I’m empathetic to the complexities of programming audio applications, but in my estimation Ableton tech support’s explanations toward this issue have been mostly open ended. Many users report these issues only to report back that Ableton’s tech support doesn’t respond. I have experienced this as well. Certainly there are enough customers who want a better solution.

I feel it’s time to launch a concerted effort to organize users and demand that Ableton addresses this issue once and for all. Perhaps this solution wouldn’t even involve midi at all. Ideally this would be an open protocol such as OSC, but I wouldn’t be opposed to a proprietary solution – just as long as there is a reliable one.

The main purpose of this correspondence is seek your and CDM’s assistance in sponsoring an effort to encourage Ableton to address this issue once and for all. I feel CDM could be quite helpful in garnering leverage toward this effort (a simple blog post, or ideally a dedicated section) to organize users and to demand better sync ability between two (or even multiple) laptops running Live – even from unlike computer manufacturers. I’m sure you know artists with valuable expertise in this area.

Even if the issues regarding sync via midi are insurmountable, there have to be CDM readers who have developed reliable methods of two or more persons performing with Ableton Live and it would be great to have one centralized portal where discussions of working methods can be discovered.

Thank you for your time.

Again, my personal intention is not to single out Ableton — I’ve heard similar complaints about other scenarios, and moreover, I think the “open-ended” tech support response occurs when there isn’t an easy solution. Tech support alone often can’t deal with something as multi-faceted as sync, so it’s time to engage other users in this, as well.

I’ve also spoken to Owen Vallis and other folks about how sync could be executed more effectively over network protocols, and specifically how the time stamp feature in OpenSoundControl might be used in conjunction with MIDI clock messages.

To kick things off, let’s comment here, but I’m also setting up a special Noisepages group for users to share experiences and tips:

Sync or Swim Group [noisepages]

(Incidentally, CDM contributor Matt Ganucheau is joining me Saturday at a WordPress developer intensive here in New York, so we’ll be picking up development techniques to work on the Noisepages community, too.)

Jump in, say hello, and let’s talk about how we can make sync work in real-life musical situations.

I’ll also be talking to more artists and developers about their experiences and suggestions, and will pass along your feedback, so expect a report back. In the meantime:

1. Are you routinely trying to sync multiple musicians?
2. What software (and hardware) tools do you use?
3. What have been some frustrations?
4. What techniques have worked, or what have you learned you might want to pass along to other users at various skill levels?