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

Automap on other devices – and an iPhone as a remote control for your Live set? Our friend Ben Rogerson at MusicRadar have caught up with the chaps at Novation at a London trade show to have a look at Automap for iPhone. This app hasn’t yet hit the App Store yet – Hispasonic and the Ableton Forums got the jump on the story last month. But it looks appealing.

It seems to auto-detect the computer to which it’s connecting – as it should, folks, look up Zeroconf. (implemented on iPhone as “Bonjour”) And you can learn in both directions – so you can interactively choose parameters on the iPhone and decide what you want to control. It also sends MIDI to Live for clip triggering, though you’ll notice that some features on the APC40, like clip status and the ability to move through blocks of clips, aren’t possible here. Because Automap wraps around VST and AU automation parameters, you also get high-resolution control of plug-in parameters.

This should also open up possibilities for other Automap-supported apps, not just Live; I’ll be able to test this once the app comes out. No official word on availability or pricing other than soon and cheap. Before people start complaining about the tiny iPhone screen — yes, absolutely. But there’s a nice blank spot on the Novation controllers on which you could put your iPhone or iPod touch. Think about it: you can add an intelligent multi-touchscreen to your existing hardware, use your conventional gear for physical control, but keep the Apple gadgetry as an additional remote (now fairly cheap with no contract for iPod touch). You can even wander around the room during sound check while still controlling your set.

Update: I should note, as I just got asked on Twitter, most Wi-Fi adapters allow you to create your own Wi-Fi network. So you don’t need Wi-Fi in a venue. You’d just create your own network on your PC or Mac laptop, and connect via that – the iPhone and iPod touch both support connecting to these networks. (Note that not all devices do: the Android-powered TMobile G1, for instance, has a chip that apparently doesn’t support them, and I have an 802.11b/g USB adapter that won’t create them. But mostly, this is an easy matter.)

Cool as this is, and elegant as the work Novation appears to have done, I can’t help but notice this is still something of a kludge. The iPhone communicates natively over TCP/IP with the computer. That’s what this app is using – but then it needs a Rosetta Stone and another set of software on the computer just to untangle the archaic protocols music software uses (plug-in automation, MIDI, and more oddness heaped atop of MIDI). There’s absolutely no reason that music software couldn’t be intelligent enough to support networking protocols so that all software and devices can easily communicate. That wouldn’t put Novation out of business, either – on the contrary, it would allow them to do their jobs and this very app could be more productive. Instead of MIDI CC numbers, imagine if you could refer to clips by scene and position number, or even by clip name. Imagine if the iPhone displayed clip parameters and changed when clips were launched. Imagine no more drivers or software to install: someone who bought Novation hardware with OSC support could bring it to a friend’s place and work on a session without that friend installing Automap software.

(singing) You may say I’m a dreamer, but … (sorry, cough) actually this is all possible right now.

I’m all for solutions that work, and Automap (and M-Audio’s HyperControl) both have great capabilities now. But OpenSoundControl is also something you can implement now (provided hosts like Live will support it), and we’ll be talking more about what it can do over the summer to make it more practical and less abstract.

So, you’ve been looking at that Akai APC40. And it’s appealing. It’s got lots of lights and a huge array of buttons for triggering samples or video or what have you, and plenty of knobs and faders.

Now the APC40 has some serious “indie” competition, though, in the form of Livid’s Ohm64. Let’s compare:

APC40:

• Proprietary connection to Ableton Live
• A proprietary handshake that ensures only a real APC is being used with Live
• Fixed MIDI assignments – no MIDI assignment editor
• MIDI only
• No MIDI out jacks, so you can’t use it with outboard gear
• No bus power
• 40 buttons
• Made in some factory somewhere we’ve never seen

Livid Ohm64:

• Open source editor, partially open source firmware, open source patches to connect to whatever you want
• Custom MIDI assignments, for use with whatever you want
• MIDI for now, but the chipset supports open source solutions for OpenSoundControl (OSC) in the near future – and even DMX (for lighting) is a possibility
• USB and standard MIDI jacks so you can sequence outboard gear
• Bus power
• 64 trigger buttons in a more logical 8×8 array
• “Made in the USA by humans” – with a beautifully-crafted body
• Free Cell DNA video software included

Both the APC and Ohm are class-compliant, so at least neither needs drivers to work over USB for MIDI on Mac, Windows, and Linux.

Sure, the APC is plug-and-play with Live. But just as lots of non-programmers use open source browsers like Firefox, the whole point is that the Ohm could wind up being more plug and play with more tools thanks to its more open approach.

Most important is the programmability of the Ohm64. You can make your own custom light interactions – or, if you’re not into that sort of programming, count on what may be a growing community of open source musicians and visualists doing it for you.

In fact, Livid is so committed to customization that in addition to the natural, blue, and red finishes, you can order it unfinished and stain or paint it whatever color you like.

The Ohm64 is also priced at just US$599, meaning it doesn’t cost much more than the APC40. And with future OSC support, hardware MIDI support, bus power so you don’t have to carry a dongle, fully programmable visual feedback and assignments, and open source editing software, the APC has some real explaining to do about what its long-term payoff may be.

The editor is currently built in Max/MSP with some interesting possibilities coming up in Max for Live, but I’m also interested in working on some editing and performance tools in fully open source environments. Stay tuned.

Now, mind, this isn’t a review – I’ll get my hands on the Ohm64 next week here in New York, and I’ve only had a brief encounter with the APC. But if I were a betting man, I have to say, the contest here isn’t looking like it’s in the APC’s favor.

Available now.

Livid Ohm64

http://www.lividindustry.com/culture/ blog with more videos

Updated: I should note, one issue is definitely that, in order to maintain bus power, there are some compromises. You don’t get quite as much interaction from the lights as you do on the Akai APC – I do like the APC’s lovely LED rings around its encoders. You can interactively dim the lights on the knobs on the Ohm, though, which would work nearly as well. More once I get my hands on the Ohm, and theoretically, I should have an APC for testing at some point, too, assuming I didn’t just make Akai angry. (Uh…. competition is good. Blogs are all about opinions. Don’t hurt me.)

By the way, if you aren’t convinced and think you can do better, Livid is also distributing the brains of this device – the MIDIDIY – so you can build your own creations. Other such solutions exist, but the MIDIDIY is distinguished in its ability to support a lot more contacts for doing this sort of more complex device.

http://www.lividinstruments.com/hardware_mididiy.php

Ed.: Plogue Bidule is an unusual animal: this affordable patching tool resists conventional ways of doing things, down to its hatred of the number “1.0.” But Plogue has an underground following inside the already-underground world of modular patching tools for creative music. I’ve invited Primus Luta, aka David Dobson, to give us insight into this tool – including a new release that will be big news to the people who rely on Plogue to make their productions and live performances tick. -PK

Today if you go over to the Plogue site you will see the announcement for the latest release of Plogue Bidule. In addition to a number of bug fixes, there are some amazing updates in this latest release. On the eye candy side of things, Bidule finally gets a waveform viewer module — the WaveViewer shown in the image above. There’s also a new Audio Buffer module for visualizing waveforms. These are great additions to the Bidule arsenal and also a good indication of more visual goodness to come.

In its ever-growing commitment to fully support OSC [OpenSoundControl], a new tool has been added for monitoring OSC communication. The OSC Monitor behaves like many third-party options, showing not only the OSC messages sent by and to Bidule, but also picking up any additional messages being transmitted, as well. Ed.: A general-purpose monitoring tool sounds like a great idea! A great resource when trying to get multiple OSC-enabled devices or pieces of software communicating with each other.

Perhaps the biggest update of all in this version is the introduction of Multi-Core Processing, supporting up to 8 Cores. Previous versions of Bidule only allowed for processing on two cores, but now the MP Assign command lets you not only utilize up to 8 cores, but also select which processors you’d like to use. As a bonus, there’s also a new DSP Adapter function which allows you to run a limited set of modules at a buffer size of 1 sample.

All an all, it is a very welcome update. As with all publicly-released versions, this one comes with a time-sensitive trial period, so that new users can explore Bidule over the next three months without purchase. Simply make your way to the Plogue site to download this version today. If you’re looking for encouragement, also starting today, I’ve launched the first tutorial in a series which will be utilizing instruments that I’ve developed in Bidule for the Heads Project as examples. The series will be starting from the most basic concepts and progressing toward the more complex over the next months. If you’ve ever wanted to get your feet wet in Bidule now would be the time.

Lastly, I had the extreme pleasure of having a conversation with Sebastien Beaulieu, co-founder and lead Bidule developer over at Plogue. He gave me some great insight into the origins of Bidule, the business and development model of Plogue, and some ideas of what we can expect in the future. You can read the full interview here on CDM.

Want to interact with your computer musically using physical objects and other fancy-schmancy, science-fiction-y interfaces? Don’t want to rely on Microsoft or wait until 2019? You’re in luck. It’s like Christmas for DIYers and interactive futurists.

Enter LusidOSC, a set of protocols, libraries, and useful code, and Trackmate, a clever and cheap-to-build system for tangible interfaces. Together, you’ve just got a bunch of tools to help you start playing with blocks — erm, experiencing new spatial interfaces.

• LusidOSC, the library maps “spatial input devices” – really, any tangible devices or sensors in the real world – to applications, like live music or live visuals. It uses the network-savvy OpenSoundControl protocol. The library is available now for Processing, with Java, Python, Flash, and C++ in the works.
• LusidOSC, the apps/code: a set of Processing utilities to get you started includes a basic example app, command launcher, playlist mixer, and a MIDI sequencer. You can build on these for your own Processing apps.
• Your own input device: Tags? Sensors? Markers? Regions? Fingertips? If it’s in physical space, you can map it via LusidOSC. Or, if you want a place to start, try:
• Trackmate: A project of MIT’s Tangible Media Group, Trackmate lets you affix tags to any objects you want and use them as an interface.

LusidOSC is just the protocol; it’s physical applications like Trackmate that get really interesting. In these economically-challenged times, Trackmate gives you tangible interfaces for next to nothing. All you need is a computer (Mac, Windows, or Linux), and a camera (even a webcam will do). Print out randomly-generated tags in the free and open source software, stick them on stuff you want to use, and go to town.

You can make your own Trackmate surfaces out of hardwood or plexiglass for as little as $40 in parts. There’s even a Processing-based simulator app so you can experiment without the physical objects. (Good for troubleshooting on the bus or plane, I imagine.)

Trackmate is just one project, though; LusidOSC promises to support other interface ideas, too.

LusidOSC at Sourceforge, the work of “many research institutions and companies.” (Which, I wonder?)
Trackmate at Sourceforge, a project of the MIT Media Lab Tangible Media Group

Alternatives: TUIO, the protocol used in the Bjork-endorsed Reactable project marches forward, as well. And as both projects are open source, there could be some cross-pollination. I hear a revised TUIO is coming, and in the meantime, LusidOSC acts as a gateway to TUIO.