#The Case for Hedgehog (aka Mx32 and friends)

<div class='centre'>
"Who wants a mouse that only works with Photoshop? Or a keyboard that
only works with Microsoft Word?" --- John Allsup
</div>

## 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.**