this topic is to discuss options of controlling Axoloti via the USB device port.
(though arguably the same method could be used for the USB host port)
primarily this is for my own project, but could be useful for axoloti as a whole or other developers doing similar things,
so perhaps there is an opportunity for collaboration.
the basic idea is for a hosting device (in my case a PI2/Beagleboard) to be able to control the axoloti board,
in particular my goals are:
- parameter control
- sequencing control
- meta patch data e.g. what parameters are available etc.
- patch loading
- binary patch (& possibly other files) distribution.
- possible some 'firmware level' control e.g. gain level/mixing adjustment.
note: the above implies bi-directional communication
It can be seen i think, with the above any kind of UI could be generated to allow live performance e.g. the LIVE view of the current java UI but crucially without having the patch available
(this is critical since on multiple boards you may be running different patches)
currently Im considering 3 approaches
- using/extending the 'axoloti protocol' , the protocol used by the current java UI.
- using MIDI with a combination of NRPN/sysex
- a completely new protocol
this seems the obvious one, but it currently only supports a subset of the above, and I'm concerned about taking it in directions that are contrary to those intended, whilst also needing to be able to take it where I need it to go...
I also have to ensure I dont break the current java UI - though this can be avoided by a simple prefixing that can be ignored by the UI etc.
use NRPN to control parameters etc, and sysex for other info (eg. patch loading commands)
using NRPN means good compatibly with lots of apps, but restricted to numeric data, so for more data we can use sysex.
(would need to extend sysex support in axoloti)
new protocol - compressed OSC?
the difficultly with this approach is it would either need to use a new USB interface (so extend it) , or there be some means of switching the existing 'axoloti interface' (as i dont need both protocols to be running at the same time)
why use a new protocol?
Im thinking of something that might be like a compressed form of OSC... e.g. a message catalog that is sent upfront but from there is quite like OSC.
the idea being, this could then easily be transformed into OSC at the other end, (and perhaps rebroadcast) which then could be a way to control axoloti from a variety of sources. (e.g. say Lemur on an iPad)
obviously technically, the most important requirement is the protocol used can be quickly generated/parsed on the axoloti side, as it has limited resources. the host has more power so I dont think is an issue.
I think the first 2 are the most likely for me to go with, but thought id raise the other as perhaps its more interesting to others....