Support
Looper's Delight
|
Support |
|
|
At 3:21 PM -0800 3/8/01, Matthias Grob wrote: >Mark: >>A request for the long fabled update to the EDP software: > >Nice suggestions, thank you. >You seem to think rather Quantized. We want the liberty to press any >function at any time and it should do it immediately (although we >also offer quantized). > >>Could we have an option to change short press undo while in playback >>(rather than record or overdub) to mean undo back to before the last >>operation/redo the operation? > >So in Overdub the function would be what we have now? While in overdub, undo should cancel out of the overdub and take things back to where they were before overdub was pressed. That's what the manual indicates it does though your comments below indicate otherwise. >In Play it would for example go back to before the last Overdub was >started? Yes. >The long press function cannot be totally different because we start >the action before the long time is reached. As a programmer, I agree that I hate having to do things differently based on how long one presses a button. You can always take the action at button up time rather than button down with the downside that it now feels like there's a lag. > >>I suspect that part of the confusion over >>undo on the EDP that comes up on this list (or at least part of my >>confusion at times when using it) is the trim the last layer behavior. > >I dont quite understand... trim? According to the manual, a short press means undo the topmost layer from the time of the press until the cycle point. In other words, trim off the end of the topmost layer. > >>Reading the manual, it suggests that when we run out of memory, if at >>all possible the pre-operation loop is preserved. In other words, if we >>have room for 3 loops in memory and we start with A and layer B followed >by >>C followed by D in a single overdub, then memory ends up holding A, >A+B+C, >>and A+B+C+D. Is this correct? If not, could there be an option to provide >>this behavior? We've obviously got to toss something out, and it would >seem >>better to toss A+B rather than A. > >due to the delay structure we use, all overdubed versions follow each >other in memory. So what you suggest is that we keep A separately >while running through the rest of the memory, so A can be called back. >This somehow fits to he new UNDO function you suggest above. We could >save a previous version of the loop (not necessarily the very first >nor before the last function) and come back to it later. >Then again, thats what NextLoop is good for: >Work with LoopCopy=Snd or NextMultiply and 2 loops. Thus you can also >Redo. > >To fascilitate this, I could make longUndo (if MoreLoops >1) switch >to the previous loop and erase the next, so next time you press Next, >LoopCopy=Snd causes a new copy. I could certainly see something based around multiple loops as a way to do this. Here's what I'm trying to do: Start an overdub (or multiply) by hitting the appropriate single button. If I know in the midst of what I'm doing that I don't like it, undo should cancel me out and take me back to where things were before I started the operation. If after I've completed the operation, I don't like it, I'd still like to be able to go back to before I started the operation. It would also be interesting to be able to flip back and forth to compare the two versions. Undoing a single loop's worth of overdubbing or removing a gratuitous multiply cycle would also be nice but I view them as gravy. I haven't figured out a case for when I'd want to just chop off the end of an overdbub. Do you have any good examples of when this is useful? In any event, if doing this required using two loops, I could cope with that provided that it didn't mean that I had to trigger a lot of operations with a combination of next and the operation switch. On the other hand, if done within a loop, then the next loop functionality becomes another level of checkpointing on top of things. Mark