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?

Max For Live Sneak Peak from max4live on Vimeo.

Suddenly, I have an image of American Ableton hackers patching on their MacBook over Thanksgiving turkey.

After a long, long wait, a public beta of Max for Live is available. The software incorporates the full version of Max/MSP/Jitter – complete with visual output, video processing, and 3D capabilities – with the Live host. Max patches operate with all their usual capabilities as devices inside Live. User interface elements are available to give Max patches conventional Ableton device interfaces, and there are even pre-built elements for useful functions like frequency displays and MIDI patterns. Via the Live API, Max for Live patches are also able to control most elements of the Live interface.

Because of Max’s networking capabilities, Max for Live devices can also be used to route OpenSoundControl data into Live. That isn’t necessarily with the same ease as you might route MIDI, and there’s still no native support in the Live interface, but it is a step forward.

Our friend Michael at max4live.info has been busy documenting the new software. His overview video is at top, and for OSC coverage, see his tutorial [part 1 | part 2].

Updated: Pricing has now been announced.
Max for Live is not included with Live 8 or even (perhaps surprisingly) Live Suite. It will be a US$299 / EUR249 download, available separately, on top of the cost of Live 8 or Live Suite 8. If you already own Max, you’ll have a set of crossgrades available:
1. You own Live. You can add Max for Live for US$99.
2. You don’t own Live, and want just Live. You can get that and Max for Live for US$449.
3. You don’t own Live, and want the whole Suite. Suite plus Max for Live crossgrade, US$699.

Total cost:
Max owners without Live: US$449-699
Live owners without Max: US$299 + cost of the upgrade to Live 8
Max + Live owners: US$99 + cost of the upgrade to Live 8

I think this could arguably be worth the investment, but given the discontinuation of support for developing VST, RTAS, and AU plug-ins in Max – a feature that was formerly free – I expect some resistance. Also, as previously announced, there is no known Max for Live “runtime,” meaning Max patch developers don’t really have a distribution outlet for work made in Max for Live, other than other Max for Live users.

Sign up for the public beta on Ableton’s site, and you’ll be able to grab the downloads (details below). You must be an Ableton Live 8 owner, though you don’t need to own Max 5:
http://www.ableton.com/maxforlive/beta

At the bottom of the page, you’ll have a direct link to download Live 8.1 (the official current build of Live is 8.0.9 otherwise), and a link to Cycling’s site to download Max. (Note: the Max link worked this morning, then promptly disappeared, so it’s possible they’re uploading an updated build is now back up.)

There are full instructions there. I was able to simply click a button and become a beta tester; hopefully you have the same experience. You’ll need to install two pieces of software, both Ableton Live 8.1 on the Live side and Max 5.1.

For the Python-based Live API, and the MIDI and OSC interfaces based on it, this should also come as good news. Live 8.1 should theoretically represent a more stable, feature-complete, fully documented version of the Live API under the hood in Live. That means even without Max for Live, it may be possible to, say, route an OSC input into Live as easily as a MIDI control surface.

If you’d like to join in with other people working on hacking Ableton Live and ask questions, try out our Noisepages group, which should now be functioning properly with a forum, wire, and networking features. More to come with this, with Max for Live, with OSC, with other tools, with… yeah, I’m glad I own a coffee maker.

http://noisepages.com/groups/ableton-hackers

The “space bassoon” Eigenharp seems to have landed from another planet. Today, I’ve got good news: it’s bringing alien gifts with it. By next year, both the software and the high-performance protocol the instrument uses will be open source. Taken together with other advancements in the open source community and with protocols like OSC, that could mean we’re at the vanguard of a golden age for more open, more intelligent, more expressive digital instruments.

Genuinely new music controllers made available commercially don’t come along very often. So this week’s news of a strange but wonderful-looking instrument shaped like a bassoon with customizable key controls turned many heads. With high-resolution, high-frequency data and reliance on the computer for everything from sound generation to mapping the keys to different tunings, the computer connection matters. Eigenharp’s chairman, John Lambert, sets the record straight for CDM on the software, the way it talks to your computer and other gear, and how open the tools and protocol will be.

I’ll be talking more with John next week, but I want to bring you this news now. Part of blogging means that you don’t hold back – you share that first reaction and then learn more. I’m pleased to say I was dead wrong on the Eigenharp. What looked on the spec sheet like MIDI-only communication and proprietary software turns out to be just the opposite. Sometimes, being wrong is great. Here are all the details:

What protocol do the instruments use?

The instruments talk to their base station by a dedicated, high speed, differential, transformer-coupled, error-correcting digital protocol designed (and tested) for use in noisy stage environments by ourselves. The wire used is a 4 core, standard star quad mic cable and can be up to 40M long. The base station then talks to the control software running on the host PC (Mac at the moment) via a dedicated protocol over USB2. In the host system, the native protocol used between agents (our software components) is a network protocol called Eigentalk. This can run over Ethernet wires (with slightly increased latencies due to some smart jitter buffering we do). We will be making this public and freely available (when we open-source our main software) in Febuary next year. There is an open API, to be published at the same time, for our equivalent of AU’s or VST’s, hosted in our software, EigenD. This is rather richer than the AU and VST API’s, for reasons connected with the expressiveness and configure-ability (is that a word?) of our system. A couple of interesting AU vendors are looking at producing native EigenD instruments at the moment, and I think there will be many more in time. We try to avoid MIDI wherever possible as it has so many serious performance limitations.

Had you considered OSC?

We did have a look at OSC but there are a bunch of things that our protocol does that OSC didn’t (not least of which, for example, is clock syncronisation for jitter removal, utterly vital over ethernet for live performance) so we decided to grow our own and release it. Absolutely no reason whatsoever that we can’t interoperate fuly with it though, I suspect that an OSC EigenD Agent will probably come quite soon after the open source release.

Ed.: Actually, with OSC (OpenSoundControl) moving increasingly toward broader input and assimilating other standards, I can easily imagine that a future implementation of OSC could begin to implement these features. More on both protocols in the coming months. -PK

Is it possible to use this as a controller for MIDI hardware? MIDI software?

Yes, EigenD has in and out MIDI gateway programs. The incoming [MIDI] is mainly used for pedalboards at the moment (to control scale, key, tempo, etc.), although there is no reason you couldn’t use a midi keyboard to play notes. We’re using the MIDI out to do a wide variety of things, including playing MIDI sound modules, and controlling video DJ software and lighting systems. There is a huge reduction in effective bandwidth when ‘downsampling’ to MIDI, but for a lot of things it still works very well. And of course, the AU and VST standards (which we fully support) are a kind of MIDI interface.

Is it possible to access its native protocol for custom software / Max-Pd patches and the like?

Well, we’re open sourcing the whole thing early next year, and I think there’ll be a lot of work done to glue all sorts of external stuff in then. Max/MSP has attracted a lot of interest in this area. The whole of EigenD is kind of built for this really. We’re an Open Source company: my main personal desktop is Linux and I have a strong personal commitment to open standards. I offer a number of ‘programming bounties’ for Linux improvements on my personal website at http://johnhenrylambert.com.

Tell us more about open-sourcing the software. What tools did you use to build the software.

It’s written in a mixture of C++ and Python. It’s quite scary code, but very clean and pretty, with little ‘cruft’. I think the open source community are going to have fun with it. Its a big system too, 8 years of R&D in one huge release. I don’t think that there’s been anything quite like this open sourced before in the music world – it is a bit as if Logic or Ableton were GPL’d tomorrow.

Thanks, John! Stay tuned for more details, and let me know if you have specific questions for the creators.

Take a weekend, and make something: that’s the challenge behind the Music Hack Day, which joins a growing phenomenon of events built around collective creation. (CDM held its own tangible interface hackday online, which I definitely hope to follow up soon!) Initiated by Dave Haynes of music sharing service Soundcloud, the Hack Day has already hit London. Many of the events were Web app-based and focused on consumption rather than creation of music, but we also saw a chordal synth plug-in and beer bottle percussion instrument.

The Berlin Hack Day, which wound up earlier today, offers still more projects focused on the creation side of music hacking. Having Ableton and Native Instruments as sponsors likely helped the mood. And as you’d expect from one of the world capitals of creative hacking, Berliners don’t disappoint.

Among the projects: a beautiful, elegant 3D sequencer, a fun bird-and-sky multitouch soundmaker with multitouch trackpad input, and a robotic xylophone controlled by monome. Someone even worked out a way to turn NI’s Maschine into a rhythm game, complete with Street Fighter sounds.

I’ve got some of my favorite projects here, but see also an eyewitness report (in English and Italian) at Audio News Room:
Just back from Music Hack Day Berlin
… and keep your eye on the wiki:
Berlin Hack Submissions

xylobot run by monome from robb on Vimeo.

Monomist Rob Böhnke and Ramsey Arnaoot created one of my favorite hackday projects so far: a monome-controlled robotic xylophone. The ingredients: one monome grid controller, one Java application for step sequencing to the output, one Arduino open source controller board, and one terrific xylophone “robot” made of an array of servos that strike the bars of the instrument. Oh, and some hot glue and wood, of course.

Project details

Debugging

Audio loop

Of course, what’s especially impressive is nailing this in just a weekend – imagine what they could do with more time and iterations.

Proof that musical visualizers don’t always have to be trippy, futuristic, Tron-like 3D landscapes (and that’s me speaking as a fan of such things), Gernot Poetsch instead chose a whimsical environment with clouds and cartoon birds, inspired by the graphic identity of Twitter. (No actual Twitter is involved, meaning you lose the, ahem, unreliable, buggy, unfiltered chat network but keep the cutesy happy sky! Works for me!)

The visuals are built in Quartz Composer, which via OSC transmits messages to synthesis language ChucK for noisemaking. The surprise is, the multitouch input is not a Lemur or an iPhone – it’s the new MacBook touchpad under Snow Leopard!

iLoveAcid is a beautiful-looking nodal sequencer by Jakob Penca which uses wireframe “tracks” to guide music playback through a sequencer, transmitting events to your soundmaker of choice via MIDI or OSC. By using curved timelines and connections, it’s a veritable model railroad of music, in which formations combine to form more complex structures instead of simply stepping across a grid. Despite appearances, it is so far only two-dimensional – but then, the z displacement could easily be assigned to some form of modulation. I’m really eager to see the video of this.

One ingredient: Processing, which makes it easier to write visual code and to connect to Java libraries.

Project Page

The hardware controller for Native Instruments’ Maschine software drum machine has been adapted to other software, like Ableton Live. But this is surely the first time it’s been made into a game. Using Maschine’s MIDI output as a game control and sounds from Street Fighter, MaschineFighter is a simple, Simon-style rhythm game. Unlike Simon, though, there’s a twist – instead of rote patterns generated in advance, you face off against a friend and try to out-rhythm each other, battle style. I think it’s actually a pretty brilliant idea, and could become a new sensation for us electronic music nerds – not to mention, it’ll finally test our rhythm in a way electronic performance often does not. (Correction: It is Mac-only, making use of the PYMIDI Objective-C based library, which, since everything else that starts with “Py” usually means Python – a la jThings that mean Java – I assumed, incorrectly, was built on Python. But anyway, if you like the idea, carry on! And, actually, having a pure Objective-C CoreMIDI interface is also pretty awesome.)

Hoping for a video of this, too.

If you have a project that didn’t make this list, or if you add documentation after the fact, let us know.

It’s still anyone’s guess exactly what fruit parent technology maker Stantum may soon ship, but the JazzMutant Lemur touchscreen is getting a component update soon. Nat Lecaude points to a quiet MySpace post from JazzMutant with the details of a coming manufacturing change.

“…the next batch of Lemur will feature the latest generation of our multi-touch technology: better optical performances, higher precision, greater accuracy and responsiveness. It will be clearer and have brighter colors. We plan on launching the new Lemur in early October, and of course we will keep you updated as we get closer to launch date. We once again thank you for your patience, and look forward to sharing the excitement early October!”

It’s actually quite remarkable to me that JazzMutant remains alone in this market – and with Stantum focused on the mass market, that could be the case in the future, too. The issue is that doing multi-touch well still costs some money. There are basic implementations on computers that are cheaper, but that restricts you to a few computer models, because slapping multitouch overlays on displays remains pricey. So HP can get a few computers to the mass market, but not without cutting some corners and not even on that company’s full range. The iPhone has brilliant multi-touch control, but a mobile form factor makes this much easier.

I’ve got some videos demonstrating what’s possible with the Lemur coming soon, as well as some notes on how the software has evolved since I first saw it in its initial release. Even if you don’t want or can’t afford a Lemur, it’s a fascinating demonstration of interaction design and OSC, with lessons (inspiring and tough alike) for other interfaces.

Photo by Rainer Knobloch for CDM.

Pronunciation of some common music tech terms has been a source of debate. Generally, though, there’s only one right answer. I had hoped to kick off a pronunciation guide yesterday or today, but now I really can’t resist – not with none other than Tegan & Sara getting together to debate the right way to say Moog.

Don’t get me wrong. I love cows, and the sound “moo.” I suggest if you have something you want to name Moo, you should, like your own MooVerb max patch or something. However, here goes, a few of my favorites:

Moog: Rhymes with “brogue” or “rogue,” not the sound a cow makes. Don’t say “Moooooog” unless you want to get funny looks from synth nerds, or if you’re teaching synthesis to livestock in a dairy.

Monome: The community-based, (partly, at least) open-source controller rhymes with “MA gnome,” not the Spanish-sounding “Ma gnome ME.” You should not be able to use it in a couplet with paper mache. Get it? Two syllables. Sure, this pronunciation varies, but the two-syllable version is what the device’s co-creators call it.

OSC: Pronounce the letters of the open communications protocol, as in “O.S.C. / oh ess see”, not “osk” – though that would have been kind of cool. Think, “Rah, rah, rah, Give me an O! Give me an S! Give me a C! What’s that spell? Better than MIDI! Time-based messages, higher resolution, transport-independent high-speed networked communication with auto-discovery, gooooooooooOOOOO O.S.C.!” (People sometimes say this site is geeky. I have no idea what gives them that impression.)

And for now, O.S.C. stands for Open Sound Control, even though in one spot on the JazzMutant website it’s called “Open-Source Control.” Just get ready for this to change – because OSC really isn’t specific to sound, it may need a new name, like Open System Control. (A recent paper suggests dropping the “sound” in the name.)

MIDI: Rhymes with G. Gordon Liddy, or P. Diddy, or Tweetiebird saying “Piddy.” And, actually, it occurs to me I’ve never heard anyone mispronounce this. Fascinating – an acronym that’s actually intuitive. Oh, but “C.C.” stands for “Control Change,” NOT “continuous controllers” — look at the CC specs; most aren’t continuous. There. I got to be anal about something anyway. Updated: consensus is actually that “mee-dee” is a mispronunciation for native-English speakers, but likely makes more since than “mi-dee” in other languages — particularly if you speak French. So, in other words, it’s an acronym, and makes the most sense to pronounce in the natural way you would in your native tongue. (For English speakers, who knows what vowel sound is appropriate given how screwy our language is, but the creators of MIDI all say middy.)

Maschine: Native Instruments’ drum machine software and controller is German-engineered, so say “muh SHEEN uh,” three syllables, as if you grew up in Berlin. Now, granted, Maschine’s own promotional videos — outsourced to the US — anglicize this to “machine” / “muh SHEEN”, but the engineers and product folks who built the thing use the German pronunciation and think you should, too. And, anyway, it sounds cooler, just as I have to admit a currywurst is tastier than a Nathan’s dog.

I’m sure this is only a small selection of potential mispronunciations. Other candidates? We’ll have to release a full pronunciation guide soon.

The beauty of using touch for controllers is flexibility. Sure, you give up tactile feedback – but you can also quickly make your own layouts, make touch controllers an ideal complement to your existing hardware gear (the stuff with physical knobs and faders and pads).

For that reason, we’re all eagerly anticipating an upcoming version of the awesome OSC-based iPhone/iPod touch controller, TouchOSC.

http://hexler.net/software/touchosc

The included layouts are already fantastic, with rotaries and virtual buttons and multi-faders and toggles and X/Y pads. But custom control would be even better. Creator hexler writes CDM with the latest:

The long-awaited update to TouchOSC that will allow for custom layouts has just been submitted for review to Apple,
so I hope that as soon as next week it will be available as a free update to all users on the App Store.

Together with this release (1.3) there will be a free editor application to visually design and upload layouts to the device. You can take a look at the last beta version I published if you want, there’s both Windows and OS X versions available, but I will also prepare a Linux version as soon as possible, of course without the new version of TouchOSC this is but a preview of things to come:

http://dev.hexler.net/touchosc/touchosc-editor-0.7-osx.zip
http://dev.hexler.net/touchosc/touchosc-editor-0.7-win32.zip
http://dev.hexler.net/touchosc/touchosc-default-layouts.zip

And nicely enough, the editor is built in cross-platform Java, which I think makes a whole lot of sense. (Go Java, Python, etc., rather than getting stuck in hard-to-port platform-specific stuff like Cocoa.)

Thanks, hexler! I don’t have a video of the new features yet, so instead here’s a nice novelty – the beginnings of a creation using the free SuperCollider (which runs OSC natively) in combination with TouchOSC to make a custom step sequencer. Should fuel other ideas, too:

Fritzcrate Project / lusidLearn Early Demo from Michael Schieben on Vimeo.

Knobs and faders can be rigid. Fancy multitouch devices can be expensive. But for the cost of a webcam and some spare materials, you can build computer interfaces with objects around the house, thanks to the power of open source software.

In just one day, a group of artists in the CDM community, from Austria and Germany to New York to Australia, got quite a lot working with tangible interfaces. At top, Michael Schieben and Christophe Stoll experimented with using soda bottles to control software like Future Audio Workshop’s lovely Circle. (Ableton Live works, too – as does any MIDI software.) As Precious Forever, these guys are responsible for some of the best UIs in music software, from FAW to recent Native Instruments designs, so it’s lovely to see them experimenting with this idea.

As you add more people to the mix, you get ideas you might otherwise never have imagined, from a game involving blocks of the Tokyo skyline to an interface built into floor toms.

We also got a lot of real-world data on what works, what needs work, and what causes trouble for beginners, which we’ll be documenting. (Adam and Martin from the Trackmate and reacTIVision projects, respectively, were both tuned in to see progress and provided lots of help – and are also collecting that data to improve their own documentation and libraries.) More commentary on all these side benefits, as well as a discussion with visitors from Argentina on the scene around the world, at Create Digital Motion.

Musical Resources

We also got some really helpful tips for working with the free, powerful, tri-platform synthesis tool SuperCollider:
Charles Martin wrote up an easy SC test script for receiving Trackmate messages (and also had the clever idea of using a floor tom)

And for connecting Trackmate to MIDI and working with Processing, lots of tips are available on Michael Schieben’s noisepages blog:
http://fritzcrate.noisepages.com/

Get Involved

More documentation:
Tangible Interface Hackday: The Projects (So Far)
http://hackday.noisepages.com/

http://trackmate.sourceforge.net/
http://reactivision.sourceforge.net/

So, what’s next? You can join discussion and brainstorming for how to proceed, and how to get in on another hackday (formal or ongoing), even if you missed the first. Stop by the Tangible and Multi-Touch Interface group on noisepages:
Tangible + Multi-Touch noisepages Group

Our noisepages community is still in “alpha” state, but it’s usable – we’ve just fixed avatar uploading, which was the biggest problem. We’ll have more features, functionality, and improvements down the line, as well as more extensive documentation for how to get started. But if you’re a bleeding edge sort of person, join up free and give us some advice on what you’d like out of it.

I look forward to more work on these projects. Stay tuned for more, including some additional documentation (I’m developing some stuff around my own project).