hedgehog/hardware/ HomePage

What is a HedgeHog?

This is a mouse. We are all familiar with them.

Now consider a separate peripheral with an assortment of knobs and buttons. I wanted a 'cute animal that isn't a mouse' nickname for it, and settled on HedgeHog. A while back, for example, I made one out of an Arduino and a few rotary knobs I bought online (see HumphreyTheHedgeHog).

But the concept is to view things abstractly, in the sense that it is a bunch of buttons and knobs and other assorted controls – everything else is software defined.

For example, it could be a MidiController like the BehringerBcr2000 (with the rotary controllers set to 'relative' mode), or a device like the NovationNocturn (provided your computer can talk directly to it, which limits it to Linux at present – on Windows and Mac it only works with Novation's discontinued Automap software), or even a keyboard or trackball, or touchpad or even a mouse, provided you can stop the keyboard/mouse functioning as a conventional one and just telling the computer what buttons were pressed without the OS doing anything with it. (A mouse has two relative controls, one for the x-axis and one for the y-axis, and a few buttons.)

Basically we want our peripherals to be as dumb as possible: they tell the computer what buttons were pressed, and the computer tells it what LEDs to light up, or what to display on any LCD displays. It is as simple as possible.

The thing is that, if we have control over what happens next, we can send those controller events anywhere. The other half of the idea is 'making everything addressable'.

The Point of Hedgehogs

Why do we want our peripherals to be as dumb as possible? The reason is that we want IntelligentControlSurfaces. And we want to be able to customise them to our workflow, including choosing what controls we have. There is a certain amount of modularity that is desirable, such as rotary encoders coming in groups of 8, (or the 8+1 configuration we see on the NovationNocturn and Native Instruments' KompleteKontrol devices). We want to keep as much of the intelligence in one place, rather than trying to have multiple pieces of 'intelligent' hardware staying in sync – that way is akin to herding cats, and leads only to chaos madness.

So a HedgeHog family has some designated hub towards which essentially all controller events, and from where messages are sent to applications. (One exception is Midi keyboards, where you want to avoid the latency of having events flowing over a network.)

Connecting HedgeHogs

The easiest ways to connect a HedgeHog are a simple usb-serial link or midi. For example the Usb TourBox uses a usb-serial link, sending one byte per button press/knob movement. Midi uses multiple bytes per event. So does Humphrey, using a protocol I named MX7 (MessageExchange 7bit). The original idea was to use a 32bit protocol (MX32) for more general messaging, but OSC is an ideal protocol for virtually all circumstances.

Applications

The most basic thing we can do, to control applications, is to generate virtual keypresses. For example, I press the leftmost button on my Nocturn, and it sends 'ctrl+shift+M' to the focused application; or I turn the knob three clicks to the right and it sends three 'ctrl-Right' keypresses. This is how TourBox's Console controls applications.

Music applications are much more developed in this regard, and Midi control surfaces have been around for decades. The OSC protocol dates back over a decade.

Now it takes only a few lines of code to receive UDP messages. There is then plenty of free open-source code to parse OSC messages. In general, we want to map OSC messages to actions. So it is potentially easy to make an application respond to such events. It is a case of convincing developers to make their apps 'hedgehog-friendly'.

Existing hardware

Novation Nocturn

The NovationNocturn is ideal except for one annoying thing: it can only be used as a generic MIDI device under Linux. Under Windows or Mac, it only works with Novation's discontinued Automap software. So to use them, I use either a Linux laptop or a Raspberry Pi, which receives events from the device, and sends cc events to switch the leds on and off (and adjust the encoder rings), and talks via OSC over the network using software I tend to write in Python. By using dlls and so libraries loaded by ctypes, you can basically do anything.

The annoying thing about the Nocturn is that, behind the scenes, it (I think) communicates with the computer by sending raw MIDI data (specifically MidiCc events), and would otherwise be class compliant, but requires a proprietary driver under Windows and Macos which means it only works with their discontinued Automap software.

As I said, under Linux, it works like a typical MIDI device, so to make use of them, I use a Linux laptop or a pi as a hub.

Generally, the idea is that the hubs form a HedgehogFamily.

Komplete Kontrol

NativeInstruments' KompleteKontrol devices would be ideal except for one major flaw. Like with the NovationNocturn, they only fully function with the vendor's proprietary software.

Behringer BCR-2000

This device has been around for nearly two decades, and was my original inspiration. (I'll not go through the long story over here that meant it is only now that this idea is coming to fruition.) It has 32 rotary encoders. The row of encoders at the top are also push encoders (you can turn them, and you can push them). The firmware makes them appear as four banks of 8 encoders. Then there are three more rows of 8 encoders. For our purposes, we want to ignore the bank switching, and to set all the encoders to send relative MidiCc events. Thankfully you can just send it a MidiSysEx message to do all this.

TourBox Neo

This is basically a hedgehog with proprietary software to allow it to control applications. The software is pretty limited, and for example can't generate Osc or Midi, or pretty much anything except for virtual keyboard events.