hedgehog/software/ HomePage
Some Useful UniversalControl software:
- OSC in general: apps that send and receive it.
- AutoHotKey
- https://benjamin.kuperberg.fr/chataigne/en
Toy Examples
I am a big believer in 'toy examples' — the smallest, simplest bit of (readable, not code golf) code that illustrates a concept and how to implement it.
- HedgehogPyScribble001 – the Qt Scribble demo app rewritten in Python, which receives OSC messages that change the pen size, both absolute via /penwidth and relative via /penwidthby, both of which take integer parameters. Naturally other parameters such as colour could be controlled in the same way, and other events, as illustrated by /clear. That is the general idea, and all the clever workflow design can be factored out of the app – the app needs only to do as it is told. Part of the idea of Hedgehog is that the core of an app is controlled by receiving messages, both from the App's own UI, and also from external sources, so that a user can control an app with anything he/she wishes.
Experiments
My aim with Hedgehog at present is to produce as simple a concept demo as I can. I can't hope to actually implement it in other people's applications, save for perhaps hacking some code into some open source projects. The idea is to make it simple enough for developers to implement that, for the gained functionality, it is a no-brainer. It is also necessary to be compact, hence where scriptability is concerned, I am leaning heavily towards Lua.
- SimpleHud — display things like the bank number, or perhaps other information. All this example will demonstrate is showing a number. Though it is naturally possible to adapt to show arbitrary text in a similar fashion.
Development
The general idea, from app developers, is to receive OSC messages. That means listening on a UDP port and parsing OSC packets. These can be assigned to actions, and possibly parameters can be passed (e.g. so that we could have brushsize/changeby/percent 1.0 to increase the brush size by 1%, and brushsize/changeby/percent -5.0 to change it down by 5%). More generally, we'd like scriptability, so for example a .lua script (thinking of Reaper here) could bind a message to an action which is implemented by a .lua script, and osc_params is defined as a global variable in the context of the script.
There is no need to actually implement Midi listeners, as we could easily have a translator that receives all hardware events and outputs OSC messages wherever. Essentially all controller events flow into a single hub, which then dispatches them to the desired application. Following the active window is a case of having something inspect the active window every 100ms, and sending an OSC message to the hub when it changes.
It can make sense to have chains of hubs relaying messages, so e.g. one device on the network receives input from e.g. Novation Nocturn's (which at present means a Linux device, until someone can write a Usb driver for Windows/Mac that allows us to receive controller data from a Nocturn as midi (since behind the scenes, the Nocturn sends midi data to the computer)).