Support
Looper's Delight
|
Support |
|
|
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>... >