The Case for Hedgehog (aka Mx32 and friends)

Food for Thought

To begin, I want to ask you to imagine a few things.

1. Imagine you had a nice, shiny, £100 mouse. Produced in association with Adobe, and which only works with Photoshop, and except for being used with Photoshop, is only a small paperweight.
2. For a slightly different image along the same lines. Imagine that, while with Adobe Photoshop you got the full functionality of the mouse, with all other apps, the best you got was that the buttons worked, but not the X-Y movement.
3. And for another, not quite as bad, but almost example. Imagine you had a SuperPainterMouse(™), which had, say, pressure sensitive buttons. Imagine that this mouse could work with applications aside from Photoshop, even worked on Linux, but only worked with with painting programs which had to integrate special support for this SuperPainterMouse(™).
4. Now imagine someone using Libreoffice Writer. They want to change the font size. At present, they have to grab the mouse, find a small area towards the top of the screen, and then either click a drop-down menu to select a value, or perhaps click on a tiny text box and type a number in. Imagine if, as an alternative, they could just grab and turn a knob?
5. Now imagine you had a set of e.g. 4 or 8 knobs on a small device attached to your USB port. You could select e.g. text colour, and then those 4 knobs could either step through a palette (a simple 24ppr rotary encoder with detents), or perhaps use three knobs to adjust R,B,G or H,S,L or something. All at the choice of the user, and selected somehow.
6. Then hop over into Gimp, and imagine you have those same 4-8 knobs. Now you could paint with your right hand, e.g. using a pen, and use the knobs to control e.g. brush size, or colour, or something. The serious power user could have a few banks of these knobs so that everything from colour, brush size, and so on, could be controlled with those same general purpose knobs.
7. Now imagine that the hardware could be made by makers with an almost trivial bit of wiring, and an arduino, and simple code that only chas to send bytes over a USB-serial connection to report when knobs are turned or buttons are pressed. Everything else happens downstream in software. (Possibly including things like all but the simplest debouncing.)
8. Then imagine you are a bedroom hobbyist music producer who also uses their PC for other things like word processing, web browsing, and digital art. They have a small keyboard, like e.g. the Komplete Kontrol M32 (an example, but I have one). In your word processor, you could use e.g. middle C to toggle bold, D next to it to toggle italic, other keys to select the mode for the 8 knobs, and then use those knobs to control e.g font size or text colour. And use those buttons for things like shortcuts to select styles. But as things are now, you only get full functionality of an M32 with Native Instrument's own proprietary software. There is no 'dumb' mode where it only reports raw hardware events. Even the midi mode has issues since, unlike the Behringer BCR32, you can't configure the rotaries to work in relative mode so that they simply report +/- 1 events when knobs are turned..
9. So imagine the world where what those knobs mean is software defined. Actually, think that things are also reasonably network transparent, so events on one machine are directed to a general purpose event hub, and then forwarded over the network, possibly with our without processing, to other machines. **You could use a spare laptop with e.g. a touchscreen (like TouchOSC) to control things, but not just music applications.

So that's the vision for part of it. Here are some more analogies to consider:

1. Consider the telephone system. Imagine you had a phone system that could only connect to a quarter of the people in your village, and nothing else. If you wanted to talk to a friend in another city, you had to find out which telephone exchange they used, and find a local phone compatible with it. You couldn't just use your phone, key in the appropriate phone number, and talk. Stupid isn't it. But that's what it's like at present, in the domain that Mx32 seeks to improve:

   a. To copy to the clipboard, you usually press Ctrl-C, but that

   doesn't always work. With a terminal emulator on Linux or Windows, often you have to use Ctrl-Shift-C instead. With some emulators, since Ctrl-C is needed to send a cancel message to a command line program, they use the very old, pre-Windows 95 keyboard shortcut of Shift-Insert to paste, and I think you have to select and right-click the mouse to copy. In this day and age, it is silly. You want the equivalent of a 'copy emoji', that you send the program, and it then know, unambiguously, that you want to copy. You could even use an extra character or Word to indicate which clipboard you want to copy to (so you can have multiple clipboards). How you send that 'copy emoji' is up to you, but if you had a bank of configurable function buttons, or a small touchscreen, or even an app on your smartphone or tablet, any of those are capable of sending a signal, possibly over a network, so that your desktop OS knows to send the 'copy emoji' to your focussed application. It also opens the door to scripting having an easy way to send a copy signal to a program. *And this concept extends naturally to any*** signal we want — everything a menu item does, could be triggered by an appropriate signal, and standard things like Cut, Copy, Paste, Open, Preferences, etc., could be represented by the same 'action emoji'. Per-application keyboard shortcuts are so twenty-five years ago.

2. Or instead of the phone system, consider the modern email and the Web. This works so well because there is only one email system, with standards, and comprised by multiple networks that talk to each other via standard protocols. And the Web is viewed by a small number of browser engines (Blink, Webkit and Gecko), which all follow a public set of standards. What can be standardised between browsers often has been, and this makes life so much easier for Web developers compared to how things were when there was IE and Netscape with their own independent, incompatible extensions to HTML and Javascript, so that you had to add lost of random browser detection code.

3. Now consider one particular framework: Qt. It has a nice concept of 'Signals and Slots', inspired by Objective-C's paradigm of objects sending each other messages, in turn inspired by Smalltalk. But Qt Signals and Slots only work in Qt programs, and only within the same program. Objective-C messages, which in Swift are now reduced to acting like simple function calls with a small extra overhead, are confined largely to within an application process. Conceptually they all do the same thing: send a recognised signal from A to B that something has happened, or that an application wants something to happen. If it is conceptually the same, it should be implemented in a cross-framework network-translucent way. (By network translucent, it is meant that it may be possible to tell whether things are going over a network, but in principle any signal/event should be possible to send over a network, in a way conceptually similar to doing it in-process, and in a way which is freely available, cross-platform and cross-language. There have been a few examples to think of: Objective-C's distributed objects (and PDO), but that was confined to Objective-C and proprietary NeXT systems, and largely deprecated by the time MacOS X came out, so was useless to anybody by the end of the 20th century. Then there is QNX's window system, which was closed source, and proprietary to QNX's real time OS, so useless to anybody else.)

4. Now consider something good for a change. Unicode. Before Unicode, we had 8-bit character sets. The first 128 of these characters were standardised as ASCII, and the other 128 could be used for other things like accented letters. But 256 possible characters was way too small. Unicode change this by having essentially a 32-bit space of possible characters (so basically on the order of billions), from which they could allocate code points for every character in every alphabetic language, most of the symbols from Chinese, and plenty of emoji too. Going from an 8-bit standard to a 32-bit standard opened myriad possibilities which nowadays we take for granted. Mx32 aims to do something similar for signals and events, both within and between processes, and both within and between machines on a network, possibly across the internet.