Re: EDP controller chart

[Jeff Larson <Jeffrey.Larson@Sun.COM>]

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