Forums > MaxMSP

Clips. clips, clips again

September 22, 2010 | 10:34 am

Hi all,

i’ve figure out that my big deal is envelopes.
For instance, if you guys have patience to look at the attached patch, i paid big attention hooking up objects due to avoid every audio truncation.

Despite that, when the last line~ at the bottom right (the one who SHOULD produce level envelope) receives values above 70-80ms about, clips are listenable.


Where is the problem?!

Here is the patch:

— Pasted Max Patch, click to expand. —

Two lines generate start/end loop point for the groove~ at the button. I’ve placed a line~ that takes the difference between end and strat point, divide the resault by 2 and give that number to the last line~, with the form [0., 1. $1 0. $1]

This should prevent every possible truncation, isn’t it?


September 22, 2010 | 11:16 am

I can’t look at your patch just yet, but have you used the [trapezoid] object? This will generate a nice trapezoid envelope derived from the [groove~] objects’ sync outlet, similar to your (0., 1. $1 0. $1)



September 22, 2010 | 12:11 pm

Hi Brendan,

yes; trapezoid~ seems to work just fine.
And thanks to that i’m figuring out that the problem could be in the transitioning period from initial start/end loop point to next ones:

when the lines~ who control those points finish their course, the trapezoid~ (set with 0.1 and 0.9) give out the correct envelope (no clips).
The problem seems to be during lines~ course: it’s continuous change of start/end loop points that seems to generate clips; seems like trapezoid~ can’t "catch" those changes…

could be possible?

Brendan, when you have time and if you will be so kind to open my patch and take a quick look of it i’ll be veeeery glad!!

thanks again!

September 22, 2010 | 12:19 pm

In the meantime, have a look at the following thread; a wild guess suggests it might be related to your issue: control-rate versus signal-rate envelope generation,

September 22, 2010 | 12:32 pm

I’m looking at your patch now, but find it difficult to ‘second guess’ your thought processes and expectations of the patch; if you could provide an annotated version (describe with comments what you want each particular part to do) that would certainly speed things up for both of us


September 23, 2010 | 12:27 am

Hi Brendan,

i’ve done the task; i’ve added comments into the patch.

Here is the resaults:

— Pasted Max Patch, click to expand. —

I’ve looked to your topic suggest and it’s surely interesting. In the closed feuture i’ll surely replicate that signal flow in a blank patch and test the behavior, because i love granulation sounds and i would want to manage every related technics; but i also wonder where i wrong in this patch!! :)

thanks again Brendan!

September 23, 2010 | 2:46 am

I think your problem might be that you are always starting your [line~] envelopes from 0 with no ramp time.

September 23, 2010 | 8:05 am

Hi Chris,

in order to have no audio clips i have to start my envelope from 0. and finish it at 0. too, am i wrong? In the case of line~, to me, the important issue should be that metro rate at the top of the patch does not have to excide the overall duration of the envelope, generated from the line~

For instance: if metro gives me an output of 100, the line~ has to generate a maximum of 0. 1. 50 0. 50; due to not allow metro to start a new task before waveform reach the zero crossing.

To you is this wrong?

Anyway, i’ve replaced line~ with a trapezoid~ driven by Sync Out outlet of groove~, that seems to be much accured than line~ use; or not?


September 23, 2010 | 9:04 am

mmm I would suggest using 2 voices and alternating the playback, poly is very helpful here too.

have a look at the example patch ADSR in he example folders.
I actually am unhappy with ADSR, but it could help you figure out a way to avoid clicks.
Also you could use a custom wave loaded in a buffer, read by cycle~ and moved in phase by grroove.
Though when you start again, you need to go back to 0, this is why you´ll need another groove starting playback at the new 0 point, and let the other one finish it´s run.

September 23, 2010 | 9:04 am

there is also grooveduck, readymade, ready working

September 23, 2010 | 9:42 am

Hi Phantasmeano,

yes, the example patch seems the solution…i forgot that example….

i’d want to fix all problems in mine, without using copy&paste solutions!! :)

September 25, 2010 | 10:02 am

Here i am guys,

i've implemented the grooveduck.maxpat section wich controls the overall level envelope in my patch.

In the post there is a pic and the patch code both.

The listenable resault is quite the same as using a [trapezoid~] driven by Sync Out of the [groove~]. In the attached patch i've closed the grooveduck part into a colored comment. I really don't understand its behavior….

[clip~] object constrains a signal between two values, ok; so why are there 2 [clip~] objects?

Please someone can give a little explanation of objects closed in the blue box?

I'd really appreciate your help.


patch code:

— Pasted Max Patch, click to expand. —


  1. patch.tiff


Viewing 12 posts - 1 through 12 (of 12 total)

Forums > MaxMSP