Configure MIDI control code mapping

[dpwe]

AMY will accept MIDI commands to play notes. And we have an example, in midi_mappings.c that allows the Juno VCF base frequency and resonance to be set by MIDI control codes 0x70 and 0x71 on channel 1. But this feels pretty cursory and is of course dependent on the particular structure of the Juno patch, not universal.

Instead, it would be good to have a mechanism to configure the routing of MIDI control codes to arbitrary AMY parameters via an AMY wire code template. For instance,

ic<C>,<L>,<N>,<X>,<O>,<CODE>

where C= MIDI control code (0-127), L = log-scale flag (so the mapping is exponential if L == 1), N = min value for the control (corresponding to MIDI value 0), X = max value (for MIDI value 127), O = offset for log scale (so if L == 1, value = (min + offset) * exp(log(((max + offset)/(min + offset) * midi_value / 127) - offset), and CODE is a wire code string with %v as a placeholder for the value to be substituted (also %i for channel/synth number) and maybe %V to force an integer, for things like selecting wave, and maybe more.

So an entire command to set up the VCF control for the Juno patches on synth 1 (as in the current midi_mappings.c) would be:

i1ic112,1,20,8000,0,i%iv0F%vZ
i1ic113,1,0.5,16,0,i%iv0R%vZ

That would set MIDI CC 112 (0x70) to set the constant term of the filter_freq of the voice's osc 0 to vary from 20 to 8000 with log mapping, and MIDI CC 0x71 to vary the resonance from 0.5 to 16, also with log mapping.

(I'm not sure the message parser can currently handle mid-string Zs for commands including wire-command arguments, but the syntax is not ambiguous, even if it makes the parsing more context-dependent).

[dpwe]

Note, this idea comes from playing with the knobs in the AMYboard web interface. In particular, the N/X/L/O parameters are the same as those used to configure knobs in amy_parameters.js, and indeed we already have the CODEs more or less ready to go in that code. It would be very nice to have a simple mechanism to attach a MIDI control code to any knob in the web interface.

[dpwe]

Remembering our effort to expunge places where you have to know wire code (see #367), we could employ a similar technique here where an event that includes i0icNN can include any other events which then get stored in a separate chain of deltas specific to the MIDI control code. We could have it that if you specify the min/max/log, it means you're defining a new event, but if you omit them, it means you're cumulating onto an existing definition.

There is, however, the problem of where to put the calculated value. When the MIDI CC comes in, the handler will calculate a value using the min and max etc., but then it has to substitute it somewhere into the stored delta sequence. But the substitution point has to be indicated by an actual, acceptable value in the event structure.

We could do this with magic values. Right now, we indicate unused values in the amy_event structure with AMY_UNSET_VALUE, which is nanf("") for floats and INT_MAX for int types. We could similarly define an AMY_PLACEHOLDER_VALUE as nanf("1") for floats and INT_MAX - 1 for ints, then the user indicates where to substitute the calculated value by passing one (or more!) of these in with their events.

Unfortunately, the arg to nanf(char *arg) is not standardized in C (i.e., it's implementation-dependent whether it's supported at all) and as a result it's a pain to actually distinguish them. I don't actually know if our microcontrollers implement it. So we could use a different, specific value (like 1e30) to indicate a placeholder. For C users, that could be hidden in a #define, but for wire-string users, trying to include 1e30 in a wire string (where we've explicitly disallowed scientific notation, since we need the e) would be a pain. Maybe 1e10 then.

I think for the first implementation, we'll limit it to wire-command specification.

[dpwe]

Completed in #532