] [Thread Prev
Re: Andre's EDP Undo trick
At 01:32 AM 6/9/98 -0700, Andre LaFosse wrote:
>Now HERE'S the intriguing part:
>5) Once you've got a short cycle or two with a fragment of the longer
>loop, hit UNDO. Each successive press of UNDO causes a different
>cycle-length fragment of the previous, longer loop to emerge. Pressing
>UNDO repeatedly morphs this small cycle through all sorts of mutations
>of the original longer loop.
>I discovered this along with another Echoplex user a few months ago, and
>we were suitably intrigued by the effect.
uhhhhh, yeah, we meant for it to do that! It's a feature!
Actually, what you've found appears to be some crazy sequence of possible
operations that we somehow didn't think all the way through, so it does
something a bit unpredictable. Fortunately there are far fewer of these
there used to be! If you had noticed it a year ago while you were beta
testing this release, Andre, probably it wouldn't do this. :-) But since
like it this way, maybe it's best left alone.
>My question for Kim, then, is: Can you describe (in layman's terms, a la
>that great train analogy with which you enacted your mosr recent round
>of Andre Damage Control) what's going in the unit when this phenomenon
I'll skip the train analogies this time....
When you've taken a loop and done all sorts of multiplies and inserts on it
to make a more complex loop with many cycles, the echoplex is keeping track
of all these different fragments in memory. It makes the loop by churning
through them in the right order, and it has to do a lot to keep track of
everything. When you do overdubs, it saves this altered version in new
memory and preserves the old version, further complicating all the audio
fragments the poor echoplex has to remember. (we actually have
defragmentation routines going behind the scenes to keep this under
control.) If you chop the loop down to some smaller subset of cycles, the
echoplex just changes the set of cycles that it jumps through to make the
loop. The other stuff is all still there in memory, just unused.
For Undo to work, we have to keep track of not just the current loop, but
all available previous versions of it that you may wish to undo back to. So
while we're doing all the other stuff, we are also tracking the past. In
other words, it's a big hairy complicated mess. Getting it all to work
was a complete agony. (mostly experienced by Matthias since he had to deal
with all the assembly code...)
Undo works by jumping back to the previous section of memory that was being
used before you made the last change to the loop. Each time you press it,
jump back to a previous section of memory that we have kept track of, and
play that instead. So whatever changes you had made are "undone", and the
loop is back the way it was before the change.
Typically with Undo, we don't allow it to undo past a point where multiply
or insert was done. We assume that the user probably doesn't really mean to
do that, since it would unexpectedly change the length of their loop, so
Undo is supposed to stop at the point where the multiply was done. Except
for the case you just found, that's what it does.
So what undo should do for you here is stay on the chopped out section of
loop, and not jump back past it. It looks like you've discovered a
combination of actions that screws up Undo, so that it loses track of where
the last multiply happened. So rather than refusing to let you Undo again,
it just goes ahead and lets you. It keeps this loop at the same number of
cycles, of the same cycle length. So you jump back to some unpredictable
spot, but with the loop length and cycle structure maintained. The audio
that happens to be there is left over from some previous loop operations,
and that's what you hear.
So, I'm happy that for once you found an obscure bug that you like, rather
than calling in the army! :-) And only the second bug found LoopIII v5.0,
with Claude getting the first one a few weeks ago. So I guess the question
is, do you want us to fix it or not?