Support
Looper's Delight
|
Support |
|
|
At 01:32 AM 6/9/98 -0700, Andre LaFosse wrote: >Just kidding. damn! :-) >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 than 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 you 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 >occurs? 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 right 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, we 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? kim