-i made a few little changes to the patch... same question though...

i am quite the beginner, so i am very grateful for the support of this amazing resource! i'm pretty sure that my question is a little silly, but i could not find the answer anywhere (though if anyone else knows of a thread that i missed, please fill me in).

basically i am trying to overcome the clicking that my groove~ objects always seem to make (i AM a huge noob). i have been able to do so with specific files (of fixed duration), but i am trying to get the same results from a groove where the contents (and more importantly, length) of the buffer change.

is there any way to know when a groove~ is a given amount of time, let's say 50ms, away from the end of any number of different samples (of varying lengths)?

as seen below, i have tried to get this information (approximately) from the farthest right outlet of the groove~, but this approach seems inflexible and just plain wrong.

also, with a very short and loud sample, i was still getting a bit of a click at the end of some (but not all) playbacks. is there anything obvious in my patch that would yield this kind of "occasional" click?

EDIT:
-i made a few little changes to the patch... same question though...

i am quite the beginner, so i am very grateful for the support of this amazing resource!  i'm pretty sure that my question is a little silly, but i could not find the answer anywhere (though if anyone else knows of a thread that i missed, please fill me in).

basically i am trying to overcome the clicking that my groove~ objects always seem to make (i AM a huge noob).  i have been able to do so with specific files (of fixed duration), but i am trying to get the same results from a groove where the contents (and more importantly, length) of the buffer change.

also, with a very short and loud sample, i was still getting a bit of a click at the end of some (but not all) playbacks.  is there anything obvious in my patch that would yield this kind of "occasional" click?

thank you all so much in advance,
your help is greatly appreciated,
DFM

simple-groove-questions

Perhaps have a look at [grooveduck] and [grooveduck2] which are abstraction wrappers for the [groove~] object included with the standard distribution of max. They fade the signal in and out at the specified loop points.

if i give it a very big number for loop end,

it seems to take the whole file (whatever the length) automatically,

before the first poly~ has a chance to finish.

shouldn't the order that i have my line objects connected (in the clickless patcher) prevent that?

if i give it a very big number for loop end,
it seems to take the whole file (whatever the length) automatically,
which is what i was after.
i will add that in right away.

on a related note,
i tidied up the patch a little,
but i still get a click if:

i click on "start" four times quickly,
before the first poly~ has a chance to finish.
shouldn't the order that i have my line objects connected (in the clickless patcher) prevent that?

If you make sure your loop points are at zero-crossings in your buffer, you shouldn't have any clicks. There are ways to do this using the [waveform~] object (do a search or you can find one thread about this by looking at my past postings). There are also some 3rd party externals for detecting zero crossings (one in tap.buffer.snap~ comes to mind, but that is part of a pay collection--a good one though from some of the objects I have seen by using my demo period I started recently).

Similar to the [grooveduck] example, you could combine [groove~] with [trapezoid~] like this:

If you make sure your loop points are at zero-crossings in your buffer, you shouldn't have any clicks.  There are ways to do this using the [waveform~] object (do a search or you can find one thread about this by looking at my past postings).  There are also some 3rd party externals for detecting zero crossings (one in tap.buffer.snap~ comes to mind, but that is part of a pay collection--a good one though from some of the objects I have seen by using my demo period I started recently).

cool, thanks very much everyone!
i will look into these as well.

sounds like you've got it covered but just in case it helps, here's a detailed patch with explanations as to how to keep groove's sync outlet in the signal domain while using it to sync an envelope. In addition, I created this so that you can get an s-type curve as opposed to just the linear one that the original grooveduck does(more effective removal of clicks). added bonus is that the s-type curve is created in real-time as opposed to drawn into and then read from a buffer~(if you've never seen the buffer~ technique, check out the granular example in the examples folder here:

Max5/examples/sampling/granular/granularized.maxpat 

in that example investigate the rgrano.maxpat module in the 'lib' subfolder, click into edit mode and check out the

subpatcher; it may seem daunting at first but it's worth studying). anyways, hope this helps:

sounds like you've got it covered but just in case it helps, here's a detailed patch with explanations as to how to keep groove's sync outlet in the signal domain while using it to sync an envelope. In addition, I created this so that you can get an s-type curve as opposed to just the linear one that the original grooveduck does(more effective removal of clicks). added bonus is that the s-type curve is created in real-time as opposed to drawn into and then read from a buffer~(if you've never seen the buffer~ technique, check out the granular example in the examples folder here:
Max5/examples/sampling/granular/granularized.maxpat 
in that example investigate the rgrano.maxpat module in the 'lib' subfolder, click into edit mode and check out the 

 subpatcher; it may seem daunting at first but it's worth studying). anyways, hope this helps:

wow, 
thanks everybody!
lots to look into here,
i really appreciate all this help!

simple(?) groove~ question(s)