The grid is in. While the monome remains the standards bearer for hardware with grids of buttons on it, arrays of buttons are suddenly everywhere, in the commercial Akai APC40 and Novation Launchpad, and, from Livid Instruments, the Ohm64 and now the Block. I think it’s a real compliment to the monome’s creators – and the community that has authored ingenious open software for the monome – that there is this excitement around the design.

The latest entry is Livid’s Block, a compact, aluminum-and-wood controller that’s easy to carry and which weighs less than 3 pounds. It’s not a monome – it eschews the monome’s stringent minimalist design aesthetic and adds knobs on top, faders on the side. That layout has made the M-Audio Trigger Finger a blockbuster hit, so I think it could attract people who want more than just buttons. (That’s why choice is generally a good thing.) But just as importantly, the Block takes cues from the monome beyond the skin-deep. As with the Ohm64, Livid is working to open-source both the guts of the hardware and the software on the computer. The instruments are made by hand using sustainable materials and finishes, manufactured in Texas in their own shop rather than the lowest bidder overseas. The hardware itself encourages hacks and customization. These are principles championed by the monome’s Brian Crabtree and Kelli Cain, and they’re badly in need of some company. Livid, like those monome creators, is a handful of individuals rather then a big company, but they give us new hardware that embodies sustainability, openness, and local production – and that makes the monome and its principles stronger. (Livid has been crafting performance hardware and Max patches for many years.) And while this bus-powered USB MIDI device doesn’t yet support (OSC) OpenSoundControl, that could come – without sacrificing conventional MIDI connections to outboard gear when you don’t have the computer connected. (Clarification: as with the Ohm64, OSC support is not yet available but should be possible. Stay tuned.)


Basic specs:

  • 8×8 backlit keypad with corresponding knobs, function buttons, and faders
  • Square layout that can be used at any rotation (so the USB port lies where you want it)
  • Runs a suite of apps built in Max/MSP from Livid – including a sampler, synth, sequencer
  • blockEditor for customizing layouts, lights
  • US$399, available November 1

I’m interested in more open software, so I’m working on making an editor in Java and would love to hear what else people might want. (SuperCollider looper? Pd algorithmic grid controller? Processing library?) These I hope to make work both with the Livid hardware’s added faders and knobs, and the monome’s more minimal design. Of course, OSC will be terrific for computer applications if that comes to pass, but I love the idea of gear that can also talk to MIDI hardware.

I really like Novation’s Launchpad, but for a little more money, you get a beautiful case, additional controls, and added flexibility, all in gear handcrafted by the maker and with an open approach to hardware and software. Without getting into a debate over the merits one way or another, consider this: you can choose. We didn’t use to have these kinds of choices in music hardware. The fact that we do now – not only the ability to choose the nameplate, but the very philosophy behind the device’s manufacture – I think can benefit everyone, users and manufacturers alike. It opens up the entire music tech industry to new ideas and new variety.

  • Kfrm

    Nice, but why not make the grid multi color? That's what I've been missing on both Monome and Livids stuff ..

  • Michael Coelho

    I was just pouring over the Livid web site last night and didn't see this. I want to get a grid controller ASAP to use with Live and was leaning towards the Launch Pad. This announcement makes it just that much harder to decide.

  • Mudo

    For me it is nice. I prefer it instead launchpad…

    but is true: Monome needs rgb upgrading…

  • rootbooter

    just saw one before Moldover and elijah B torne show on Saturday in brokelyn. cool looking and the software control panel loks really tite too. i think for the quality build and builders its def worth the extra scrilla.

  • @Kfrm RGB LEDs are substantially more expensive than solid color LEDs. The price of the unit would go up too much I would imagine.

  • tekcor

    it seems that everybody whants to get a piece of the big grid-apple.

    i deffinately will wait for an grid with the possibility to have all 4096 colors with those rgb leds mudo and kfrm allready mentioned.

  • mpf

    still looks a bit like a prototype to me. block is a good name for it… blocky for sure.

    no one can touch the beautiful minimalism of the monome. perfectly finished enclosures with no visible screws or branding. (unless you flip it over.. even then it is extremely minimal)

  • Eric Klein

    <cite>really like Novation’s Launchpad, but for a little more money, you get a beautiful case…</cite>

    A little more money? Try double the price…

  • Eric Klein

    @George P. Macklin – Multicolor doesn't have to be RGB. Maybe just the tri-color buttons of the APC40 would do the trick…

  • deamras

    I would prefer it to Launchpad if the colors were not so gay.

  • Redoom

    I am soooooooooooooooooooo tired of all these alt grid haters lickin' Crabtrees' sac.

    The Power of choice RULES!!!!!!!!!!!

  • less featuritis than a Novation Launchpad, not as minimal as a Monome at a price point in between the two, it will be interesting to see who this is for? I like the Ohm64 better than this, and I like the Monome line better as well, and the Launchpad price makes it a good deal for this kind of controller. Glad to see more options anyhow.

  • That Guy

    Looks kool.

    gettin' tired of the forced monome references in these articles though.

    Give it a rest, a matrix is a matrix is a matrix is a matrix.

  • The nice thing about the Launchpad is that it is bus powered and multi-led. This is something other devices have not been able to accomplish yet. BTW… I got to test out the Launchpad at AES and i was surprised to discover how durable it felt. It was definitely a solid plastic. I talked to the guys that designed the Launchpad and they said they wanted to make a video showing the launchpad run over by a car multiple times, because it really is very durable. That may be an exaggeration, but it definitely felt more durable than i expected. The combo of the Launchpad and the Nocturn seemed really powerful.

  • newmiracle

    Mike, the Ohm64 and the Block are USB powered.

    I just got my Ohm64 last friday. I love it, though I would've liked having the choice between the Ohm64 and the Block. That being said, I'd probably have still ordered the Ohm64.

    One thing that I have been raving about with the Ohm64 is the fact that it was really simple to set up with Live. It's a USB class compliant device. You plug it into your machine, open up Live, set MIDI in and out to "Ohm64", and you're ready to rock MIDI-Learn however you please. No fuss no muss.

    I was expecting the worst, tbh. So in terms of competing against the integration of the APC or the Launchpad, I feel like the Ohm64 does much better than people would assume. From the looks of it, the Block is the same.

    ALSO- one of the things that made me pull the trigger on the Ohm64 was the fact that the company has made a kind of 'wrapper' for Monome apps. I haven't tried them yet, but people seem to be pretty positive about them.

  • Esol Esek

    This is getting confusing. I cant buy all these guys just to test them out. Someone needs to open a midi controller library/store…

  • doc rob

    @Redoom – I'm quiet tired of unnecessary vulgarity and poor grammatical skills but I suppose those won't fade either.

    Hmm thinking of the appropriate analogy for the choice argument with this product. I'm soooooooo glad the Vanilla Ice gave me a choice how to listen to 'Under Pressure.'

    Argue that the grid isn't orginal etc… fine. However, when you look at this you cannot help but point back to the monome.

  • newmiracle

    Peter, here is one of my more 'lofty' ideas that I will probably never get around to actually doing. Here's what you can do and take all the credit:

    Make an editor that is flexable. So lets say you're looking at 64 buttons. Have people be able to section off real estate for different functions as they see fit. Highlight the buttons you want, and then be able to assign different kinds of functions. Example, highlight the bottom row and give it a 'track control' function (play, stop, pause, etc). The 7×8 grid above that could be split into half. The left half could be given the function of "step sequencer" and the right half could be a simple "sampler" function with gate/trigger/etc.

    Think of these functions as 'modules'. You could make multiple modules: sampler, sequencer, looper. Maybe get spicy and make a Game of Life module, a "gravity" or "bouncy ball" module.

    Then people could say: highlight the upper half of a 64 button grid. That could be a "Game of Life" module. Row 5,6,7 could be loopers, and row 8 could be control buttons.

    With continued development you could have fader and knob objects, and be able to build templates for popular controllers. With any luck perhaps you could build a layout in your editor that could incorperate multiple controllers and inputs.

    The final hurdle would be to make it so that you could switch layouts without any trouble within a live performance scenario.

    Most importantly, I think that there's a big opportunity for giving electronic musicians creative opportunities without making them program or troubleshoot. I have these many buttons: I want these to be samplers, these to be sequencers, and these to be controls… GO! I used to program alot of ActionScript, and even with a somewhat decent programming background- the last thing I want to do with my music is debug my instrument. I want to conceive of a system and be able to impliment it with the least fuss possible.

    Bonus points for something that has a NICE LOOKING UI. Or, I dunno- a customizable one.

    …I'd also like a unicorn, rainbows, and world peace. Oh, and icecream!

  • newmiracle,

    I realize there are bus powered devices. What I was illustrating was the fact that it used multicolored leds and bus powered. The Livid Instruments stuff looks nice too. I asked them to send me a device to demo for my site. We will see what happens. I should be getting some hardware from some other vendors shortly. I will definitely do some comparisons.

  • I'm waiting for Korg, they should do the next movement to the grid controller stuff, maybe a nanogrid?

  • That Guy

    doc rob,

    ya. and monome were the pioneers of making things by hand, sourcing locally, etc.


    Not dissing monome, I own one and use it all the time. But peter's been outdoing himself with the *forced* references lately. The tedious grid/matrix references are one thing, but livid can't even seem to be a small company that hand builds their products with locally sourced materials without – you guessed it – invoking another monome reference.

    Seriously, give it a rest or at least stop trying so hard.

  • at least i can see the colour of the clips on this thing.

  • wagon

    would i be able to use this with monome apps i use currently with my 8×8 arduinome? would be nice to replace it with this πŸ™‚

  • griotspeak


    that lofty idea actually sounds ioflow

  • DumaisAudio

    So the Ohm64 supports OSC, but the Block doesn't? Am I correct in reading that? If so, why would they limit it like that? That's the one thing the Launchpad is lacking that the Ohm64 has, why not put it in the Block as well?

  • @Eric Klein The tricolor LEDs would work very nicely indeed. πŸ™‚

  • Currently, neither the Ohm64 nor the Block supports OSC. However, they're based on an architecture that should be able to support OSC in the near future. Stay tuned; I'm in touch with Livid about this because I think OSC support is important. As I say in the story, I think the ideal for a hardware controller would be to plug into a computer and use OSC, then *unplug* the computer and use MIDI with external hardware. Ironically, the Launchpad and APC40 which are MIDI-only (and likely to stay that way, sadly, as proprietary mainstream gear) can't support external MIDI hardware.

    Yes, the Launchpad costs half as much – without any knobs or faders, without this customizable case, without open firmware and software, without an editor for assignments, without support for external MIDI gear. Now, I think for some people the Launchpad will *still* be the perfect choice for people. But this illustrates why you really need to look deeper than just how something looks superficially and the price tag.

    Oh, and you can stain this a different color if you don't like it.

    The Launchpad is indeed sturdy in my tests so far, though I wouldn't drive a car over it; I think they're being a wee bit over-optimistic. πŸ˜‰ It is worth saying, though, that plastic can be a very, very sturdy material. The issue is, environmentally the plastics used in music hardware are not so awesome. There are sustainable and recycled plastics and plastic-wood hybrids that look interesting, but I haven't seen anyone use them in an instrument.

  • Just to be clear – that's not to take away from hardware like the Launchpad, or Things Made of Plastic. But this illustrates why choice is important. The industry needs some of these bigger players just to get stuff into the channel and into people's hands, and for a lot of folks $200 may be their whole budget for a controller. On the other hand, $400 is something a lot of people can save up to buy, and I'd love to see us talk about things like environmental impact when considering what our gear is made out of. I'm typing this on a plastic computer, but I'm also interested in learning about – and investing in – something like a renewable wood with a non-toxic surface. These are the objects we touch to make our music; it's worth talking about them from all angles.

  • salamanderanagram

    let's be clear here

    the monome doesn't speak OSC either. it has a program that translates it's serial data into OSC data. one could just as easily write a program to translate data from the livid devices to OSC.

  • I saw this at the moldover show on saturday as well. really nice bit of kit. sturdy and really nice button response. faders and knobs feel super quality as well. definitely doesn't feel "plastic". There is a really nice editor which makes it really easy to set up and use ( maxmsp source included as well ). I believe there is also a monome template for it, so you can use any of the monome apps with it. Im most likely going to pick one of these up once they are available.

  • Mudo

    I said "it's time to become rgb" because it is done at octint for around 350 $ (enclousure included) and tricolor is not enough for some of us…

    I prefer customization as a freedom of choice over standaritzation as a "one way" thinking…

    and yes, it is a upgraded monome and Mr. Crabtree maybe doesn't invent grids but his invention (plus maxmsp) has become the reference which all of this gear are getting inspired (and trying to be compatible…)

    Just my2cents.

  • w.a.


    Well said…

    the monome doesn't 'natively' speak OSC either!

    but imho, even if USB it's a ('universal') serial protocol, I wouldn't say that you could write a program to translate data from livid devices 'just as easily'…

    If you know how to translate directly USB data into whatever you want you can 'just as easily' write a program to translate data from other devices like the APC40 and the launchpad. Those devices are USB compliant (at least the APC is)… don't know in detail what this implies, but it should be that they follow a certain communication protocol, than it should be possible for a 'USB programmer' to take the serial stream and translate it in whatever he wants…

    so, you may:

    – write a driver so that the APC40 is not seen as a MIDI/AUDIO device but as a HumanComputerInterface device… this will give you the possibility to use it with a 'hi' object in Max.

    – translate the serial data from an APC40, launchpad, or any other USB device into OSC as well…

    I would love to be able to do that…

    and I think is not that_hard/impossible either…

    but AFAIK when you program USB devices you'd better put your hands on a hardware 'USB_sniffer/debugger' if you want to do things right.

  • I like it – for me it seems like a good 'stop gap' between the APC and Launchpad (neither appeal to me, as I don't like the 'have tos' in terms of their use) and a Monome.

    If it really is as 'open' as it's made out to be, I think these are going to sell like hotcakes. My pre-order's going in…!

  • Cille

    My first impression is that the design seems a bit unresolved. I don't like the fact that the 8 knobs don't line up with the 8×8 grid; it doesn't make any sense to me visually and from a practical user point of view.

  • Pingback: Another new Ableton Live controller: Livid Block «

  • Oh, Livid … you can turn this out but I still can't buy a MIDIDIY … first it was infinitely "coming soon", now it's "out of stock".

    Possibly because it is the guts of one of these?

    I still wish someone would make a really modular midi controller, with components you can snap together like legos. Making your own matrix controller would be simple … just snap a bunch of buttons together … however many buttons or pads, or knobs you have … it'll never be enough anyhow πŸ™‚

  • AO

    A few questions that all this new controller news has raised . . .

    Does one pick a controller and arrange their set around the "limits" of a particular controller, or pick the right combo of controllers to control an existing set? Looking at it another way, do you chose a controller and build a set around it, or do you chose/combine controllers based on the set you want/prefer in software? Curious about other people's thoughts.

    Also, anyone have a good solution for navigating between banks of clips with controllers that aren't "integrated" w/ Live such as the Launchpad, ie, a way to mimic the red box behaviour w/ controllers like the Block?

  • salamanderanagram

    @wa – "I wouldn’t say that you could write a program to translate data from livid devices ‘just as easily’…"

    i'm not sure as to the whole of your comments, but what i meant to say was the midi coming out the livid devices could be translated to OSC just as easily as the serial coming out of the monome.

    i have already done this with a kaoss pad, and i've also made a serial device of my own that 'talks osc', and while listening to the midi data is different than the straight serial data, it's a relatively minor programming task to translate either into the monome protocol.

    to pretend that the monome is somehow superior because it 'speaks osc' is really, really really missing the point. ANYTHING can speak osc the way a monome does, IE if you are willing to translate the actual output of the device, and have an extra program always running…

    in fact, is there an actual piece of hardware that natively understands OSC? i don't know of any.

  • The only piece of hardware that i have, that actually speaks OSC natively is the Lemur. I do not have to initiate any other progam to talk to a software program that supports OSC.

  • When I was talking to the developer of the Launchpad, we discussed OSC. When it really comes down to it, why does it matter on a button grid that is going to give you a value of 1 or 0. I can understand faders that would need values greater than 127. But, for buttons, as long as you can get unique values from the buttons and their state, it doesn't really matter what you get from the device.

  • salamanderanagram

    micheal – i agree, i've always thought it odd the way that people talk up OSC and the monome, when i can't for the life of me understand what makes it superior to midi *in the context of monome*. you're only really sending very simple messages anyway.

    as for the lemur and osc, i know nothing about it, but are you sure there's not a driver on your computer doing that work?

  • Technically speaking, just because OSC is transmitted over a different transport doesn't make it any less "native" – serial included. Serial support gets more involved on monome because of challenges supporting serial over USB, *not* OSC over serial. πŸ˜‰

    Reasons you might choose OSC over MIDI, even for a grid of buttons:

    * time stamps

    * true transport independence

    * the lack of an arbitrary baud rate

    * (not true on the monome, unfortunately, because it operates as a serial device) independence from archaic driver support

    * human-readable message format, which can be parsed hierarchically … instead of having arbitrary numbers

    The Launchpad is a well-designed device, but that shows a misunderstanding of what OSC *is*… and it still doesn't explain why Novation doesn't provide class compliance, which would allow their hardware to work without drivers. (That does require non-trivial firmware support, but it's still worth pointing out.)

    When you add faders and additional controls, OSC becomes even more useful.

    Anyway, I think that a lot of people *aren't* aware of these reasons, because they haven't been articulated clearly and broadly.

  • Also, any computer can natively "speak" OSC. Now that computers can include mobile devices and touch devices that are themselves controllers, and because cheap, embedded "computers" can get built into anything you like, that's a big, big deal.

  • salamanderanagram

    "Technically speaking, just because OSC is transmitted over a different transport doesn’t make it any less “native” – serial included. Serial support gets more involved on monome because of challenges supporting serial over USB, *not* OSC over serial. ;)"

    maybe it's an argument of how to phrase something. in my mind "native" osc would mean you could plug it into a computer and it would send the computer osc messages without the need of a glue program.

    an example of "native" protocol use is the way i can plug my keyboard into my mopho and they automatically understand each other. i have yet to see osc devices that work this way.

    i have yet to personally see a device that natively supports osc.

    and the only thing i see the monome actually using in the osc protocol that is different than midi is that it is more readable. it is absolutely trivial to emulate the monome using midi.

  • The Lemur does not require any software to transmit or receive OSC. That functionality is part of the firmware and is actually it's native protocol. Realize that the Lemur gets connected by network cable, not USB. There is a JazzDaemon, but that is just to convert from OSC to midi and for Keyboard and mouse control.

  • salamanderanagram


    just for the record, i do hope OSC becomes more of a standard, but right now i'd honestly rather have a piece of gear spit out something that i can use with pretty much anything.

  • Another thing to consider it what is really talking native OSC? Just because firmware has OSC control is that really Native? If i have a serially connected device and then the drivers talk OSC is that Native? Does it really matter, or do we just really care that we have a low latency device that we can, "do something" with that is useful to us. I think we can all go a little crazy thinking about this. To me, I just want something that is low latency, has the functionality i need and is sturdy. Now, there is an argument to be made for standardization for communication, interfacing, and other parameters. That hasn't really happened in the music scene since the 1980's with a little known protocol called MIDI.

  • salamanderanagram

    i consider it native if i can plug an osc keyboard into an osc synth and have them automatically be able to talk with no computer in between.

  • @salamanderanagram

    I like that definition. In order for things to be native and inter-compatible, there would have to be a common interfacing spec and a common communications specification that is agreed upon by all vendors.

  • @salamanderanagram: what do you imagine the two ends of the communications link will be saying to each other? i hate to sound like a broken record, but the fundamental problem with OSC at this point in time is that even though the syntax of the messages is reasonably well-defined, there is no agreement on the semantics. put differently, there is no way for any OSC transmitter to send a message to an OSC-receiving sound generator that will reliably cause the generator play middle C. no standard/generic way to do this, and that is what is important.

  • @Paul / @salamanderanagram / @Michael:

    Well, here we're having a conversation among extremely well-educated folks, and still there are a lot of myths being repeated. So, the real problem is that OSC needs better communication between the protocol and other human being before we get into implementation on devices. πŸ™‚ I think that's possible, so this will absolutely be something I follow up.

    Okay, first off — as I've said many times before, the idea is not to replace MIDI. In fact, I think MIDI itself has some fundamental flaws. We've simply become so used to them that we take them for granted. Let's take Paul's and Michael's examples.

    MIDI itself lacks a standard means to refer to pitch – period. There's absolutely no guarantee, none whatsoever, that sending note event 60 to another MIDI device will get you *sound*, let alone middle C. To the extent that MIDI can do this, it's easy enough to send MIDI over OSC.

    So, in fact, what we're really saying here is not that OSC is deficient, it's that no one *anywhere* has come up with a standard way of referring to something as simple as pitch.

    Okay, granted, that may be a little harsh. In a variety of circumstances, you can in fact send a MIDI note event and get a note that's what you expect. (Not under all circumstances, but… well, some.) Then you get beyond MIDI note events.

    Control Changes are a failure. They don't do anything predictable, ever. But more interesting to me is why they failed, which is that different devices *don't do the same thing*. So, Paul is correct, except that you can replace the word "MIDI" for "OSC" and "control message" for "note message" (having said that even using notes as an example is extremely charitable), and the same is true.

    Now, that said, a lot of what's being said about OSC here simply isn't true. OSC does standardize on communication and interfacing. It's not a serial protocol, but that's an advantage. The standard OSC message can add a lot of overhead, but it's possible – as the monome does, and as the microcontroller OSC implementation that's emerging does – to translate OSC messages to optimized serial communication and still have advantages relative to MIDI.

    OSC hardware does not require a software layer in order to work with other software. That's simply a myth. Of course, the real problem is that there isn't much OSC hardware period, but that's something that could change soon. What there is a whole lot of is OSC-compatible software. This site is Create *Digital* Music as readers are so fond of reminding me, so it's worth noting that "software" can – and should – mean embedded hardware and microcontrollers to.

    Look, OSC isn't a perfect protocol, or a finished one. But let's face it; MIDI for musical applications on hardware and software hasn't significantly changed for decades. OSC *can* change, because it isn't gummed up in a manufacturing group, it's a truly open protocol to which anyone may contribute. You can actually develop semantics, which is something you can't do with MIDI because of the nature of the protocol and how it's standardized.

    In fact, a standardized networked protocol such as OSC is the best opportunity we have to actually think musically about hardware can communicate in networked environments and not only serial connections, how it can begin to treat pitch in a sophisticated way, and how devices can interoperate more dynamically. I have to disagree with Paul that this must be a rigid standard; I think the ideal objective would be to have devices communicate dynamically more easily.

  • salamanderanagram

    "OSC hardware does not require a software layer in order to work with other software. That’s simply a myth."

    i was only saying that

    1) the monome specifically requires software, as it does not output or receive OSC messages on it's own


    2) i don't know of any OSC hardware. the lemur has now been cited, do you know of any others? i think colin at experimentalists anonymous was working on something called the open open sound control controller but i never saw if it was finished.

    3) even if if there WERE OSC hardware, i have no idea how they would interact with each other, so at the moment, while it seems interesting, it's certainly not poised to topple midi.

    while you can poke fun at how every midi device may not play a middle C when you tell it to, you can't deny that there are a staggering number of synths out there that will, that can be plugged into a staggering number of keyboards.

    as you say, there's no accepted way to do that in OSC, so the idea of buying an OSC synth seems a little odd UNLESS it has MIDI too. if i can't plug it into my keyboard or send it data from ableton what good is it? an OSC keyboard would be equally pointless until some sort of standard is agreed upon.

    and i'll wrap up by saying, if we are going to start agreeing on OSC standards, the monome protocol should be the first! it already works on the livid ohm, apc40, korg padKontrol and kp3, now we've got the block and launchpad coming too.

  • @salamanderanagram: Nope, correct, agree.

    1. That's correct, though that's more to do with the way the monome's own serial protocol is designed. I believe with micro-OSC, it could be possible to have a similarly-optimized serial protocol that was integrated with software on the other side. And yeah, I think we're in agreement that not needing an extra app to run is a good thing. πŸ™‚

    2. Well, there isn't OSC gear the way there's MIDI gear, but I think it's better to think about the fact that a lot of gear nowadays is built atop standard computing, mobile computing, and embedded platforms. Right now, it's possible to implement OSC on all of those standard platforms. But yes, in terms of things immediately available to consumers, think iPhone/iPod, etc.

    3. Not sure what you mean. Multiple pieces of OSC gear could interact in all the ways MIDI interacts. It could – and should – also work better, with less configuration, at higher resolutions, and in situations in which time stamping matters. If two people switch on laptops, they can instantly see each other and exchange IMs locally via Bonjour (zeroconf). There's no reason you shouldn't just as easily exchange musical ideas and live performances.

    Yes, you can plug a staggering number of synths into one another. However, you're still somewhat limited in what you can do without some prior configuration. As for note values, if you're happy with MIDI notes, you can do that *over OSC*. If you're not happy with MIDI notes, then now is the perfect time to come up with something better.

    Anyway, I think we're in agreement here.

    Incidentally, one brilliant example of how standardization can work is TUIO, the multitouch protocol. First implemented for ReacTable, it now works with a wide variety of modular software and unique multitouch hardware, including readily-available touchscreen displays, the iPhone, and others. It's a perfect example of spontaneous semantic standardization, which can happen as easily as getting a few people trying to do the same thing. By contrast, the same problems in MIDI have tended to devolve into proprietary messaging formats awkwardly wrapped into MIDI's somewhat arbitrary message schema.

  • I should add, on the topic of "replacing MIDI" — there really isn't any need. Compatibility with MIDI is a good thing. There's no reason hardware can't support both, which is the hope with the Livid above.

    Ironically, these days we're seeing hardware (APC40, Launchpad) that doesn't have MIDI I/O ports for communicating with hardware or configuration editors and templates so you can easily switch hardware and software tools. Contrast the Livid, which has both those things yet still can be useful in Ableton Live. Add OSC *without* subtracting those things, which would be the idea, and you have maximum versatility.

    There's no reason to use OSC where MIDI would do the job; the whole idea is to use OSC in the cases where MIDI either can't do something or can't do something gracefully.

  • salamanderanagram

    "3. Not sure what you mean. Multiple pieces of OSC gear could interact in all the ways MIDI interacts. It could – and should – also work better, with less configuration, at higher resolutions, and in situations in which time stamping matters."

    we are mainly in agreement i think, but the problem is there is no accepted method of doing these things. so while OSC "could" do all the things midi can and better, until there's an accepted, standardized way of doing across different types of gear (the way note on/off messages work in midi, for example) it seems kind of pointless.

  • salamanderanagram

    good point about iphones, forgot about that!

  • Ah, yes, but I think that's wherein lies the direction for OSC and digital music devices in general.

    A set of ways by which multiple devices can connect with each other, ad-hoc, in various combinations and communicate peer-to-peer and client-to-server using structured, semantic data….


    Yep. That'll be The Internet. πŸ™‚

    So, in fact, a lot of the answers lie on the Web. For instance: want various OSC-supporting devices to connect to one another without configuration? The answer is zeroconf aka Bonjour. And it's possible to implement this right now, as various iPhone OSC apps do. (I'm working on one for Android, along with a client app that does the same.) The semantics of how to structure data via technology like XPath is similar.

    This will all sound like a whole bunch of buzzwords to people who haven't encountered this tech, but you can look at it this way: rather than reinvent the wheel, you can go look to see if someone will give you gold 40" rims for free. πŸ˜‰

  • salamanderanagram

    @paul i know it! i see this as a huge flaw in OSC, one that must be addressed for larger implementation. what’s the point of having OSC “Replace MIDI” as i hear so many people on this site saying, if no OSC gear works with any other gear? seems pointless.

  • Peter, i think you're right on the big picture but oh so wrong on the details. Can you give me a single example of any OSC message that will be understood by any arbitrary OSC receiver?

    OSC is a way to connect a control system to a controlled system, but the way it has evolved, the control system has to know a LOT about the controlled system.

    By contrast, MIDI has lots of flaws, but the sender of a MIDI CC message (or even MMC for that matter) doesn't need to know anything at all about the receiver.

    This is a huge and fundamental difference. Until and unless the OSC "community" gets together and defines a set of standardized messages that cover at least roughly the same ground as what MIDI CC/NRPN/MMC covers, I fear that it will continue to be useful only for "dedicated" communication. Its not that this is a useless thing, its just not as useful as OSC could potentially be.

  • Paul, I just gave the best example — TUIO. There are a ton of TUIO apps that will respond to an arbitrary multitouch input in a way that makes sense. Not only that, but they cover a ground that's a lot broader than, say, responding to MIDI notes 0-127.

    That said, of course, there is a lot of work to be done to make OSC more useful. But I don't think that the solution will necessarily look like MIDI. For instance, rather than transmitting "60" and hoping that comes back as a middle C, you might query an instrument first to figure out its polyphony, tuning system, and scale, then map, say, an array of velocity-sensitive pads accordingly. Now, you're right – that would require an agreed-upon spec to do it.

    But here's the thing: rather than wait for someone else to do it, people should just go and try stuff and document the results. Rather than relying on some massive, slow-moving standards board, this is really about doing it. So, for instance, if there's a way that hardware should be talking to Ardour via OSC, you can just say so. Ardour ought to make a pretty good model, as it represents a traditional approach to what a DAW is and does.

  • Also, one other note – receivers shouldn't have to know about the sender. Right now, I think the OSC implementations out there have been way, way too rigid, not a result of how OSC is structured but a lack of creative implementations. So, yes – we need more creative implementations.

    For instance, I can't for the life of me figure out why no one is using wildcards. You can use wildcards in OSC messages just like you can with file paths, so that you could have /somedevice/pad/13 that works the same way regardless of whether it's something like /monome/pad/13 or /insanophone/box2/pad/13.

    And this works right now. OSC has everything people need. The problem with OSC is that, as you suggest, a lot of people aren't using it. And that doesn't mean hardware device makers. You can go do this right now in, say, Pd.

  • rorschach

    Again, I don't want to troll but let me question the aesthecical value of all these knob-panels from Tenorion over monome to livids (and the obnoxious LIVE connection to it)

    If ou see someone on stage with a laptop bobbing his (or her) head over the screen, the artistical value is zero. Art is is on the projection screen and on the loudspeaker. If the artist uses sketchpads, mouse, buttons or iphones is of no artistical value to the audience. It is just the ego fun of the artist.

    So for me, gazillion lighted buttons is just a hype. Soon it will be replaced by gazillion iphones, gazillion iron knobs, gazillion wobegons.

    Where is the art of all these machines, wher is the output that is produced by this input pads?

    Musical Art is defined as function over time. If someone plays Cello, he (or she) needs to strike the right note at the right time on the strings and the neck. Given the complexity of a cello, this is an accepted art and valued skill.

    But hitting the right button at a specific timepoint to play a sample cue and unlit the button, is that art?

  • @roschach: that sounds a bit like what the cello player says under her breath about the piano player… πŸ˜‰

  • Peter: the wildcard stuff in your short example is all well and good. But I'm not wondering about the wildcard up front ("insanophone" vs. "monome"). I'm wondering about "pad". Why "pad"? Why "13"? Introduce more components to the OSC path and every added component just makes it harder and harder to agree on the message set. Notice also the way that "markets" work here. As Ardour's author, I end up defining the message set that Ardour responds to, since there isn't a standard message out there. So we have. But on the other hand, Lemur, Mrmr, TUIO and other control apps/devices have developers who want to define the message set that their systems send (at least by default). The reason that MIDI worked out in the first place was the senders AND the receivers got together and agreed on what they were going to do. As I understand it, Mrmr and TUIO have defined a trivial set of messages that map to a physical surface but once again have no actual semantics. What should a program do when it gets "/*/pad/13" and whose job is it to define the answer to that question?

    I agree with you that part of this just needs to be *done* by those of us on the edge of it. I do know that Native Instruments are interested in figuring out "what to do" with OSC in the broadest sense, and perhaps it would only take a couple of significant "biggish" apps or instruments agreeing on some core control message set to push things over the edge.

  • Paul – absolutely, I agree. I've been long overdue having a conversation with CNMAT about just these questions. But my point is, don't look to MIDI for the model. I think the lesson of MIDI is that even basic, clumsy (ahem) standardization can be useful, as can simple numeric values. I think OSC already learns some of those lessons. But as far as how to make the standardization work with a wider variety of messages, the Web really does offer some solutions.

  • Paul: My argument all along is that there needs to be a well defined and agreed upon spec that will work for multiple manufacturers. This spec should define a standardized communication syntax. Another thing to consider is the physical spec. Do we connect through Ethernet or USB? What protocol do we use for auto detection of devices? Peter had mentioned Bonjour. There are many ways to go, but they need to be agreed upon in order to have true interoperability between vendors. Peter is right in that it does not need to start with a standards committee. It can start with us, but we need to take action if we want others to follow. If enough people use something then manufacturers tend to follow.

    Just a side note… It struck me as I was walking through AES; How many companies are still selling the same old stuff and are really behind the times. I think a lot of companies need to look at the trends for musical equipment and see where things are going or they are going to wind up out of business.

  • Physical spec isn't necessary. That's not even the case with MIDI; while MIDI specifies the DIN connection, even MIDI is technically transport independent – it's run wirelessly, over Ethernet, over USB, etc. right now.

    Zeroconf is the answer to detection of other devices, because it's an existing standard. There is a little specification required beyond that.

    But I'd just get away from the idea of "manufacturers." There's no reason you have to sit around waiting for manufacturers to do something. (Well, for one thing, you may be waiting a … very … long … time.) You can give this stuff a try. So mostly what we need to do is get more people trying stuff out. I'm convinced the best solutions will come out of solving real-world problems and sharing them.

  • @michaelChenetz: i think that if its a given that OSC makes sense, then nothing about the communication protocol itself needs to be defined. what does need to happen, as a first step, is breaking down the problem space into more tractable parts. for example, transport control is entirely different from synthesis control. MMC provides some very useful lessons for transport control, and at the very least we could attempt to define a common set of messages that are equivalent to, say, MMC Level 2. this strikes me as relatively non-controversial. synthesis control gets bogged down in questions about representing pitch, legato, note lifetime management etc. etc. all of which have generally derailed efforts at anything like this in the past. but transport control, and perhaps later basic DAW controls like mute/solo/rec-enable/per-track-or-bus-gain-control seems much more tractable to me.

  • @Paul: I absolutely agree. Actually, I think that suggests the need for different groups. So, for instance, most people would have found the multitouch control stuff intractable. But people who do that all day, every day found it an easy problem to solve – hence, TUIO works very well. Likewise, I think the synthesis problems could be *fun* to solve if they were tackled creatively by sound designers rather than bureaucratically by change-adverse (defensibly so) manufacturers. So it sounds as though some efforts are needed to focus on specific problems.

    I think transport controls would be terrific to solve.

  • here's an interesting detail of transport control, from a very real world example.

    in JACK, we have sample accurate transport sync. one JACK client can request a locate, and all other clients that are paying attention to the transport info will locate too.

    but some clients can do this instantly (e.g. a drum machine with a timeline), whereas others may take a little while to get ready (e.g. a DAW with lots of tracks – it has to reload audio buffers with new material)

    since we don't want any clients to start to play audio before everyone is ready, JACK transport involves the concept of "slow clients" and "fast clients". if a client has declared itself "slow", JACK will poll the client for a short time (about 2 seconds typically) to see if it (and all other slow clients) are ready. only when they all are does JACK switch the transport state into "ready to roll" or "rolling".

    if you look at MMC, this concept is only weakly supported. when you look at rewire (to the extent that you can look at rewire), its not obvious at all.

    if one were to assume that this type of handling of different participants in a shared transport control system is the right way to do things, it gets pretty hairy to do with OSC. in fact anything that involves query-response behavior gets to be pretty hairy with OSC.

    so even if the message set could be easily defined by referring to, say, MMC, details of the mechanism might be a lot harder.

  • So Instead of talking… Let us all collaborate and come up with a solution.

  • Pingback: A new Monome challenger appears()