Controlling axoloti via USB

#1

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

axoloti 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.

midi

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

thoughts?

Accessing parameters in subpatches
#2

I think extending the axoloti protocol is the way to go. Encapsulating binary data in midi is ugly and will be very inefficient. OSC, I think a deamon running on PC is the best way to deal with OSC compatibility, the other option would be a USB network interface personality but I'd rather avoid that...

The axoloti usb bulk protocol needs a cleanup though, now it is packets encapsulated in a bytestream encapsulated in usb packets. This is not efficient or elegant.

#3

yeah, seems to be, but has the disadvantage that you need usb code to use it...
e.g. say something wanted to write a front end in Max/Msp, midi they could do directly, but for this they need to use an external.
also... its likely own one application can use it at a time, e.g. if you have the java UI open, you probably won't be able to use your Max app, because the USB device is already open.

Ive also have a general fear of some 'all encompassing protocol' - being too ambitious on dev projects, usually means things just don't get done... Id far prefer an 'extension' approach, that allows it to evolve, and allow individual projects to add things they need.

I completely accept the above might not even be a priority for axoloti/other users, so I need an approach that I can get on with, but with confidence that the work will not have to be redone entirely due to (for example) the axoloti protocol changing.
(ok, I can do a certain amount of encapsulation, but it has to make some assumptions about the underlying transport)

#4

Don't quite understand syntax of NRPN in Axo.
My controller (Xboard) is sending NRPN's like this:
B0 63 15
B0 62 28
B0 26 54
B0 06 1F
Last two bytes are the two 7bit LSB and MSB values.
I tried to look at the output with object "midi/in/cc hr ii" plus object "disp/hex", filled in 99 and 98 in the first two boxes, but didn't give any output. An oscillator responded tot modulation via CC-number 38 (= $26) but with very strange noises, no linear sweep.
Has probably to do with the osc not being able to see the LSB and MSB as such.
Any help would be appreciated.
Sorry if slightly offtopic or noobish question (or both).

#5

this was a discussion on how we could send the parameter set...
currently axoloti doesn't support NRPN directly ... though NRPNS are just CCs so you can interpret yourself using the normal midi/in/cc or midi/in/cc hr ii

with NRPN 63/62 tell you the parameter thats changing on your controller/synth, 26/06 tell you the data value.
note: I follow the convention that bytes are sent LSB then MSB, and he MSB triggers... this is the approach used by the continuum to ensure that you dont get data jumps when sending 14 bit values. whilst also allowing 7 bit midi to still be compatible.

unless you have a very good reason , i would not use NRPNs ... they take up alot of bandwidth as they take 8 bytes (over usb or 6 over din) for just 2 bytes of data.
nrpns tends to just be used by synths, where there are hundreds of parameters to map, and even then the most common tend to also be assigned to CCs.

(its the 100's of parameters argument, that may be suggest it for axoloti mapping... but we'd still need to use sysex to send data about what they parameters actually are... i.e. metadata)

#6

Any recent developments here? I'm getting very interested in this area in order to drive axoloti patches with custom graphic interfaces on iOS or Android devices. Currently, there are several off-the-shelf toolkits that can speak MIDI or OSC so there's a potential big plus there. I'm not good at low-level code myself, but I can drive such things, as well as pd and Max, fairly fluently.

I know that some devs in the music app space are interested in something similar.

#7

Ive been kind of waiting a little to see whats going on with Axoloti Control, as this will also need some work to tidy up the parameter broadcasting.

but that aside, Im personally now tending towards some kind of midi implementation.
I suspect there might be a couple of ways to do this - one is sysex data for meta data + cc/nrpn etc, the other just using sysex.

sysex is not perfect of course, as there are quite a lot of environments that cannot process, but its really the only way to send the textual meta data. (e.g. parameter names)

this is preferable over the bulk interface since it doesn't require a particular low level driver to handle the usb data.

the 'trick' is to keep the data as compact as possible, since USB midi already has a 25% overhead, and NRPN and SYSEX also have overheads... however, Im hoping with once the data is packaged/throttled this wont be too bad.

as for development, I (personally) need to do some work on another part of my project that will make use of this data, before there is any point in doing this, but once thats done I guess I will quickly do something (as a proof of concept) that can be based on the Ableton Push work I did.

#8

Thanks, Bear. I tend to agree about using midi. We've been noting its warts for decades now, but it's still the only game in town in a lot of ways.

I look forward to hearing more on your project.