Cut buffer into X amount of slices and randomize (via groove~)
I'm trying to cut a buffer into a variable amount of slices (between 2 and, don't know, 256?) and randomize the order that they are played back in. It's a dynamically sized buffer currently being written using poke~.
Now I started to write something that took the total buffer size and divided it by however many steps I want, and that's giving me the step size. But then I got stuck in how to apply that to the loop start/end points. I want to make it so it slices the sample into equally sized pieces, which will change depending on total buffer size and/or slice amount.
Here is the patch as it stands (the dividing is happening in the bottom right)
Just a thought; have you looked at the helpfiles for [chucker~] and [stutter~]? Some good examples of how to randomise slices.
Brendan
And don't forget 2dwave~ ; see here for an example, which also incorporates part of Raja's patch from the post referenced above - https://cycling74.com/forums/its-ok-to-share-twinpusher
And in answer to your query about loopers, have a look at Stephen Schweitzer's Loopexp - http://soundexp.freeshell.org/loopexp/
It uses a couple of 3rd party objects, but it's nicely annotated, and the 3rd party objects can quite easily be replaced,
cheers
Roger
Chucker~ looks ideal, especially since it seems like you can just throw it right after groove (so the rest of my patch can stay put). It only goes up to 64steps though, which is a bummer.
The twinpusher patch looks(and sounds) great but it's massive overkill for what I'm trying to do here. Not to mention peeking inside it isn't terribly obvious (to me) what's happening. That one does seem to be able to cut it up into many more than 64 steps.
All of the patches linked, as far as I could tell, just let you determine what order to play the slices via the multislider. How would one go about cutting it into however many slices (either via chucker or 2dwave(I believe that's what's at play in the last patch?)) then shuffle the order those play in, randomly.
you need to look into roger's twinpusher patch some more. it can do all that. if memory serves me correct it is based on the "ModSquad" patch in the Max Examples - you should look at that too, as it 'reorders' the actual phasor~ to drive the wave~ with a clever ramping-per-step feature (again, from memory, i have not looked at it in a while). the advantage of this over chucker~ is that there is nothing to 'buffer' first - chucker~ is designed for live audio throughput so it needs a buffer of data through it before it 'chucks'. of course the problem with wave~ and 2d.wave~ is they sound pretty bad, whereas the chucker~ audio quality is better, and because maths is internal it is much more efficient. i guess it all depends on your uses. i tend to drive a techno~ and a play~ with the same phasor~ (actually hr.phasor~ via a rate~) and then play~ into chucker~ and drive the chucker~ with techo~ (via /~ steps of course), that way you can implement envelopes and other ideas on a per-step basis, use 'repeatpos' to techno~ to play steps out of regular time, and all at sample accurate rate. lots of experimenting to do. good luck.
There's tons I don't understand here, for certain, but in looking at twinpusher, as well as modsquad both seem to be built around changing the order of the slice, into a repeatable/preset manner. Which isn't what I want at all.
More simply, I want to break a buffer into say 16 slices, then randomly play any one of the 16 slices, in a non repeating/resetting manner (say a random 16 in this case driving it). And have that be a number between 2 and 256 (or higher) but it functions the same way. I'm sure this is possible with any one of the patches there but none of them have that feature/setting (slice amount + randomize).
Ok so I figured out by chaining uzi, random and zl group I can generate a random list which I can feed chucker~
This is working fine and dandy barring a few quirks.
First I can't get it to start the slicing to change right away. If I have slices set to 1, then crank it to 64, it waits until the loop is done playing before changing the slice amounts. It would be nice if this were to happen in real-time.
Second, is it possible to resize the chucker buffer? If I load something big, then something small, I get little slices of what was there before.
Lastly, chucker only goes up to 64 slices...
I took a look at modsquad again and as far as I can tell there are 16 steps there, period, as that's what's loaded into its table/buffer.
Twinpusher, on the otherhand, feels like using a sledgehammer to swat a fly. More specifically, it's way beyond my understanding in terms of "pulling out" the bit of code that slices into X amount.
Here's my patch with chucker doing random steps with the above mentioned problem.
Any help would be appreciated.
a lot of the chucker~ functionality you mention is just what chucker~ does, unfortunately. time and place i guess. anyway, fwiw, i pasted some suggestions to your patch at the bottom of my post.
the modsquad can be developed to be different step lengths very easily. however, the problem with it is that the clever step-ramping feature requires multiples of a certain size (if i remember correctly). i once remade this system for myself that allowed indeterminate step numbers that relied on some dodgy 'overflow' and 'rounding' system. i'll try and dig it out for you if you want.
good luck.
Thanks a lot for that. The guts of your object are so much more complex than mine! It's great seeing stuff like that and trying to make sense of it, so thanks for that (and all the comments).
The 64 steps and not slicing until the end of the loop are a bit of a deal breaker for chucker though I think. More the latter than the former as 64 is a lot of slices.
I'd love to see your modsquad-based patch if you can find it. I suppose I'm not married to odd number slices, as it will all be randomly cut up anyways.
Here's another slant on it with probabilities for reverse and mute and an auto scramble feature
one thing about chucker though, when changing the no. of steps i get the original sample 'unchucked' - any thoughts on how to get round this?