"Lazy Susan" Approach to Loop Staggering?

alexs1

I've been theorizing about using functions like "Slip" and "Move" on the fly, and the best analogy I can think of for this technique is a Lazy Susan. While performing, I want to be able to "rearrange the platter" while it's spinning, so to speak. For example, if I have a drumbeat where the kick lands on the downbeat of beat 1, I could slip or move(?) the Cheetos and shift the entire rhythm one beat ahead (or behind), so that it's still aligned, the drumbeat becomes syncopated, and the rest of the snacks are now offset by one beat, yet still spinning at the same rate, if that makes sense. Bound to a trigger, each press would buffer the rhythm by one beat (in sync).

Any ideas? Would it be better to use Slip or Move in this case? And how could I keep it quantized/in sync while it's going?

jeff

Slip and Move do basically the same thing, they jump to a location within the loop. Slip came first and is more limited in where you can go, but also more controllable. I forget where it came from, it might have been a request, or just something I tossed in one day to see what would happen. There wasn't a lot of thought put into it. I think it worked like this...

There are three variants: Slip, SlipForward, SlipBackward. All three look at the Slip Mode parameter to determine the "unit" to move. The functions each allow an argument that is the number of units. Slip must have an argument, a positive (forward) or negative (backward) integer. SlipForward and SlipBackward accept an argument but if you don't pass one they assume 1 unit. The units in Slip Mode are:

  subcycle
  cycle
  start
  relativeSubcycle
  relativeCycle
  time

If you use units subcycle and cycle, it jumps forward or backward to subcycle/cycle boundaries. So SlipForward means jump to the next subcycle and SlipForward(2) means jump to the subcycle after the next, etc.

If you use relativeSubcycle and relativeCycle it jumps the length of one subcycle/cycle but relative to where you are at the moment. Example: the loop is 1000 samples long and there are 4 subcycles, each subcycle will be 250 samples long.
A relative jump just adds 250 to the current sample location. A non-relative jump will only go to 0, 250, 500, 750.

slipMode=start just jumps to the start and is effectively the same as the new Start function, arguments don't matter.

slipMode=time is the least useful, it treats the argument as a number of milliseconds. So if you found a compelling reason to jump to exactly millisecond 1234 of the loop you could do Slip(1234 slipMode=:time)

Move is actually more of an internal function that is used for several things including Realign. Here the argument is any sample location within the loop, but in order to use it for anything other than Move(0) you would need to be in a script and doing some math.

There is another relatively obscure function that you might find interesting Shuffle. This reorders the loop subcycles according to a few selectable patterns. If I remember right, Reverse means to make subcycles 1 2 3 4 be 4 3 2 1.
Shift would make 1 2 3 4 be 2 3 4 1 and you could apply that several times. Swap I believe worked in pairs so 1 2 3 4 would become 2 1 4 3. Random just moved them randomly.

Finally there once was a way to pass a "shuffle pattern" in as an argument. That was a string of numbers where you could define a pattern like "4 3 5 1 8 2 7 6" and it would scramble it that way. I think someone tried that a year or so ago and it was broken, so it probably still is.

Slip and Shuffle both obey Quantize. I don't think Move does because it is used for internal forced jumps.

alexs1

jeff

Ok so to get the pistachios where the cheetos are, it sounds like I’d want to look into a Shuffle + Shift.

The logic would go something like on each press, shift 1,2,3,4 once so it becomes 2,3,4,1 ; 3,4,1,2 ; 4,1,2,3 and finally back to 1,2,3,4, while retaining quantization.

Where could I find the parameter that adjusts the shift unit quantization in the UI? Does Shift quantization extend into external sync with b46?

Also, does Shuffle and Shift use the same scripting references from the old manual for MSL?

jeff

alexs1 If I remember right, the problem with script Shuffle was the talk about the shuffle pattern. The pattern was specified as a string with numbers separated by spaces "1 2 3 4" and the way MSL handles strings is quite a bit different and I think isn't being passed down to the old Shuffle code properly. Someone tried that about a year ago and it wasn't working.

Shuffle(shuffleMode=:shift) should work but I haven' tried it recently. Or just set Shuffle Mode to Shift and use Shuffle without arguments in the script. To shift with more than one unit at a time pass a number Shuffle(2)

After a quick glance, it looks like Shuffle may have been considered an "instant" function that didn't obey quantization. You can simulate quantization in a script with wait.

#name ShuffleAtEnd
wait loop
Shuffle

But that's kind of annoying, I'm not seeing a reason why this shouldn't pay attention to Quantize.

alexs1

jeff

Is there a way to change the Shift Mode Unit to Beat or is it always subcycles?

jeff

alexs1 It's always subcycles. When I finish quantization to internal beats (instead of sync beats) I can probably address shuffle units at the same time. You can change the subcycle count at any time, so depending on how you record the loop it can match where beats were in the host. But it takes a little planning.

alexs1

jeff

Cool. I could see getting some fun out of changing Shuffle Units to something like Host Beat or from subcycles to just cycles with internal sync