I use a large sample buffer (like 30 sec) and record phrases into it.
I have a clock input and a counter unit, so I can sync the sampling to a full bar length (like 4 or 8 clock beats).
Now I want to stop sampling at the end of a bar and start a sample playback. But first I want to slice the recorded bar into fractions, like 8 slices, and play them in random order. This way new melodies might form.
But how do I do the slicing of the recorded section only?
I use a large sample buffer (like 30 sec) and record phrases into it.
What is preventing you from accomplishing this in the slice editor?
I don’t want to do it manually. I have a foot pedal that switches from recording to playback, so the slicing should be fully automated based on the number of beats I defined before.
New slices can only be created in the slice editor at the moment. Perhaps you can pre-slice the buffer and record over the same (sliced) section each time?
Another option might be to not use slices, and instead built some construct that modulates the shift parameter of the sample player to select the “slice” of interest for playback.
Unfortunately this is not possible, because I need to be able to change the BPM on the fly, which changes the overall length of a beat and therefore the length of each slice.
Yeah, the buffer could be set to a bar at a known bpm and then sliced to divisions. Whatever sample is recorded over that buffer will then maintain those slices.
It could be ideal to have the bpm automatically detected or something, so that your loop would stay in time if the tempo is changed, but that’s a but much…
edit: whoops this now very redundant
But the shift parameter always relates to the whole sample length, and as I only use a part of it, which length depends on the clock speed and the beat count, this would not work. Or am I simply too bad in math…?
Yes, I want to sync the slices to a certain tempo and a certain time signature. But as far as I can see there is no solution for this with the current feature set.
Not sure. It works in my head but I haven’t actually tried it.
The shift parameter controls where the playback head will reset to when the sample player receives a gate, in seconds from the beginning of the sample. So you’d want a gain structure that relates to your “slice” length. You could set the gain on the subchain, or if you wanted to control it more dynamically you could probably put a VCA in the subchain and bring it’s value up to the top of a custom unit, e.g. slice length in sec.
Let’s assume you’re working at 120 BPM in 4/4 and you want to record two measures of quarter notes. Each slice is going to be 500ms, so if you set a gain on the shift param of 0.5, and modulated it (your source of random) using integer values, you would be resetting the playhead position to 0s, 0.5s, 1s, 1.5s, etc. with each gate (which might need a uDelay after it).
You’d obviously need to limit the range of the random there and only send values of 0-7. I would think you could set this up with some clever construct of noise, S&H, grid quantizer, and VCAs. The Pingable Scaled Random in Accents would probably save some work. Thinking you could also surface that parameter on the top level of a custom unit (max random value).
Thanks Joe, I was not aware that the shift parameter relates to the seconds from the beginning of the sample. I thought it was from 0-1 where 0 is start and 1 is the end, and everythign else is in between. With “seconds from start” this seems to be a way that could work in the end. Will try and report back later…
Keep in mind that the shift parameter is actually called Slice Shift. So it needs at least one slice to shift and the playback extent needs to be set to ‘slice’.
The wiki entry may need a tweak if this is the case (though it does disclaim that it’s out of date ). It seems to indicate it will work with an un-sliced sample.
As stated before, triggering this unit will cause the play head to reset back to the beginning of the sample or to the active slice. However, if the shift parameter is non-zero then the reset position of the play head will be shifted by a time interval equal to the shift parameter’s value. For example, if the shift parameter is 1.2s then a trigger will cause the play head to reset to 1.2s into the sample buffer, or in the case of a sliced sample, 1.2s after the active slice.
Happy to confirm the behavior and make the update if you like.
So, I did a quick test here, and may need a little bit of education about the shift control and maybe the slice polarity too. It is not behaving like I’d expect.
With no slices, shift seems to have no impact (gate resets to 0s in buffer, regardless of shift setting, as @odevices said)
With a slice in place, play extent = slice, as far as I can tell, it is resetting the playhead to the time specified by shift- but relative to the beginning of the buffer, rather than the current slice.
Depending on where the slice is positioned, and what the slice polarity is, sometimes the playhead will play back when a gate is fired, and sometimes it will just jump to that place, and stop. Sometimes it won’t move regardless of the value of shift. Sometimes it will only play back when shift = 0.
I’m actually pretty confused about this these controls now. Firmware 0.4.11.
The shift parameter is definitely acting weirdly. I’d stay away from it until I get a chance to overhaul it.
Gotcha, thanks for checking. My understanding of the slice polarity setting has always been marginal, so I thought I might have been misunderstanding how it affected the shift param.
Thanks for checking Brian & Joe. You prevented hours of head scratch for me. Hope you come back to the shift parameter quite soon and add some spice here that keeps my application in mind.
I’m wondering how you went with this.
I’m trying to build a simple but similar unit for on the fly sampling and slicing.
Basically set a bpm, record the buffer with punch in and out points in a looper.
Then in Varispeed player (reading the same buffer) slice into fractions using the punch in and out as total sample length, is there away to achieve this?
At the moment it loads the whole buffer.
I’ve only just got started with the 301 so please have mercy.
For Joe’s suggestion with variable BPM, perhaps you can utilize Pulse to Seconds?
So something like
Tap Tempo -> Pulse to Seconds -> VCA * Pingable Scaled Random -> shift.
This might not work as “on the fly” as you want, depending. You’d have to crossfade back to your dry signal before changing BPM and then re-record after you’ve done your BPM change and then fade back to the sample player. This is also with the caveat that you have to manually enter at least one slice.
Actually about that last bit and slightly off topic but it did come up regarding shift. I really hope that shift with 0 slices will work as offset from buffer start at some point, but as for current work around of inserting one slice, there is no way to set a slice at the beginning of a buffer. So to make this work would one just insert a slice at an arbitrary position and set play extend to “cue” and make sure to never put the slice parameter other than zero?