(LONG) MIDI control (for loopers and other devices)

[Tom Ritchford <tom@swirly.com>]

[sorry... this is very long but I hope quite clear.
  as you can see, I've been thinking about this for a long while... /t]



GOALS IN WRITING MIDI CONTROL PROGRAMS

zeroth priority:
  ACHIEVABLE.  must be able to make it work without too much work.

first priority:
  COMPLETE.    as much functionality as possible needs to be 
accessible from MIDI.

second priority
  CLEAR.       it should be "obvious" (to a reasonably technical person) 
how to
               access these functions from MIDI.  More common 
functions need to be
               "more obvious".

third priority
  EFFICIENT.   it needs to make reasonably efficient usage of the memory,
               computational, audio and display facilities of the machine.


DEFINING OUR TERMS


A "MIDI command" or just a command is some bit of MIDI generated by the 
user
that's supposed to control the machine (ie, program changes, control 
changes,
pitch bends, NRPNs, system exclusives, etc...)


Conceptually, you can think of the machine's controls as having
a "state".  (For the looper's MIDI control, the audio in the machine
isn't really part of the state.)

You can talk about the state of the whole machine.
You can talk about the state of a part of the machine, like the state 
of one channel.
Or, you can talk about the state of a single control.


Finally, "internal settings" or "settings" come in two flavours.

Switches have two or more discrete settings, like "on"/"off"
or "audio/tap/internal".

Dials have "continuous" settings, even though the granularity
of this might be quite small (or quite large...)  For example,
dials would be "loop time (0.000-128.000 seconds)"
or "feedback level (1-8)".


So, we put together settings (switches or dials) into parts, and
then assemble the parts into the whole state of the machine.


WHAT IS THE PROBLEM AT HAND?

We want to see how to map "MIDI commands" into changes to "internal 
settings".




SAMPLE MEMORY IS EXPENSIVE, USER TIME IS EXPENSIVE,
CONTROL MEMORY IS CHEAP, CONTROL PROCESSING IS CHEAP

Suppose a user command is represented by a (wildly generous) 100 
bytes on average,
and the user has programmed 1000 commands, surely quite a few.

The total memory consumed here is a measly 100K, or about one second
of stereo sampling.


Users (ie "musicians") are really unable to generate too many different 
sorts
of streams of information while actually using equipment.  You can't 
generate
hex code on the fly!


Modern processors perform hundreds of millions of operations a second.
Processing audio takes many hundreds of thousands of operations a second.
One user has trouble generating a thousand control operations.

This means techniques like "table lookups" or "linear interpolation"
are essentially "free" (a table lookup on a modern microprocessor might
take 100 nanoseconds!) and can be used if at all helpful.



ON WITH IT!

Without further ado, I'll present a nice, simple and general model for the 
MIDI
control of a machine.


A LIBRARY OF STATES

You need to be able to recall the state of the entire machine by some 
sort of name.
It's fine if these names are "1", "2", "3", etc. but text would be nice 
too.


BANKS OF COMMANDS

Commands need to be organized by banks.  (see control processing is 
cheap above..)
There need to be a lot of banks possible.

Informally, one bank == one song.



A "bank" of commands describes exactly how "commands" are mapped into
"changes to the settings".

A bank might conceptually say something like

   Program Change 1:  recall state 1
   Program Change 2:  set record on loop 1 to on
   Program Change 3:  set record on loop 1 to off
   Program Change 4:  -
   Program Change 5:  -
     ...
   CC1: loop 1 output (0-100)
   CC2: -
   CC3: -

   PITCH: -

where of course we just don't store the empty areas in a bank.


WHY BANKS?

It corresponds to the needs of your average player, where you have
a limited selection of controls that you need to behave differently
for different songs.


ANY CHANGE CAN BE MADE FROM ANY COMMAND

Remember, your average guy has a few fairly limited control
sources so if he can only generate, say, program changes, then
he should be able to set all levels this way.

Banks should be able to handle any MIDI data if at all possible:
PC, CC, note-on/off, aftertouch, you name it.  Seems ridiculous
but you have to parse the MIDI stream anyway, it's very little
work to cover ALL the cases at the end.


WHAT SORT OF CHANGES ARE ALLOWED?

any list of the following changes:

   set                 state            to (value)
   set                 bank             to (value)
   set                 dial/switch      to (value)
   increment/decrement dial             by (value)
   toggle              switch           up/down        // loops 
through all possible values
   set                 dial             to (start:end) // maps a 
controller linearly
 


SUMMARY

A simple model of any MIDI machine is presented
where a user sends MIDI commands
to change the state of discrete switches and continuous dials.

At any time, the machine has a "state" of all its switches and dials.
The user can store and recall multiple states in memory.

The MIDI behaviour is controlled by a "bank" which maps MIDI commands
into state changes.



APPENDIX: SUGGESTIONS FOR ENHANCEMENT

Presets: There need to be some decent "preset banks" that expose the most
          common functions to MIDI and to the most common foot pedals in 
their
          initialized format.

This idea pays for the bank idea on its own, if it works "out of the box"
with "all" the foot pedals "out of the box".


The Bank Command:  There needs to be a command that goes off when you 
select a bank.
                    If the rest of this worked, that would take 10 
minutes to implement.


Default Bank: If you had a little extra time, you could have a "default 
bank"
               that would be searched if you didn't find the incoming 
command
               in the current bank.

Curves for dials: In the case of the "linear values" for the dial, it 
would be very
                   nice to have arithmetic maps that would let you remap an
                   incoming controller.
                   This sort of thing is very useful because things 
like "velocity"
                   or "breath control" (my favorite) are not linear in 
nature.

Rev 2.0:  In a later rev, once you had this structure, it might not 
be to hard to
           actually create some LFOs, envelopes, other free-running 
gizmos...
 


...electronic a capella madness  <http://volectrix.com>.........
...extreme internet radio        <http://extremeNY.com/radio>...