A couple of queries regarding the patch below.

1. Is it possible to have one folder "feeding" more than one buffer~? For instance, two or three extra groove~ objects which are using different samples from the same folder in the umenu drop down? One folder feeds many?

2. There's quite a few posts already on here regarding the de-clicking of groove~ loops but I haven't found anything explaining how to de-click when you are randomly jumping around inside the waveform~ window. Is there a way? If I've missed something obvious, would be grateful if someone could send me a link to the thread where this is covered.

1. Is it possible to have one folder "feeding" more than one buffer~?  For instance, two or three extra groove~ objects which are using different samples from the same folder in the umenu drop down?  One folder feeds many?

2. There's quite a few posts already on here regarding the de-clicking of groove~ loops but I haven't found anything explaining how to de-click when you are randomly jumping around inside the waveform~ window.  Is there a way?  If I've missed something obvious, would be grateful if someone could send me a link to the thread where this is covered.

groove-jumps-and-multiple-buffer-feeds

Here's a method using [cycle] of using the same [umenu] to load multiple [buffer~]s. It will automatically select the next buffer after each choice or you can use the number box. Obviously if you want more than three just add some more. To solve your clicking problem have a look at [grooveduck] which is an abstraction that fades the level out and back in again at loop points. This technique is what you want to be using.

Thanks! That multiple buffer load trick is great, never would have thought of it.

It may obviously be me doing something wrong, but so far I'm not convinced that grooveduck~ is the way to go here as it doesn't seem to make any difference to the clicking when I initially set a new loop point within waveform~

Once I've chosen one, grooveduck~ cleans up the looping nicely, but it's the initial thump I'm trying to get rid of.

Would an adsr~ or a trapezoid~ somewhere in the chain clean it up? If so, where should it go??

Thanks!  That multiple buffer load trick is great, never would have thought of it.

Once I've chosen one, grooveduck~ cleans up the looping nicely, but it's the initial thump I'm trying to get rid of.  

Would an adsr~ or a trapezoid~ somewhere in the chain clean it up?  If so, where should it go??

Try placing a [mousefilter] on the selection start and end outputs of [waverform~] (or packing them into a list and using only one) before sending it into the [grooveduck]. This will mean that the selection is only confirmed when you release the mouse rather than continously as you make a selection. You will also want to connect the selection select numbers to the fourth and fifth inlet of your [scale] object so that the playback line only covers the selected area.

Thanks for the mousefilter suggestion but doesn't seem to make any difference sadly. Appreciate the help though.

Thanks for the mousefilter suggestion but doesn't seem to make any difference sadly.  Appreciate the help though.


I have been struggling with this exact problem for a while, and have returned to it again.

I've managed to eliminate clicks, but not inexplicable silences that happen sometimes when select a new set of loop points.

The goal is to have a waveform as a mouse interface and a monome as a physical interface, to jump around inside a buffer, for playback with groove.

The problems, when the above is implemented the easy/obvious way, include:

C. Inexplicable silences, (some of which are explicable when the loop points are set such that the end point sets first and ends up earlier than the start point, but I also encounter some silences that are not obviously this problem.)

I have defeated 1 and 2 with these strategies:

A-1. Set the waveform~ to snap on zero crossovers; pass all loop points through waveform~ to sanitize them.

A-2. Use the grooveduck windowing strategy on the loop anyway.

B-1. Run two copies of Groove~. When loop points change, make the change on the one that's not currently supplying audio, then equal power crossfade to that one.

C-1. Use an additional "loop point sanitizer" which when new loop points arrive, checks them against the current loop points and then provides them to the groove~ like this:

C-1a. If the new End point is before the Current start point, send the new Start point first.

C-1b. Else, send the new End point then the new start point.

now, you'd think/hope that this would be enough, but it's currently not working for me and it's going to take hours to debug it or rebuild from scratch as a single simplest case patch that includes all of the pieces to eliminate the possibility that I'm messing something up by dividing parts of this into abstractions.

(I've gotten it to apparently work with the mouse but then when I set the loop points within the patch, it glitches out. then I experiment with the mouse some more and boom, it glitches or even crashes.)

I'm all ears if anyone has a better idea, in the mean time I'm going to carefully reconstruct all of this in one patch in the simplest design possible.

A. Clicks at loop points.
B. Clicks when changing loop points.
C. Inexplicable silences, (some of which are explicable when the loop points are set such that the end point sets first and ends up earlier than the start point, but I also encounter some silences that are not obviously this problem.)

A-1. Set the waveform~ to snap on zero crossovers; pass all loop points through waveform~ to sanitize them.
A-2. Use the grooveduck windowing strategy on the loop anyway.

C-1a. If the new End point is before the Current start point, send the new Start point first.
C-1b. Else, send the new End point then the new start point.

now, you'd think/hope that this would be enough, but it's currently not working for me and it's going to take hours to debug it or rebuild from scratch as a single simplest case patch that includes all of the pieces to eliminate  the possibility that I'm messing something up by dividing parts of this into abstractions.

I'm all ears if anyone has a better idea, in the mean time I'm going to carefully reconstruct all of this in one patch in the simplest design possible.


groove~ jumps and multiple buffer~ feeds