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

["Michael LaMeyer" <mlameyer@rcn.com>]

Far out, nice conceptual outline.  I've been thinking of making a foray 
into
programming and the most interesting (and accessible for me) possiblity
would be midi control programming.  I'd like to write a simple usable midi
loop sequencer.  We'll see.  I appreciate the thoughts though.

Mike

----- Original Message -----
From: "Tom Ritchford" <tom@swirly.com>
To: <Loopers-Delight@loopers-delight.com>
Cc: "Damon Langlois ( Electrix )" <Damon@Electrixpro.com>
Sent: Friday, August 25, 2000 5:35 PM
Subject: (LONG) MIDI control (for loopers and other devices)


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