Parameter editor


#1

When using the Axoloti tethered to a computer, there's of course the beautiful UI where we can see parameters and twiddle virtual knobs to change them. And of course it is possible to control any parameter externally using CC. All of this is great, but what I would like is the option of a classic synthesizer interface, i.e. being able to call up a set of parameters on an LCD, and then having a row of knobs (pots or encoders) to change the values. I like machines which have a built in tactile interface, and just hooking up a external MIDI controller doesn't offer the feedback of the current values of the parameters.

Even if one had a full front panel of controls, some mechanism would be needed to detect when a knob had been turned and not change the corresponding parameter's value if a knob is just left in its current position.

I know that thoughts to this end are intended to be addressed by the Axoloti Control if and when it materializes, but it seems to me that a simple parameter interface would be possible to implement on the Axoloti Core itself. What I'm thinking of is something centered around a simple character based LCD.

Some thoughts on connecting an LCD have been given in
this thread, and there are also some thoughts in this thread.

Ok, so there's a lot that needs to come together for this to happen, not to mention an LCD interface. Actually, a character LCD is fairly easy to drive, you need 5 or 6 or so interface lines, plus a driver that will do initialization, and apart from being able to write characters you need to be able to position the cursor. I think that wouldn't be too difficult; it could be implemented as a standard Axoloti object. And the Axoloti already supports a string data type which would be handy for writing stuff to the LCD.

The thing I'm trying to understand how to approach is some form of API to extract a list of existing externally controlled parameters and their values, and somehow to send back updated parameter values to the Axoloti framework. Something like this may already partly be in place, and of course I can check the code, but I thought it a good idea to see what any thoughts, perhaps some or most of the required API is already in place.

What I'm thinking about is some form of object where you can define the names of parameters, and some referece to them, and group them into pages which would fit on the LCD in question. When a given page is addressed, the relevant parameters are fetched and displayed on the LCD. When the corresponding knob is turned, the value of the corresponding parameter is then sent to the Axoloti framework which then updates the parameter just as if it were input from the GUI, or recieved via CC. The thing that seems 'new' about this is being able to extract the current parameter values, not just set them. And not just the values, it needs to get mix/max values etc so that the proper value range can be displayed and enforced.

Some mechanism would have to be devised to select the currently used parameter page, but that could be up to the patch itself, e.g. using push buttons, or a global parameter which selects the currently displayed parameter page.

The core of all this would be some form of parameter management object so I think that's where one would have to start. The rest can be done with existing tools.


#2

There does seem to be some form of UI code in firmware/ui.c, but its top level thread function (AxolotiControlUpdate() or pControlUpdate which points to it) doesn't seem to be called from anywhere, so ... mostly an idea so far?


#3

have a look at my push object (in community library) , it does something similar to what your trying to do.
(i.e. view and update parameters)


#4

Thanks, I just checked out your short video demo too, yes it's something like that I'm after, perhaps with some form of mapping of the parameter names to shorter ones in order to fit in a smaller display but yes, I'll have a closer look at that code.


#5

from memory, there is no short name ( I may be wrong, been a while) , but often code uses algorithms to derive short names... strip vowels etc.
I will point out 'parameters' are a bit 'work in progress' when it comes to external controls, since much of the work stems from axoloti remote/control, which took a back burner to get axoloti core released. this means something things are missing from the parameter map, and the structure is not complete.

basically its ok for the basic controls but of limited use for things like selectors... and there is not a proper mapping of the hierarchy when you have sub patches... this means its fine for 'basic' patches, but I found it a little lacking for more complex patches.

Ive raised this with @johannes (when I was doing the Push stuff), but as you can imagine there are a lot of things to do, so this will have to wait till it 'bubbles to the top' of the priority stack, on my side Im a bit busy with other projects at the moment, but it is something Id like to look at in the future, time permitting.


#6

My hardware synth-in-progress is using a Teensy board to hold state and pushes the settings over MIDI-CC (via a header at the back of the DIN socket). This gets around the need to view parameters (haven't found a reason to yet) as only the settings that matter are held on the Teensy. Kind of like MVC pattern. Basically though, this is just a midi-controller with more intelligence.

Also connected are 10 knobs for immediate access. An Adafruit Trellis for a mod-matrix and an encoder+OLED screen for other parameters (also includes an oscilloscope!)