[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Date Index][
Thread Index][
Author Index]
Re: EDP controller chart
Sam Rogers wrote:
> Bernard -
>
> It seems that we should indeed form a party to chart this
> out. Anyone else who's interested, please chime in as well!
I don't claim to be an expert, but I've spent an unhealthy amount of
time thinking about EDP states, and would be happy to contribute to the
cause. I'm not sure if all EDP behavior nuances can be accurately
captured in a 2 dimensional table though. We can probably get close
but there will certainly be cells with footnotes.
To get things started, imagine a table with "modes" on the X axis and
"functions" on the Y axis. I think of the EDP as being in one of the
following modes:
Reset
Play
Record
Threshold (waiting for record threshold)
Overdub
Multiply
Insert
Stutter
Rehearse Play
Rehearse Record
Replace
Substitute
Mute
Switch Confirm
Switch Quantize
Synchronize (waiting for sync pulse)
Delay
Hold
Tempo Select
In addition there are what I call "minor modes" that can be combined
with the major modes.
Overdub Enable
Reverse
Half Speed
Stop Sync
Stop Sync is relatively esoteric and since it doesn't affect the
semantics of the other modes we don't really need to consider it.
Overdub Enable is interesting because it represents a "pending" or
"armed" mode. If you were in Overdub before you entered Insert, you
leave Overdub during Insert, but return to Overdub when the Insert
ends. It is difficult to express this in a 2D table, at the
intersection of Insert/Insert you would have to say in effect "return
to Play if Overdub Enable is not on, else return to Overdub" or more
concisely "Play/Overdub". Since this will happen a lot, you could
simplify it by footnoting the table to say that "Play" implies Play or
Overdub depending on the setting of the Overdub Enable mode.
Reverse and Half Speed are different than Overdub Enable because they
are active when combined with the other modes. For example you can be
in Play+Reverse, or Multiply+Reverse+Half Speed. If we were to
consider these distinct modes, we have a combinatorial explosion, a
fancy term for gobs of modes along the X axis. Most of these
combo-modes are uninteresting because the behavior will be the same
whether the minor modes are on or off. But there are a few cases
where this does matter. That's one reason why I'm wondering if a
single table is enough.
Then there are parameters. InsertMode and InterfaceMode both affect
the behavior of some functions. I think we can simplify this by using
only DirectMIDI functions except for the very few cases where a MIDI
initiated function differs from a front panel function. In other
words, we don't need a column for "Insert, InsertMode=Replace", just
use "Replace".
Parameters like MuteMode and SamplerStyle are more challenging.
SamplerStyle=Once especially is almost like another mode, the "waiting
to return to previous loop" mode.
Quantize is interesting. What happens when you try to "stack" more
than one function for future execution. Do they cancel each other?
Are they performed on successive quantization boundaries? I honestly
don't know. The documentation is clear on the behavior of some
quantized SUS functions, but not everything.
Oh yes, SUS functions! In most cases the up/down transitions of a SUS
function can be treated as if they were separate presses of the
non-SUS function. But in a few cases the timing of the up transition
is significant (such as with SUSNextLoop) and would need to be a
column in the table.
Hmm, long presses. My brain hurts.
Well, that's all I have time for now. I think this is a really
interesting and useful exercise. My fear though is that we're going
to end up with a 500 x 500 table with 100 footnotes :-)
Jeff