Engineering a production instrument is a kind of study in compromise. For mass-produced musical instruments, it’s a fusion of practicality and economics, made affordable by a mass-market supply chain.
What makes the monome creations special isn’t just that they look beautiful; the art isn’t aesthetic only. They are uncommonly uncompromising. They’re designed in such a way that tells a story about materials, one that weaves connections between suppliers – many of them local suppliers – and focuses the experience of the device on the interface. They have the kind of obsessive attention to detail associated with the finest acoustic musical instruments, but they demonstrate digital design can be similarly exacting.
They don’t just add more. Some controllers are expensive just because they have a ridiculous number of knobs and switches, for instance; these are passionately minimal. But they reach a level of total commitment in design.
The beauty you’ll see, but understanding why it’s musically important to have this interface or just why these devices are costly can take more investigation. So, here, we get to look closer behind the scenes with the designer.
The second-generation arc, a controller built around lit encoders encased in glass, metal, and wood, reaches a whole new level of uncompromising design. It might, you could argue, be too much. These are just a set of round encoders, no more; even a previous button-press mechanism is gone, so you instead have either two or four continuous controllers with light feedback. The edition was limited to 50, and sold out as I was preparing this article. But, on the other hand, think about the simplicity of the mechanism of a piano key. It’s “just” a lever. Execution makes it into the instrument we know and love.
And here, execution cuts absolutely no corners. From monome’s self-described specifications – the latest episode in the arc saga we first covered with Brian at the beginning of 2011:
higher resolution: 1024 ticks per revolution. incredibly precise gestural capturing.
custom engineered shaft and bushing, produced by an american scientific instrumentation company. very tight tolerances. no wobble, perfect smoothness.
etched steel light shaper. acid-etched glass. sixty four crisp variable-brightness LEDs per encoder.
low profile walnut enclosure, exposed aluminum sides matching the 2012 edition grids. recessed rubber feet.
there is one change that’s important to note however—encoders no longer support a keypress. this was a long-discussed design compromise and while we appreciate the capabilities of the original edition, we’re very excited for this new incarnation. further discussion on the forum.
Pricing ran (past tense, since they’ve sold out) at $500-800 depending on number of encoders, with additional costs for shipping.
A nice window into what it means to have local suppliers and collaborate with someone like a glass cutter is this message from Brian Crabtree, posted to the monome forums. In this case, their unique supply chain both creates – and simultaneously solves – the problem.
The walnut enclosures are nearly done being finished, they look wonderful.
the fancy bushings and encoder shafts are here in bulk and feel better than we ever hoped.
somehow our circuit assembler mixed up a reel of orange LEDs from 2011 with our 2012 yellow variety. luckily only a dozen or so (i think) are the wrong color. we do order overage and hope these won’t interfere with the last few orders. will have a full inventory soon once i flash firmwares onto 300 boards.
our glass cutter (yes, real glass, water cut) switched suppliers from sandblasted to acid-etched glass. these just arrived and the thickness of the glass is not to specification, hence won’t fit our assembly. the good news is that our supplier took back the parts immediately and is re-grinding them to thickness. hopefully they’ll be back here soon, as it’s holding up production. but the fact that the parts will be turned around quickly after showing up wrong is one of the big advantages of using a local supplier.
as usual our machine shop is behind schedule, but we expect to see shipments arriving within a week.
this is all to say that we regret we’ll miss our oct 12 goal to begin shipping. i’ll post updates here and i very much appreciate your patience and understanding.
in other news i’ve just about completed a big summer project– building out a proper workshop in the barn where all of monome will be moved completely. it’s fully insulated though it’s about to be winter-tested. this edition of the arc may be the first monome edition in six years that hasn’t taken over our dining table at some point.
Tomorrow, November 1, was the expected ship date, though I imagine that will be slightly delayed by Tropical Storm Sandy. As those units start arriving in the hands of arc artists, I wanted to step back and talk to monome’s Brian Crabtree about what makes this creation special. And there’s nowhere better to start than asking about just why people need this sort of encoder expression, musically speaking, in the first place.
CDM: What are some of the works that for you were most compelling on the first arc, in terms of applications?
Rodrigo Constanzo’s Party Van:
Rodrigo’s approach is precisely the approach I imagined using the device myself. The grid allows fast-access manipulation and exploration, the arc for fine-tuning. The arc’s ability to show clear visual feedback follows the same decoupled input/output paradigm introduced with the original monome grid controllers, but with continuous control rather than discrete events.
Matthew Davidson’s Electric Dharma Wheels:
Stretta is one of the few people to share a truly successful arc-only software instrument. It’s a joy to use and sounds outstanding. The high resolution of the arc is particularly well-suited for manipulation of the FM synth he’s created.
I often have to remind myself that there are only 100 units of each size arc (two and four) out in the world. The uses for the device are subtle, and I expect more surprises to emerge with time.
Can you describe the engineering goals of arc two? What was the experience like designing this stuff yourself from scratch? It clearly goes well beyond what a lot of us (my own projects included) do, in that we tend to work more with off-the-shelf components.
The primary component with the arc is a very high-quality encoder; the feel of the device is very important given its hyper-minimalism. We felt we could improve on the original by not using an OEM component and, as a result, began delving into unfamiliar engineering territory.
An optical encoder has no electrical contacts– it’s a code wheel attached to a rotating shaft which is read by a reflected LED. There’s no noise, even at incredible resolutions. We sourced higher-resolution discs and designed a circuit board with some strict mechanical parameters.
We didn’t want any play in the knob, which meant we had to design a shaft and bushing pair with much better tolerances than those typical of machine shops — we ended up using a precision scientific instrumentation company in New Jersey. After a few more technical discoveries, we’re very satisfied with the results.
We’re again using cut glass. We discovered another company which acid-etches sheet steel, which we used for shaping the LED rings. The walnut is still from Pennsylvania, and the overall design matches our recent edition of grids.
The entire process turned out not to be so financially reasonable. I don’t expect to make a lot of these devices (we’re made just 50 of each this time around), but I feel a very strong commitment to making the best work we can manage.
I’ve spent some time talking to [serialosc engineer] William Light about this – can you share a bit of what you’ve done making OSC [OpenSoundControl] find and work with multiple devices?
Our main progress over the last years has been dealing with OSC discovery. [Ed.: this is the process of how to find devices communicating over OSC automatically, rather than having to key in IP addresses manually and the like. It's important that it work with multiple devices, as someone might use a monome and an arc, or a couple of monomes.]
Initially we found a lot of promise in [zero-configuration / auto-discovery protocol] zeroconf/[Apple] Bonjour given it’s built-in to Mac and Linux. Windows gave us a lot of trouble: it works, but any number of setups can interfere with its operation, and tracking down these tiny problems can be tricky. The other major issue is that most audio-visual environments just barely adopted OSC; zeroconf is probably asking too much. we adapted a Max/MSP external that works well, but that’s the only option outside traditional programming languages like C or Python. Furthermore, zeroconf has no official support in the OSC spec and developer community.
A way around this was to have serialosc (our device-OSC router) spawn its own information server, a port where messages can be exchanged to query the current setup. It works in place of zeroconf (though zeroconf is still built in), where an application can subscribe to future updates in device configuration changes, for example.
I see this as a first experiment in friendlier auto-routing of OSC data. Even for non-device-centric OSC data, it’s an interesting model for parameter auto-discovery and cross-application awareness. Of course, we haven’t created a standard, so there’s not something to directly hook into, but the ideas are there to explore. We’re excited to see where it goes from here.
So, anticipating the question of people impressed by arc, when might we see another edition?
As with all of our editions, we determine demand as we go. If enough people are seeking these devices, we’ll certainly make more.