Can minimalist controller design make even two knobs into a digital instrument? We’ll soon see. The arc, the new controller from monome designer Brian Crabtree, contains just two high-resolution encoders (known to us in everyday usage as “knobs”). It makes no sound; every minute rotation and a push-button action are telegraphed to a computer. Everything that would make it musically interesting, then, is up to the makers of interactive software on the computer. At their disposal are interactive, brightness-adjustable LED displays that ring those encoders.
At US$500 (or $800 for a four-knob model), the results aren’t cheap, challenging even loyal fans of the grid controller monome. What you get for your dollars, at least according to the creator, is materials and handmade construction. The case is made out of solid, sustainable walnut, the facing from aluminum. In grainy Internet video, it may look like there’s plastic around the rings; it’s not – it’s glass. The slip mat is felt, sourced from small farms. I almost hesitate to point these things out, as it might make it seem as though the arc is expensive for the sake of being expensive, and that wouldn’t be fair; ultimately, it’s the arc’s small-quantity, handmade, local construction that drives up the price, relatively speaking, in the iPhone world in which we live.
Anyway, whether you buy one or not, I think it’ll be the question of how software can rise to the challenge of the arc’s provocatively-minimal design that’s more interesting. Brian has shot a first video experiment with one demo, in which you can see those LEDs providing feedback with the software, showing the position of loop points. Even this video only scratches the surface: Brian hopes that this won’t just be a monome companion, but that some will find ways of using it on its own.
A recent post on the official monome site provides additional details:
- 256 steps per revolution, with integrated push button
- 64 leds per ring, each led independently has 16 levels of brightness
- arc two: 6” x 3.5” x 1.5”
- arc four: 10.5×3.5” x 1.5”
- Ordering Feb. 18, ships first week March
- Initial run: 50 of each. (Yeah, that’ll sell out fast, even in this economy.)
A design like this rightfully raises questions – even doubts – so I’ve spoken with Brian to see how he sees his latest creation.
CDM: Who is this for? Is it primarily a companion to the monome, or might you imagine people using it as a controller on its own?
Brian: fundamentally it’s for people who are interested in exploring new methods of interaction. the arc is simply a high-resolution encoder and a bunch of lights. like the open decoupled grid, it’s a blank canvas which provides the same opportunity to invent, share, and generally think differently about process.
while certainly it makes sense integrated into larger systems or paired with a grid device, i’m hoping the extreme constraints will also prompt ambitious, minimalist performance tactics. and it’s not simply a fancy volume knob. the visual feedback has sufficient depth to facilitate much more exacting use of the input. i do see the possibility of interesting two-knob applications that make good use of visual feedback and various modes.
Price seems to be a debate no matter what things cost, so let’s ask it another way – realizing many people aren’t familiar with what goes into manufacturing and how that impacts price, where does the cost of an arc go? What are the major sources of its cost, specifically?
like the grid devices before it, the arc had several tricky design challenges. it’s often more difficult to achieve a minimalist aesthetic, which is perhaps counter-intuitive.
the materials, sources, and people we chose to work with account for the cost. the enclosure is milled solid black walnut, harvested in central pennsylvania. aluminum work, anodizing, glass cutting (that is not plastic), laser cutting, sheet metal fabrication, circuit assembly, and pcb manufacturing all happen in the eastern US. we’re deeply invested in our local economy.
there’s no one part that makes the device expensive– it’s the total number of custom parts that seem somewhat cheap on their own– and there are a lot of them. i’ll be sharing some photos of the construction process when we get a chance.
of course, there’s the fact that these devices are hand-made in very small batches– we don’t get huge discounts on quantity orders.
but comparing prices is a bit silly– we’re not really competing with yamaha or novation or the like. if you truly appreciate what goes into these devices and what they do (and don’t do), i think you will find the pricing fair and reasonable.
With just two encoders on the main model, there’s a lot of focus, obviously, on just these controls. In practical use, as you get your hands on this thing, how much do you find having the additional resolution makes a difference? Can you really make movements small enough to take advantage of it?
tiny movements can be tracked– 256 steps per revolution– and the large knob allows for greater physical control. high resolution is a major benefit. there’s room for more subtle gesture in controllers, and i’m hoping room for thoughtful, slow, and maybe even quiet musical contours.
the integrated pushbutton allows for press-sweep-release gestures, toggling, or however the application would like to interpret the data. in a way it doubles the input streams per knob– turning while pressed, turning while depressed. with the correct app design this feels remarkably natural.
How are those messages sent via OSC?
there’s a simple format similar to other monome devices. we’re about to release a new serial-osc server (called serialosc) which will make for a much more plug-and-play experience.
encoders send out delta values: +1, -1, -2 for example. they don’t have an absolute position, so it’s up to the software to count and transpose these values. it makes for much more interesting translation of what knob movement means– for example you could map a single “tick” to be 1 normally but 0.1 when holding the button down– coarse/fine movement.
the led ring has a flexible and detailed set of messages. set a single led, set all leds to one value, set a range of leds to a value, or send a whole array of 64 led values in one OSC packet. these optimizations allow for incredibly fast refresh rates, resulting in very smooth animation.
the leds support variable brightness with 16 values per led. i see a lot of potential here– layers, waveform mapping, background vs. foreground, reactive metering…
As I recall from our conversation, USB connections are different than on the monome, yes? Will you use USB class for control as well as serial-over-USB? How will the arc connect to software?
we’re using ftdi again. long boring story! some other time.
Ed.: FTDI refers to a chip manufacturer. Long story short, this involves having a USB device act as a standard, non-USB serial port, which involves drivers. (Fun fact: those drivers are now rolled into recent kernels on Linux, which makes life easier for free software users.) The arrangement works, and in the past people have appreciated the performance they get out of the arrangement. It does (likely) knock out the possibility of using your arc with an iPad.
Why only two (or four) encoders, and not more?
you can already get more encoders elsewhere, but without resolution of input or output. we generally don’t like reinventing things that already exist.
for this project i think having too many elements detracts from the focus. we’d prefer a high degree of detail.
What patches have you seen created so far for this?
that’s a funny question given only one prototype exists at the moment! but the monome forum seems to have already brainstormed several pages of possibilities– one user even created a flash app for realizing detailed diagrams.
the community really surprised me on this one. i figured new apps would come about quickly once the actual devices were out in the wild, but never did i imagine apps were getting first versions before the hardware was ready.
The first run is limited, but if it’s a big success, do you anticipate making larger runs later?
certainly, though we’ll follow our same methods which have proved successful over the years– releasing in editions, and trying to create enough to meet demand but not much more. it’s still just kelli and me building, and it’s not great to have extra parts laying around.
Brightness you noted was addressable; how would you control brightness on the LED rings?
/enc/ring/set n x s
where n = encoder number, x = led number, s = state/brightness (0-15)
Presumably if people wished to add, say, accelerometer and/or tilt, they could do so? (This wound up creating interesting variations to control on the monome.)
i’ve done a huge redesign of the electronics, modularized and standardized. we’re working on a tilt upgrade that should be a matter of plugging in a small ribbon cable.
Will any component of this, beyond bundled software, be released under an open source license, or is it already? (I think perhaps the USB chip you’re using already is?)
i’m looking at licenses (some which you referred me to) and expect to post firmware and schematics and everything. it’s not realistic for people to make a DIY version (complicated boards, insanely tiny parts), and we won’t be making a kit version (though we will have an encoder module that will plug into the new mk).
most importantly, the protocol will be open source. both the serial and OSC protocol. so smartphone emulators and arduino clones will be possible and encouraged.
Because the hardware is not available under an open source license and cannot be freely redistributed, I wouldn’t call monome or arc “open source hardware.” At the same time, it’s different in significant ways from conventional proprietary hardware, and it does have genuinely open source protocols and software. Perhaps “modifiable” is another word. Without getting stuck on labels, how would you describe what the monome is? And you’ve talked about some other priorities you have that exist outside the open source discussion that seem they also merit conversation; can you comment on that?
i agree, it may need another name.
i’m slightly ambivalent about the label “open source hardware.” it’s come to mean more than simply having the sources available, which was my original goal. people should absolutely know how their equipment works and be able to modify it if desired. it’s turned into a different conversation, about freedom– the most anonymous free-market sort of freedom. and this is a good conversation to have, but it somehow left the realm of sharing and went somewhere else. i wish more people were interested in discussing resource use, materials, and local economics– these are very real issues concerning physical goods. the open source hardware debate seems to have inherited too much from the open source software ideology.
overall i’m a proponent of communicating with people. if you’d like to use someone’s work, contact them and chat about it. licenses are only a starting point.
Side note – OSC messages + Arc
TheAlphaNerd posts via comments this excerpt of Brian on the forums. This should be considered a draft of the OSC implementation, but I think is interesting nonetheless.
To simplify this… there are 64 leds per encoder. There are 16 stages of brightness. Leds can be changed as a group or individually
“most of this is still tentative, could endure minor refinements before the end of the month.
in short:
from device:
/enc/delta n d
where n is encoder number, d is change (ie 1, -1, +2)
/enc/key n s
where n is encoder number, s is state (0,1)the refresh is incredibly fine and fast, so unless you’re really throwing the knob, you rarely get beyond 1 or -1 on delta.
that said, it’s “up to you” to keep a counter when writing your own apps. i’ll be making a bunch of “helper” apps and templates to provide high-level functionality to app writers.
one thing to consider– being able to set rotation limits (setting ranges), “chunking” the display into 16 sections, having the rotation speed (fine vs course) be set by the button press.
what about a rotating led cycle that’s an LFO (or sample playback)? turning the know pulls at the velocity like a turntable. push down the knob and it applies a friction brake. hold it down and spin one way to give it a serious push, let go and it runs free.
etc.
protocol to device:
/enc/ring/set n x s
set led x (0-63) of encoder n to state s (0-15)
/enc/ring/all n s
set all leds of encoder n to state s (0-15) like /clear on monome grids
/enc/ring/map n d[64]
map array d (64 values) to encoder n, like /frame on grids”
It’s still early days for the arc, as it awaits production and more patches and creativity. I hope to offer more on it as that happens.