Poly~ groove~ headache

Jan 4, 2007 at 8:51pm

Poly~ groove~ headache

Hi

I am trying to create a simple poly~ patch that reads from a long (10min) audio file, and randomly plays short (5secs) sections at 1sec intervals, thus creating a multi-layered polyphonic sound.
I am finding it very frustarting to get anything working properly. I am using poly~ but am have problems when sending random “setloop” points to groove~ in each voice.
I have included the patch and subpatcher below. Just copy and select “new from clipboard”
I realise this is very simple, but it is driving me mad!
Any help (entirely rewritten patch;-) would be much appreciated.
I hope this is clear.
Thanks
David

Parent patcher

max v2;
#N vpatcher 465 100 1088 549;
#P window setfont Monaco 12.;
#P flonum 478 168 83 12 0 0 0 4 0 0 0 221 221 221 222 222 222 0 0 0;
#P window setfont “Fixedwidth Serif” 9.;
#P number 79 176 35 9 0 0 0 22 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P message 79 197 50 1441801 open $1;
#P window setfont Monaco 9.;
#P newex 458 340 66 262153 adsr~;
#P comment 450 265 91 262153 FUTURE STUFF;
#P comment 517 305 16 262153 R;
#P comment 496 305 16 262153 S;
#P comment 475 305 16 262153 D;
#P user dial 518 283 19 19 128 1 0 0 159 270 1 1. 170 170 170 221 221 221 120 120 120 225 225 225 0 0 0 0 0 0;
#P user dial 496 283 19 19 128 1 0 0 159 270 1 1. 170 170 170 221 221 221 120 120 120 225 225 225 0 0 0 0 0 0;
#P user dial 474 283 19 19 128 1 0 0 159 270 1 1. 170 170 170 221 221 221 120 120 120 225 225 225 0 0 0 0 0 0;
#P user dial 452 283 19 19 128 1 0 0 159 270 1 1. 170 170 170 221 221 221 120 120 120 225 225 225 0 0 0 0 0 0;
#P flonum 355 189 113 9 0 0 0 4 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 355 168 46 262153 random;
#P button 438 92 15 0;
#P flonum 397 142 92 9 0 0 0 4 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 319 115 105 262153 info~ david;
#P message 319 69 52 262153 replace;
#P newex 319 86 101 262153 buffer~ david;
#P user ezdac~ 145 344 189 377 0;
#P user gain~ 145 266 42 38 158 0 1.071519 7.94321 10.;
#P newex 145 240 94 262153 poly~ time2~ 8;
#P message 225 194 64 262153 target $1;
#N counter 1 8;
#X flags 0 0;
#P newobj 225 172 76 262153 counter 1 8;
#P toggle 145 102 15 0;
#P newex 145 121 64 262153 metro 250;
#P comment 454 305 16 262153 A;
#P user panel 440 260 107 75;
#X brgb 191 191 191;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P connect 26 0 25 0;
#P connect 3 0 2 0;
#P connect 2 0 6 0;
#P fasten 5 0 6 0 230 217 150 217;
#P connect 25 0 6 0;
#P connect 6 0 7 0;
#P connect 7 0 8 0;
#P fasten 7 0 8 1 150 333 184 333;
#P fasten 2 0 4 0 150 163 230 163;
#P connect 4 0 5 0;
#P fasten 15 0 6 1 360 224 234 224;
#P connect 10 0 9 0;
#P connect 9 1 11 0;
#P fasten 2 0 14 0 150 146 360 146;
#P connect 14 0 15 0;
#P connect 12 0 14 1;
#P connect 11 6 12 0;
#P fasten 13 0 12 0 443 137 402 137;
#P fasten 11 0 27 0 324 158 483 158;
#P pop;

Subpatch name it “time2~”

max v2;
#N vpatcher 646 279 1246 679;
#P toggle 80 141 15 0;
#P window setfont Monaco 9.;
#P window linecount 1;
#P newex 80 112 52 262153 t b b b;
#P newex 80 194 38 262153 sig~;
#P newex 367 213 40 262153 line~;
#P message 367 193 148 262153 0 , 1 1000 1 3000 0 1000;
#P newex 108 246 64 262153 thispoly~;
#P newex 80 319 131 262153 *~;
#N out~ 1;
#P newobj 80 353 46 262153 out~ 1;
#P flonum 142 103 60 9 0 0 0 4 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 186 127 52 262153 + 5000.;
#P message 142 193 159 262153 setloop 2.31 5002.31;
#P newex 142 172 76 262153 prepend set;
#P newex 142 152 136 262153 sprintf setloop %f %f;
#P newex 80 282 115 262153 groove~ david 2;
#N in 2;
#P newobj 142 80 38 262153 in 2;
#N in 1;
#P newobj 80 80 34 262153 in 1;
#P window setfont Monaco 12.;
#P window linecount 5;
#P comment 364 107 100 262156 tidy up the ADSR so it relates to sample play length;
#P connect 1 0 15 0;
#P connect 15 0 16 0;
#P connect 16 0 14 0;
#P connect 14 0 3 0;
#P fasten 6 0 3 0 147 221 85 221;
#P connect 3 0 10 0;
#P fasten 3 1 10 0 137 312 85 312;
#P connect 10 0 9 0;
#P fasten 14 0 11 0 85 236 113 236;
#P connect 2 0 8 0;
#P connect 8 0 4 0;
#P connect 4 0 5 0;
#P connect 5 0 6 0;
#P fasten 8 0 7 0 147 120 191 120;
#P fasten 13 0 10 1 372 265 206 265;
#P fasten 7 0 4 1 191 147 273 147;
#P connect 15 1 12 0;
#P connect 12 0 13 0;
#P pop;

#29503
Jan 4, 2007 at 9:19pm

#92369
Jan 4, 2007 at 9:38pm

On 04 Jan 2007, at 21:51, David Atkinson wrote:

>
> Hi

hi
there are a few problems with your patch… ;)
you should have another look at how to use groove~
also check out what prepend set does to a message box
and polyphony management is taken care for you by the poly~ object.
no need for setting the target manually in this case.
see if the attatched files help you.
volker.

/* save as time22 */

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#N out 1;
#P newobj 367 307 33 196617 out 1;
#P window setfont Monaco 9.;
#P newex 154 67 40 262153 t b f;
#P newex 39 202 46 262153 sig~ 1;
#P newex 367 231 40 262153 line~;
#P message 367 174 148 262153 0 , 1 1000 1 3000 0 1000;
#P newex 367 282 64 262153 thispoly~;
#P newex 80 319 131 262153 *~;
#N out~ 1;
#P newobj 80 353 46 262153 out~ 1;
#P newex 80 282 115 262153 groove~ david 2;
#N in 1;
#P newobj 154 43 34 262153 in 1;
#P window setfont Monaco 12.;
#P window linecount 5;
#P comment 437 43 100 262156 tidy up the ADSR so it relates to sample
play length;
#P connect 5 0 10 0;
#P fasten 7 0 4 1 372 265 206 265;
#P connect 7 0 5 0;
#P connect 9 0 6 0;
#P connect 9 0 5 0;
#P connect 6 0 7 0;
#P connect 1 0 9 0;
#P connect 4 0 3 0;
#P connect 2 0 4 0;
#P fasten 2 1 4 0 137 312 85 312;
#P connect 8 0 2 0;
#P connect 9 1 2 0;
#P window clipboard copycount 11;

/* main patch */

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 397 165 45 196617 – 5000.;
#P newex 145 213 67 196617 prepend note;
#P number 235 263 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 199 83 41 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window setfont “Fixedwidth Serif” 9.;
#P number 79 176 35 9 0 0 0 22 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 79 197 50 1441801 open $1;
#P window setfont Monaco 9.;
#P flonum 145 189 78 9 0 0 0 4 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 145 168 46 262153 random;
#P button 438 92 15 0;
#P flonum 397 142 92 9 0 0 0 4 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 319 115 105 262153 info~ david;
#P message 319 69 52 262153 replace;
#P newex 319 86 101 262153 buffer~ david;
#P user ezdac~ 145 386 189 419 0;
#P user gain~ 145 281 34 59 158 0 1.071519 7.94321 10.;
#P newex 145 240 100 262153 poly~ time22 20;
#P toggle 145 82 15 0;
#P newex 145 115 64 262153 metro 250;
#P connect 13 0 12 0;
#P connect 1 0 0 0;
#P connect 0 0 10 0;
#P connect 10 0 11 0;
#P connect 11 0 16 0;
#P connect 16 0 2 0;
#P connect 12 0 2 0;
#P connect 2 0 3 0;
#P connect 3 0 4 0;
#P fasten 3 0 4 1 150 375 184 375;
#P connect 17 0 10 1;
#P connect 14 0 0 1;
#P connect 2 1 15 0;
#P connect 6 0 5 0;
#P connect 5 1 7 0;
#P fasten 9 0 8 0 443 137 402 137;
#P connect 7 6 8 0;
#P connect 8 0 17 0;
#P window clipboard copycount 18;

#92370
Jan 4, 2007 at 11:13pm

Hi Volker
Thanks so much for the patch. It is doing exactly what I intended. I’m apologise for my original patch being in such a bad state. I find using the poly~ object with sample players very frustrating.
A few questions if you can spare the time.
Am I right in assuming in your patch, poly~ is looking after voice muting?
What is “prepend note” communicating with?
Also, would it be best to use ADSR~ to set different envelopes for each voice from the main patch?
Kind regards
A very grateful
David

On 04 Jan 2007, at 21:51, David Atkinson wrote:

>
> Hi

hi
there are a few problems with your patch… ;)
you should have another look at how to use groove~
also check out what prepend set does to a message box
and polyphony management is taken care for you by the poly~ object.
no need for setting the target manually in this case.
see if the attatched files help you.
volker.

/* save as time22 */

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#N out 1;
#P newobj 367 307 33 196617 out 1;
#P window setfont Monaco 9.;
#P newex 154 67 40 262153 t b f;
#P newex 39 202 46 262153 sig~ 1;
#P newex 367 231 40 262153 line~;
#P message 367 174 148 262153 0 , 1 1000 1 3000 0 1000;
#P newex 367 282 64 262153 thispoly~;
#P newex 80 319 131 262153 *~;
#N out~ 1;
#P newobj 80 353 46 262153 out~ 1;
#P newex 80 282 115 262153 groove~ david 2;
#N in 1;
#P newobj 154 43 34 262153 in 1;
#P window setfont Monaco 12.;
#P window linecount 5;
#P comment 437 43 100 262156 tidy up the ADSR so it relates to sample
play length;
#P connect 5 0 10 0;
#P fasten 7 0 4 1 372 265 206 265;
#P connect 7 0 5 0;
#P connect 9 0 6 0;
#P connect 9 0 5 0;
#P connect 6 0 7 0;
#P connect 1 0 9 0;
#P connect 4 0 3 0;
#P connect 2 0 4 0;
#P fasten 2 1 4 0 137 312 85 312;
#P connect 8 0 2 0;
#P connect 9 1 2 0;
#P window clipboard copycount 11;

/* main patch */

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 397 165 45 196617 – 5000.;
#P newex 145 213 67 196617 prepend note;
#P number 235 263 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 199 83 41 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window setfont “Fixedwidth Serif” 9.;
#P number 79 176 35 9 0 0 0 22 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 79 197 50 1441801 open $1;
#P window setfont Monaco 9.;
#P flonum 145 189 78 9 0 0 0 4 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 145 168 46 262153 random;
#P button 438 92 15 0;
#P flonum 397 142 92 9 0 0 0 4 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 319 115 105 262153 info~ david;
#P message 319 69 52 262153 replace;
#P newex 319 86 101 262153 buffer~ david;
#P user ezdac~ 145 386 189 419 0;
#P user gain~ 145 281 34 59 158 0 1.071519 7.94321 10.;
#P newex 145 240 100 262153 poly~ time22 20;
#P toggle 145 82 15 0;
#P newex 145 115 64 262153 metro 250;
#P connect 13 0 12 0;
#P connect 1 0 0 0;
#P connect 0 0 10 0;
#P connect 10 0 11 0;
#P connect 11 0 16 0;
#P connect 16 0 2 0;
#P connect 12 0 2 0;
#P connect 2 0 3 0;
#P connect 3 0 4 0;
#P fasten 3 0 4 1 150 375 184 375;
#P connect 17 0 10 1;
#P connect 14 0 0 1;
#P connect 2 1 15 0;
#P connect 6 0 5 0;
#P connect 5 1 7 0;
#P fasten 9 0 8 0 443 137 402 137;
#P connect 7 6 8 0;
#P connect 8 0 17 0;
#P window clipboard copycount 18;

#92371
Jan 4, 2007 at 11:47pm

On 05 Jan 2007, at 00:13, David Atkinson wrote:

> A few questions if you can spare the time.
’tis near bedtime overhere zzzz
> Am I right in assuming in your patch, poly~ is looking after voice
> muting?
nope, you have to manage that yourself. poly~.help will help you to
find out how to do it.

> What is “prepend note” communicating with?
well, with poly~ ;) again poly~.help has the answers.
with “note” or “midinote” messages poly~ will automatically manage
polyphony.
while you can append more or less anything to a “note” message,
“midinote” assumes you want to send midi note data, i.e. pitch and
velocity pairs.

> Also, would it be best to use ADSR~ to set different envelopes for
> each voice from the main patch?
you can use adsr~, but in your case i would rather stick with line~.
i find that adsr~ is a little cpu hungry.
and since you are not dealing with ‘conventional’ noteon/off data, i
doubt that it will be much easier to use in your patch.
bonne nuit.
volker.

#92372
Jan 8, 2007 at 1:24am

Hi, volker,

I found your patches very interesting but cannot understand the relationship among trapezoid~, phasor~, sah~. Could you explain a little bit about what you did in these patches, especially the first one ?

Thank you very much.

PS: I love the result of the last one, too. Very cool. I hope I can learn about how you did it.

Best,
Chien-Wen

#92373
Jan 8, 2007 at 3:23pm

hi chien-wen,

> I found your patches very interesting but cannot understand the
> relationship among trapezoid~, phasor~, sah~. Could you explain a
> little bit about what you did in these patches, especially the
> first one ?

i guess you are refering here to the patches i sent in the
crossfading loop thread?
http://www.cycling74.com/forums/index.php?
t=msg&th=23747&start=0&rid=0&S=46b0543e4c642afe4aefa7ee39531db8

the question was how to loop a certain amount of a soundfile without
having clicks at the loop points.
if you select an arbitrary part of a soundfile for playback/loop you
will most likely get a discontinuity in the sample flow, cause the
beginning of the selection doesn’t fit perfectly to the end
(litterally you make a jump backwards in time). this will be audible
as a click, which in some cases is not desirable.
to avoid this, one can make the ends meet by a fade in at the
beginning and a fade out at the end of the loop.
so, no more clicks, but you have changed the actual sample values of
the loop (by forcing an envelope, a window) – you can call this an
amplitude modulation. this is what the first patch does.

the phasor~ multiplied by the loop length is the read-pointer, that
reads data with the play~ object out of buffer~.
with trapezoid~ you can take care of the fading at the loop points
(you can observe this yourself by hooking up a scope-object to
phasor~ and trapezoid~ to look at the signals). the trapezoid signal
is multiplied by the actual sample values from play~.
(see attachment below).

the sah~ looks complicated but serves a simple task:
(the idea stems from nobuyasu sakonda’s famous granular patch
http://www.bekkoame.ne.jp/~nsakonda/maxpatch.html)
if you’d like to move the playback position while the loop is playing
(or change the loop size) you shouldn’t do this while the playback
pointer is “inside” the loop, but rather when it’s at the end or the
beginning (which of course is the same) – otherwise you end up having
clicks again.
an easy way to examine the loop start/end is to watch the ramp of the
phasor~. this is done by the comparison [< ~ 0.5].
the actual value of 0.5 is arbitrary (could be anything in the range
0 < x < 1). the comparison will change its output state when the
phasor-ramp jumps back from 1 to 0. and this change of state is used
to trigger the sah~ object and ‘tells’ it to sample a new value from
its input.
with this setput we can make sure that changes of playback position
or loop length only happen at the turning points of the loop, where
amplitude values are zero, to avoid generating clicks.

but!
course there is a gap in the audio flow at the loop points (from fade
in/out).
to get rid of that, instead of simple fade in/out we could make a
crossfade between start and end of the loop, actually overlapping the
two parts. this is a little tricky and we certainly need two
‘players’ to achieve it.
so the idea of the second patch i posted is to have two loops which
are actually twice as long as in the first example. this is done to
synchronize the loops – we don’t hear the second part of the loop,
cause we use a ‘custom made’ envelope instead of trapezoid~, where we
can determine that the fade out is starting in the middle of the loop…
the two players/loops are 180 degree out of phase, i.e. synchronized
so that the first loop fades out when the second one fades in. thats it.
i think i remember having seen something similar a few years ago in
the lloopp-collection by klaus filip.

phew! it takes ages to explain something in words, which is easily
programmed in 10 minutes…
well, hope it helps,
volker.

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P comment 69 337 67 196617 w/o env;
#P comment 68 324 67 196617 choose;
#P comment 412 363 67 196617 (envelope);
#P comment 231 339 67 196617 apply env;
#P comment 379 119 67 196617 fade time;
#P comment 412 349 67 196617 trapezoid;
#P comment 411 276 67 196617 ramp;
#P comment 98 209 67 196617 loop length;
#P number 121 330 35 9 1 2 3 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 133 366 80 196617 selector~ 2 1;
#P newex 203 336 27 196617 *~;
#P newex 168 246 43 196617 +~ 300;
#P newex 168 205 44 196617 *~ 333;
#P newex 168 281 43 196617 play~ s;
#P message 66 113 43 196617 replace;
#P newex 66 133 79 196617 buffer~ s 1000;
#P user scope~ 283 320 406 394 256 3 128 -1. 1. 0 0. 0 0. 102 255 51
135 135 135 0;
#P user scope~ 283 244 406 318 256 3 128 -1. 1. 0 0. 0 0. 102 255 51
135 135 135 0;
#P flonum 383 135 35 9 0. 0.5 3 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 383 162 30 196617 !- 1.;
#P user ezdac~ 120 443 164 476 0;
#P newex 299 186 94 196617 trapezoid~ 0.2 0.8;
#P newex 283 149 55 196617 phasor~ 3;
#P comment 99 249 67 196617 loop offset;
#P connect 9 0 8 0;
#P connect 14 0 3 0;
#P connect 15 0 14 0;
#P connect 14 0 3 1;
#P connect 1 0 11 0;
#P connect 11 0 12 0;
#P connect 12 0 10 0;
#P connect 10 0 14 1;
#P fasten 10 0 13 0 173 317 208 317;
#P connect 13 0 14 2;
#P fasten 2 0 13 1 304 216 225 216;
#P hidden connect 1 0 6 0;
#P hidden fasten 2 0 7 0 304 226 288 226;
#P connect 1 0 2 0;
#P connect 5 0 2 1;
#P connect 5 0 4 0;
#P connect 4 0 2 2;
#P window clipboard copycount 24;

#92374
Jan 9, 2007 at 10:26am

Thank you very much for the detailed explanation. I have tried to understand the similar things about cross-fade or windowing function (e.g in harmonizer), but still have not figured it out. But I understand it a little bit better now after reading your explanation.

I still have two questions about the 1st patch:

1. At the moment when the phasor signal ramp down or up to change the result of the “< ~0.5" comparsion, the signal from phase~ or trapezoid~ is not really 0. Why does sah~ sample its input at this time ?

2. What does the number 1000 represent in the “!/1000″ above phasor~ object ? Why 1000 ?

Thank you very much for the help.

Best
Chien-Wen

#92375
Jan 9, 2007 at 11:55am

On 09 Jan 2007, at 11:26, Cheng Chien-Wen wrote:
>
> I still have two questions about the 1st patch:
>
> 1. At the moment when the phasor signal ramp down or up to change
> the result of the “< ~0.5" comparsion, the signal from phase~ or
> trapezoid~ is not really 0. Why does sah~ sample its input at this
> time ?

the result of the comparison is always either true (1) or false (0)
to trigger the sah~ we need to go from 0 to above 0 (e.g. to 1). this
change is going to happen if the ramp from phasor~ jumps back from 1
to 0. ( it must be a ramp up, so in this example you have to provide
positive frequencies)
the change in the other direction of the comparison, from 1 to 0, is
happening when the ramp is passing the 0.5 mark.
but this is not doing anything to sah~.
so yes, the change is happening when the phasor~ is 0.
again, scope~ is your friend for examining this stuff.
>
> 2. What does the number 1000 represent in the “!/1000″ above
> phasor~ object ? Why 1000 ?

well, there are 1000 millisec. in 1 sec.
this is to express time in frequency.
T = 1 / f
f = 1 / T
where T is time in seconds and f is frequency in Hz.

this is fundamental to almost everything you do with sound.

#92376
Jan 9, 2007 at 11:58am

Ok, I think I figure it out the first patch.
Please let me know if I misunderstood it.

I think the saw tooth wave generated by phasor~ actually “ramp down” very fast so as long as sah~ hold the sample during the “ramp down” of the saw tooth wave, it is safe.

And 1000 refers to 1 sec for frequency calculation.

Does phasor~ actually “abruptly drop down” from 1 to 0 ? Or does it gradually “ramp down” ?

If it abruptly drops down in no time, then it makes sense to me that sah~ samples the input when comparison result transits from 0 to 1 and makes no click.

Do I think correctly about the 1st patch ?

Thank you very much.

#92377
Jan 22, 2007 at 11:05am

#92378
Jan 25, 2007 at 9:54am

On 22 Jan 2007, at 12:05, David Atkinson wrote:
>
> I have attempted to adapt your patch using poly~ and a multislider
> to change the different sample positions of each voice.
> Unfortunately I have run into some problems. When I change a value
> on a multislider other voices seem to stop playing. I sure this is
> something to do with voice managment in the subpatch, but I just
> cannot work out whats wrong.
>

hallo david,
you have to decide, which parameters you want to change globally,
i.e. for all poly instances at the same time, and which params you’d
like to change individually for each instance.
in your patch looplen, amp and samplelen are ‘global’, and you can
use simple send/receive pairs to provide all instances with updates.
you can also use the ‘target 0′ message to address all instances –
but the target message is communicating with the poly~ object,
therefore you must always send it to the first inlet, followed by the
actual value you’d like to change, which is sent to the corresponding
inlet of the poly~ (see example below).
this is basically the same for sending values to individual instances
- target message always to the leftmost inlet of poly~.

i guess the ringmodulation just before the dac~ was just an oversight?
volker.

/* save as sliderSub */

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#N in 2;
#P newobj 356 50 25 196617 in 2;
#P newex 237 374 36 196617 r amp;
#P window setfont Monaco 9.;
#P flonum 154 89 71 9 0 0 0 4 0 0 0 221 221 221 222 222 222 0 0 0;
#P window setfont “Sans Serif” 9.;
#P flonum 92 82 33 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 91 100 58 196617 change 0.1;
#P newex 159 406 27 196617 *~;
#P flonum 91 119 33 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P comment 153 42 62 196617 sample size;
#P newex 154 64 60 196617 r sampSize;
#P newex 91 146 61 196617 * 1.;
#P user number~ 15 246 91 261 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221
221 222 222 222 0 0 0;
#P flonum 91 175 82 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#N out~ 1;
#P newobj 159 430 52 196617 out~ 1;
#P newex 212 243 45 196617 *~ 10;
#P newex 247 213 38 196617 sah~;
#P newex 275 174 52 196617 < ~ 0.5;
#P newex 356 218 94 196617 trapezoid~ 0.1 0.9;
#P newex 356 133 59 196617 phasor~;
#P flonum 356 114 57 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 247 133 38 196617 sig~;
#P newex 356 87 66 196617 !/ 1000.;
#P newex 159 373 27 196617 *~;
#P newex 159 340 73 196617 play~ dve;
#P newex 102 290 120 196617 +~;
#P newex 102 243 38 196617 sah~;
#P newex 91 213 38 196617 sig~;
#N in 1;
#P newobj 91 63 38 196617 in 1;
#P comment 351 26 49 196617 loop size;
#P comment 63 41 79 196617 sample position;
#P fasten 11 0 15 0 361 160 217 160;
#P fasten 11 0 13 0 361 161 280 161;
#P connect 11 0 12 0;
#P connect 10 0 11 0;
#P connect 8 0 10 0;
#P connect 28 0 9 0;
#P connect 28 0 8 0;
#P fasten 13 0 4 1 280 199 135 199;
#P connect 13 0 14 1;
#P connect 14 0 15 1;
#P connect 9 0 14 0;
#P connect 15 0 5 1;
#P connect 27 0 23 1;
#P fasten 12 0 7 1 361 362 181 362;
#P connect 23 0 16 0;
#P connect 7 0 23 0;
#P connect 6 0 7 0;
#P fasten 5 0 6 0 107 323 164 323;
#P connect 20 0 26 0;
#P connect 26 0 19 1;
#P connect 4 0 5 0;
#P connect 3 0 18 0;
#P connect 3 0 4 0;
#P connect 2 0 25 0;
#P connect 17 0 3 0;
#P connect 19 0 17 0;
#P connect 22 0 19 0;
#P connect 24 0 22 0;
#P connect 25 0 24 0;
#P window clipboard copycount 29;

/* main patch */

#P window setfont Monaco 9.;
#P window linecount 1;
#P message 307 363 26 262153 80.;
#P window setfont “Sans Serif” 9.;
#N vpatcher 10 59 610 459;
#P outlet 140 241 15 0;
#P outlet 68 239 15 0;
#P window setfont “Sans Serif” 9.;
#P newex 143 163 76 196617 prepend target;
#P newex 86 131 67 196617 fswap 0.5;
#P newex 86 100 67 196617 unpack 1 80.;
#P inlet 86 47 15 0;
#P newex 86 70 61 196617 listfunnel 1;
#P connect 4 0 5 0;
#P connect 1 0 0 0;
#P connect 0 0 2 0;
#P connect 2 0 3 0;
#P connect 3 0 6 0;
#P connect 2 1 3 1;
#P connect 3 1 4 0;
#P pop;
#P newobj 141 382 43 196617 p;
#P user multiSlider 141 241 79 134 0. 500. 4 2681 47 0 1 2 0 33 0;
#M frgb 0 0 0;
#M brgb 222 229 200;
#M rgb2 127 127 127;
#M rgb3 0 0 0;
#M rgb4 37 52 91;
#M rgb5 74 105 182;
#M rgb6 112 158 18;
#M rgb7 149 211 110;
#M rgb8 187 9 201;
#M rgb9 224 62 37;
#M rgb10 7 114 128;
#P newex 95 436 41 196617 *~ 0.5;
#P newex 344 401 36 196617 s amp;
#P newex 343 313 60 196617 s sampSize;
#P hidden message 95 50 82 196617 0 0.25 0.5 0.75;
#P hidden newex 95 27 66 196617 loadmess;
#P window setfont Monaco 9.;
#P message 344 362 31 262153 0.5;
#P newex 344 340 66 262153 loadbang;
#P flonum 344 382 67 9 0 0 0 4 0 0 0 221 221 221 222 222 222 0 0 0;
#P window setfont “Sans Serif” 9.;
#P message 28 448 38 196617 open;
#P message 95 179 72 196617 target $1 , $2;
#P newex 95 159 61 196617 listfunnel 1;
#P number 47 238 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 47 256 45 196617 open $1;
#P comment 447 142 23 196617 end;
#P comment 100 140 33 196617 Start;
#P comment 49 122 40 196617 voice 4;
#P comment 49 107 43 196617 voice 3;
#P comment 49 92 43 196617 voice 2;
#P newex 95 409 89 196617 poly~ sliderSub 4;
#P toggle 69 448 15 0;
#P newex 95 488 38 196617 dac~;
#P flonum 343 280 74 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 265 259 105 196617 info~ dve;
#P message 283 208 59 196617 replace;
#P newex 283 232 87 196617 buffer~ dve;
#P user multiSlider 95 75 385 62 0. 1. 4 2936 47 0 3 1 4 0 0;
#M frgb 0 0 0;
#M brgb 255 255 255;
#M rgb2 127 127 127;
#M rgb3 0 0 0;
#M rgb4 37 52 91;
#M rgb5 74 105 182;
#M rgb6 112 158 18;
#M rgb7 149 211 110;
#M rgb8 187 9 201;
#M rgb9 224 62 37;
#M rgb10 7 114 128;
#P comment 49 77 43 196617 voice 1;
#P user panel 47 76 45 60;
#X brgb 191 191 191;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P user panel 261 203 161 102;
#X brgb 191 191 191;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P window setfont Monaco 9.;
#P comment 222 60 100 262153 Sample Position;
#P window setfont “Sans Serif” 9.;
#P comment 147 226 100 196617 loop lengths;
#P connect 19 0 18 0;
#P hidden connect 26 0 27 0;
#P hidden connect 27 0 5 0;
#P connect 5 0 20 0;
#P connect 20 0 21 0;
#P connect 32 0 12 0;
#P connect 21 0 12 0;
#P fasten 18 0 12 0 52 276 100 276;
#P connect 12 0 30 0;
#P fasten 22 0 10 0 33 474 100 474;
#P fasten 11 0 10 0 74 474 100 474;
#P connect 30 0 10 0;
#P connect 30 0 10 1;
#P connect 33 0 31 0;
#P connect 31 0 32 0;
#P connect 32 1 12 1;
#P connect 6 1 8 0;
#P connect 7 0 6 0;
#P connect 24 0 33 0;
#P connect 8 6 9 0;
#P connect 9 0 28 0;
#P connect 24 0 25 0;
#P connect 25 0 23 0;
#P connect 23 0 29 0;
#P window clipboard copycount 34;

#92379
Jan 26, 2007 at 11:46am

#92380
Jan 26, 2007 at 5:14pm

As is always the case with Max, there are multiple
ways to approach things. Assuming that you’ve spent
the necessary time with the tutorial on poly~ to
know enough to address a specific voice, I find that
the best general hygeine involves sending any
information I need to a given instantiation {voice]
in a poly~ as a single list and then doing the
whole prepend thing, unpacking inside the poly,
and routing the necessary messages from there.
Anything you need to do globally [calculations on
buffer length using sfinfo~, for example] you
can just use send and receive for, taking advantage
of Max’s global data space. Stick in a mute message
to turn your voice on and off and you’re good to
go.

There certainly are people who opt for a squillion
in and out objects inside their poly~, but not
ganging stuff is just asking for trouble.

Your mileage may vary.

#92381

You must be logged in to reply to this topic.