Forums > MaxMSP

Clips. clips, clips again


ulodin
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.

WHY?!

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?

Thanks!


brendan mccloskey
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)

HTH

Brendan


ulodin
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!


brendan mccloskey
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,
Brendan

http://cycling74.com/forums/topic.php?id=28351


brendan mccloskey
September 22, 2010 | 12:32 pm

ps
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

cheers
Brendan


ulodin
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!


Chris Muir
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.


ulodin
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?

Thanks!


Phantasmeano
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.


Phantasmeano
September 23, 2010 | 9:04 am

there is also grooveduck, readymade, ready working


ulodin
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!! :)


ulodin
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.

Thanks!

patch code:

– Pasted Max Patch, click to expand. –

[attachment=142392,1171]

Attachments:
  1. patch.tiff
Viewing 12 posts - 1 through 12 (of 12 total)