Forums > MaxMSP

Looping buffer "play~ bank" suggestions.

January 8, 2007 | 12:26 am

Hello everyone! I’m building an audio ‘pool’ to feed an automated matrix patch I’ve been working on, and I need some help.

What I’m trying to acheive is this: I need to have 64 different play~ objects looping audio from the same long buffer, each looping a subsequent section of audio from it. In other words, Play~ object 1 would loop 1-1000ms, play~ object 2 would loop 1001-2000ms, etc, until the last play~ object plays the last section of audio. The play objects would be constantly looping, each representing a section of the buffer which could be recorded into at will.

I am left scratching my head on how to acomplish the calculations necessary to produce those playback times (based on an arbitrary record length), as well as how to effectively loop the objects at the specific lengths I require.

I’d love to hear any suggestions as to get started on this- I am open to using objects other than play~, by the way, I only started with play~ because it seemed to have a smaller CPU cost, a necessary consideration considering I do need 64 of them!

Cheers, Jeremy


January 8, 2007 | 2:51 am

Here’s one way to do it. I used groove~ because it’s easy to give it beginning and end playback times. I did a little extra math to make it sample accurate. If you just did 1-1000ms and then 1001-2000ms, you’d miss 44 samples of the recording. This patch starts each section at the next sample. Hopefully this gets you on your way. I’ve only been using Max/Msp for a month, so there are probably simpler ways to accomplish what you’re trying to do using objects I don’t know about yet…I just wanted to see if I could figure it out for my own learning process…and maybe help you out as well. :) Sorry it’s a bit messy, I wanted to loadbang everything so you could just fire it up… the [clocker] object and [p math] abstraction are the important parts….hope this helps!

max v2;
#N vpatcher 111 68 997 638;
#P window setfont "Sans Serif" 9.;
#P message 336 354 26 196617 127;
#P newex 430 123 48 196617 loadbang;
#P newex 35 171 48 196617 loadbang;
#P message 711 191 14 196617 1;
#P message 502 184 14 196617 1;
#P message 291 182 14 196617 1;
#P message 107 181 14 196617 1;
#P button 26 227 15 0;
#P button 207 236 15 0;
#P button 416 230 15 0;
#P button 633 239 15 0;
#P flonum 805 280 56 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 761 241 57 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 582 268 58 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 544 241 54 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 382 273 58 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 341 235 55 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 181 274 57 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 156 239 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 80 137 87 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 76 109 109 196617 clocker 100.04567;
#P newex 444 355 80 196617 receive~ direct;
#P newex 516 59 66 196617 send~ direct;
#P message 652 261 29 196617 stop;
#P message 447 245 29 196617 stop;
#P message 231 254 29 196617 stop;
#P message 55 250 29 196617 stop;
#P newex 68 372 48 196617 loadbang;
#P message 69 396 64 196617 loopinterp 1;
#P message 394 63 33 196617 clear;
#P user ezdac~ 388 500 432 533 0;
#P user gain~ 397 343 24 100 158 0 1.071519 7.94321 10.;
#P button 650 214 15 0;
#P button 438 206 15 0;
#P button 231 210 15 0;
#P button 56 205 15 0;
#P flonum 712 218 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 712 241 29 196617 sig~;
#P toggle 666 282 15 0;
#P message 666 305 43 196617 loop $1;
#P message 652 239 51 196617 startloop;
#P flonum 500 211 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 500 234 29 196617 sig~;
#P toggle 454 275 15 0;
#P message 454 298 43 196617 loop $1;
#P message 439 228 51 196617 startloop;
#P flonum 289 214 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 289 237 29 196617 sig~;
#P toggle 243 278 15 0;
#P message 243 301 43 196617 loop $1;
#P message 230 232 51 196617 startloop;
#P flonum 107 208 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 107 231 29 196617 sig~;
#P toggle 59 269 15 0;
#P message 59 292 43 196617 loop $1;
#P message 54 232 51 196617 startloop;
#N vpatcher 360 258 960 658;
#P window setfont "Sans Serif" 9.;
#P newex 85 220 58 196617 + 0.022727;
#P newex 261 40 48 196617 loadbang;
#P message 255 102 14 196617 4;
#P message 129 106 14 196617 3;
#P flonum 86 176 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 214 180 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 209 98 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P newex 80 84 41 196617 * 0.25;
#P window linecount 0;
#P newex 80 126 35 196617 * 1.;
#P newex 203 144 35 196617 * 1.;
#P newex 203 70 41 196617 * 0.25;
#N comlet loop end;
#P outlet 261 271 15 0;
#N comlet loop start;
#P outlet 84 270 15 0;
#N comlet record length;
#P inlet 80 54 15 0;
#P connect 0 0 6 0;
#P connect 6 0 5 0;
#P connect 13 0 1 0;
#P connect 9 0 13 0;
#P connect 5 0 9 0;
#P fasten 10 0 5 1 110 121;
#P fasten 12 0 10 0 134 57;
#P connect 0 0 3 0;
#P connect 7 0 4 0;
#P connect 3 0 7 0;
#P fasten 4 0 8 0 208 171 219 171;
#P fasten 11 0 4 1 260 137 233 137;
#P connect 12 0 11 0;
#P fasten 8 0 2 0 213 248 266 248;
#P pop;
#P newobj 773 189 40 196617 p math;
#N vpatcher 604 104 1204 504;
#P window setfont "Sans Serif" 9.;
#P message 257 111 14 196617 3;
#P message 118 100 14 196617 2;
#P newex 256 30 48 196617 loadbang;
#P flonum 207 172 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 207 100 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 83 204 58 196617 + 0.022727;
#P flonum 78 169 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P newex 58 85 41 196617 * 0.25;
#P window linecount 0;
#P newex 79 126 35 196617 * 1.;
#P newex 203 144 35 196617 * 1.;
#P newex 203 70 41 196617 * 0.25;
#N comlet loop end;
#P outlet 261 271 15 0;
#N comlet loop start;
#P outlet 84 270 15 0;
#N comlet record length;
#P inlet 79 54 15 0;
#P fasten 0 0 6 0 63 69;
#P connect 5 0 7 0;
#P fasten 6 0 5 0 63 116 84 116;
#P connect 7 0 8 0;
#P connect 8 0 1 0;
#P fasten 12 0 5 1 109 115;
#P fasten 11 0 12 0 123 53;
#P connect 0 0 3 0;
#P connect 9 0 4 0;
#P connect 3 0 9 0;
#P connect 4 0 10 0;
#P fasten 13 0 4 1 262 134 233 134;
#P connect 11 0 13 0;
#P connect 10 0 2 0;
#P pop;
#P newobj 549 183 40 196617 p math;
#N vpatcher 479 408 1079 808;
#P window setfont "Sans Serif" 9.;
#P message 117 84 14 196617 1;
#P message 251 122 14 196617 2;
#P newex 84 231 67 196617 + 0.022727;
#P flonum 205 102 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 245 31 48 196617 loadbang;
#P flonum 203 186 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 81 197 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P newex 59 86 41 196617 * 0.25;
#P window linecount 0;
#P newex 79 126 35 196617 * 1.;
#P newex 203 144 35 196617 * 1.;
#P newex 203 70 41 196617 * 0.25;
#N comlet loop end;
#P outlet 261 271 15 0;
#N comlet loop start;
#P outlet 84 270 15 0;
#N comlet record length;
#P inlet 79 54 15 0;
#P fasten 0 0 6 0 64 69;
#P fasten 6 0 5 0 64 122 78 122 78 129;
#P connect 5 0 7 0;
#P connect 7 0 11 0;
#P connect 11 0 1 0;
#P fasten 13 0 5 1 122 113 109 113;
#P fasten 9 0 13 0 122 48;
#P connect 0 0 3 0;
#P connect 10 0 4 0;
#P connect 4 0 8 0;
#P connect 3 0 10 0;
#P fasten 12 0 4 1 222 137;
#P connect 9 0 12 0;
#P fasten 8 0 2 0 208 251 266 251;
#P pop;
#P newobj 350 182 40 196617 p math;
#N vpatcher 296 255 896 655;
#P window setfont "Sans Serif" 9.;
#P newex 232 28 48 196617 loadbang;
#P message 268 116 14 196617 1;
#P message 116 120 14 196617 0;
#P flonum 207 184 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 206 100 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 81 185 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P newex 79 85 41 196617 * 0.25;
#P window linecount 0;
#P newex 78 145 27 196617 *;
#P newex 203 144 53 196617 * 1.;
#P newex 203 70 41 196617 * 0.25;
#N comlet loop end;
#P outlet 261 271 15 0;
#N comlet loop start;
#P outlet 84 270 15 0;
#N comlet record length;
#P inlet 78 56 15 0;
#P connect 6 0 5 0;
#P connect 0 0 6 0;
#P connect 5 0 7 0;
#P connect 7 0 1 0;
#P fasten 10 0 5 1 100 135;
#P fasten 12 0 10 0 127 45;
#P connect 0 0 3 0;
#P connect 8 0 4 0;
#P connect 3 0 8 0;
#P connect 4 0 9 0;
#P fasten 11 0 4 1 251 131;
#P fasten 9 0 2 0 212 234 266 234;
#P fasten 12 0 11 0 237 57 273 57;
#P pop;
#P newobj 160 177 40 196617 p math;
#P newex 733 304 81 196617 groove~ sample;
#P newex 516 300 81 196617 groove~ sample;
#P newex 312 300 81 196617 groove~ sample;
#P message 243 79 14 196617 0;
#P message 219 79 14 196617 1;
#P user ezadc~ 302 39 346 72 0;
#P newex 124 297 81 196617 groove~ sample;
#P newex 301 94 80 196617 record~ sample;
#P newex 387 94 111 196617 buffer~ sample 10000;
#P fasten 4 0 61 0 31 94;
#P connect 33 0 13 0;
#P fasten 61 0 42 0 31 255;
#P fasten 5 0 33 0 248 199 61 199;
#P fasten 41 0 15 0 49 389 49 269;
#P connect 15 0 14 0;
#P connect 41 0 40 0;
#P fasten 5 0 48 0 248 103 81 103;
#P fasten 4 0 48 0 81 94;
#P connect 48 0 49 0;
#P fasten 66 0 62 0 96 188 96 176 112 176;
#P connect 62 0 17 0;
#P connect 17 0 16 0;
#P fasten 40 0 2 0 178 411 178 365 113 365 113 286 129 286;
#P fasten 42 0 2 0 129 269;
#P fasten 13 0 2 0 129 266;
#P fasten 16 0 2 0 112 291 129 291;
#P fasten 14 0 2 0 64 313 117 313 117 288 129 288;
#P connect 9 0 50 0;
#P fasten 50 0 2 1 161 285 164 285;
#P connect 49 0 9 0;
#P connect 9 1 51 0;
#P connect 51 0 2 2;
#P fasten 4 0 60 0 224 217 212 217;
#P connect 34 0 18 0;
#P fasten 5 0 34 0 248 215 236 215;
#P fasten 60 0 43 0 212 257 223 257 223 250 236 250;
#P fasten 41 0 20 0 49 389 49 334 238 334 238 272 248 272;
#P connect 20 0 19 0;
#P connect 63 0 22 0;
#P connect 22 0 21 0;
#P fasten 66 0 63 0 96 188 96 173 144 173 144 157 296 157;
#P fasten 5 0 1 0 248 110 283 110 283 87 306 87;
#P fasten 4 0 1 0 224 120 293 120 293 85 306 85;
#P fasten 3 1 1 0 341 83 306 83;
#P connect 3 0 1 0;
#P fasten 40 0 6 0 302 411 302 290 317 299;
#P fasten 18 0 6 0 275 247 275 283 317 283;
#P fasten 43 0 6 0 283 269 283 290 317 290;
#P fasten 19 0 6 0 248 322 304 322 304 292 317 292;
#P fasten 21 0 6 0 294 291 317 291;
#P fasten 41 0 68 0 324 389 324 348 341 348;
#P connect 10 0 52 0;
#P connect 52 0 6 1;
#P fasten 49 0 10 0 85 161 355 161;
#P fasten 10 1 53 0 385 226 401 226 401 260 387 260;
#P connect 53 0 6 2;
#P fasten 39 0 0 0 399 81 392 81;
#P connect 37 0 38 0;
#P fasten 47 0 37 0 428 372 428 333 402 333;
#P fasten 8 0 37 0 738 335 402 335;
#P fasten 7 0 37 0 521 339 402 339;
#P fasten 6 0 37 0 317 335 402 335;
#P fasten 2 0 37 0 129 340 402 340;
#P fasten 68 0 37 0 384 369 384 339 402 339;
#P fasten 4 0 59 0 224 168 421 168;
#P connect 37 0 38 1;
#P fasten 5 0 35 0 248 204 335 204 335 215 443 215;
#P connect 35 0 23 0;
#P fasten 59 0 44 0 421 251;
#P fasten 41 0 25 0 59 389 59 326 449 326 449 276;
#P connect 25 0 24 0;
#P connect 64 0 27 0;
#P connect 27 0 26 0;
#P fasten 67 0 64 0 435 174 507 174;
#P fasten 3 0 46 0 376 72 376 52 521 52;
#P fasten 3 1 46 0 341 80 377 80 377 50 521 50;
#P fasten 40 0 7 0 374 411 374 328 440 328 446 349 512 349 512 287 521 287;
#P fasten 44 0 7 0 521 260;
#P fasten 26 0 7 0 505 278 521 278;
#P fasten 23 0 7 0 444 270 521 270;
#P fasten 24 0 7 0 459 321 510 321 510 288 521 288;
#P connect 11 0 54 0;
#P fasten 49 0 11 0 85 168 554 168;
#P fasten 54 0 7 1 549 287 556 287;
#P fasten 11 1 55 0 584 221 609 221 609 263 587 263;
#P connect 55 0 7 2;
#P fasten 4 0 58 0 224 151 638 151;
#P fasten 5 0 36 0 248 202 543 202 543 228 633 228 633 202 655 202;
#P connect 36 0 28 0;
#P fasten 58 0 45 0 638 261;
#P fasten 41 0 30 0 60 389 60 324 659 324 659 280 671 280;
#P connect 30 0 29 0;
#P fasten 67 0 65 0 435 156 716 156;
#P connect 65 0 32 0;
#P connect 32 0 31 0;
#P fasten 45 0 8 0 738 276;
#P fasten 29 0 8 0 671 334 722 334 722 297 738 297;
#P fasten 28 0 8 0 738 271;
#P fasten 31 0 8 0 717 280 738 280;
#P fasten 40 0 8 0 374 411 374 324 440 324 440 349 729 349 729 299 738 299;
#P connect 12 0 56 0;
#P fasten 56 0 8 1 766 295 781 295 773 303;
#P fasten 49 0 12 0 85 165 778 172;
#P connect 57 0 8 2;
#P fasten 12 1 57 0 808 220 824 220 824 266 810 266;
#P pop;


January 8, 2007 | 2:53 am

Note: Each [p math] has some different multipliers, so make sure you check out each one to see the pattern you would have to use….


January 8, 2007 | 6:21 am

[poly~] is your friend for this kind of stuff.
here is an example with a sound file, you might want to change it for live recorded files.
you 64 instances of the same player. the soundfile is divide in 64 chunks each instance plays a given chunk. volume can be adjusted for each player.
accomodate the patch for your needs, many other things can be done with [poly~]. the world of clones is a nice little labyrinth worth walking into ;)

save as "player" :

#P window setfont "Sans Serif" 9.;
#P flonum 343 385 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#N in 3;
#P newobj 322 351 25 196617 in 3;
#P newex 52 475 47 196617 *~ 0.05;
#P flonum 147 143 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 187 144 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 293 147 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 333 147 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 120 288 29 196617 gate;
#P newex 293 168 27 196617 t b i;
#P newex 293 120 90 196617 route loop loopOff;
#N in 1;
#P newobj 293 97 25 196617 in 1;
#P newex 44 124 30 196617 – 0.;
#P newex 78 80 29 196617 * 1.;
#N in 2;
#P newobj 42 38 25 196617 in 2;
#P button 88 365 15 0;
#P message 53 316 56 196617 $1 , $2 $3;
#P newex 148 48 68 196617 r sliceLength;
#P newex 53 194 61 196617 pak 0. 0. 0.;
#N out~ 1;
#P newobj 53 507 39 196617 out~ 1;
#P newex 53 363 32 196617 line~;
#P newex 53 408 53 196617 play~ bob;
#P comment 188 292 100 196617 open gate to loop;
#P window linecount 2;
#P comment 73 18 100 196617 define loopin and loop out points;
#P window linecount 1;
#P comment 347 97 100 196617 loop on-off;
#P window linecount 2;
#P comment 350 351 100 196617 control volume of each voice;
#P comment 383 388 100 196617 volume value for each voice;
#P window linecount 1;
#P comment 127 165 47 196617 loop in;
#P comment 181 166 100 196617 loop out;
#P fasten 15 0 16 0 83 110 49 110;
#P connect 7 0 25 0;
#P connect 16 0 10 0;
#P connect 10 0 12 0;
#P fasten 20 0 12 0 125 310 58 310;
#P fasten 19 0 12 0 298 228 58 228;
#P connect 12 0 8 0;
#P connect 8 0 7 0;
#P connect 25 0 9 0;
#P connect 11 0 16 1;
#P fasten 14 0 15 0 47 64 83 64;
#P connect 15 0 10 1;
#P connect 8 1 13 0;
#P fasten 26 0 25 1 327 454 94 454;
#P connect 11 0 15 1;
#P connect 11 0 10 2;
#P fasten 21 0 20 0 338 255 125 255;
#P fasten 19 1 20 0 315 239 125 239;
#P fasten 13 0 20 1 93 388 179 388 179 275 144 275;
#P connect 16 0 24 0;
#P connect 15 0 23 0;
#P connect 17 0 18 0;
#P connect 18 0 22 0;
#P connect 22 0 19 0;
#P connect 18 1 21 0;
#P connect 26 0 27 0;
#P window clipboard copycount 28;

—-

save as "main" or whatever :

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 496 152 39 196617 open 1;
#P message 374 434 30 196617 open;
#P newex 512 363 76 196617 prepend target;
#P newex 493 307 29 196617 t f b;
#N counter 0 1 64;
#X flags 0 0;
#P newobj 512 337 77 196617 counter 0 1 64;
#P newex 493 282 25 196617 iter;
#P user multiSlider 493 176 190 91 0. 0.5 64 2681 47 0 0 2 0 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 newex 306 154 76 196617 prepend target;
#P newex 382 115 27 196617 t i i;
#P user ezdac~ 318 468 362 501 0;
#P button 324 59 15 0;
#P message 495 131 95 196617 target 0 , loopOff 0;
#P message 496 110 81 196617 target 0 , loop 1;
#P newex 324 90 40 196617 uzi 64;
#P newex 319 221 137 196617 poly~ player 64;
#P flonum 75 182 60 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 75 157 31 196617 / 64;
#P flonum 75 134 62 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 75 205 68 196617 s sliceLength;
#P message 29 63 43 196617 replace;
#P newex 29 84 62 196617 buffer~ bob;
#P newex 75 108 105 196617 info~ bob;
#P comment 29 44 100 196617 1 load a sound file;
#P window linecount 3;
#P comment 147 160 100 196617 division by 64 to give us the lenght of one slice;
#P window linecount 2;
#P comment 692 185 100 196617 volume for each instance;
#P window linecount 1;
#P comment 337 242 100 196617 your 64 players;
#P window linecount 3;
#P comment 346 35 100 196617 2. distribute loopin and loopout points for each player;
#P window linecount 1;
#P comment 583 110 100 196617 3. loop all;
#P comment 595 131 100 196617 no loop;
#P comment 539 152 187 196617 open instance to check what s going on;
#P connect 29 0 15 0;
#P connect 10 0 9 0;
#P connect 9 1 8 0;
#P fasten 8 6 12 0 158 129 80 129;
#P connect 12 0 13 0;
#P connect 13 0 14 0;
#P connect 14 0 11 0;
#P fasten 21 1 22 0 404 143 311 143;
#P connect 28 0 20 0;
#P connect 15 0 20 0;
#P fasten 27 0 15 0 517 393 267 393 267 198 324 198;
#P connect 18 0 15 0;
#P connect 17 0 15 0;
#P connect 19 0 16 0;
#P connect 15 0 20 1;
#P fasten 16 2 21 0 359 111 387 111;
#P connect 21 0 15 1;
#P lcolor 7;
#P fasten 22 0 15 1 311 180 387 180;
#P fasten 26 0 15 2 498 351 478 351 478 198 450 198;
#P connect 23 0 24 0;
#P connect 24 0 26 0;
#P fasten 26 1 25 0 517 329 517 329;
#P connect 25 0 27 0;
#P window clipboard copycount 30;

Quote: UnUnUnium wrote on Sun, 07 January 2007 16:26
—————————————————-
> Hello everyone! I’m building an audio ‘pool’ to feed an automated matrix patch I’ve been working on, and I need some help.
>
> What I’m trying to acheive is this: I need to have 64 different play~ objects looping audio from the same long buffer, each looping a subsequent section of audio from it. In other words, Play~ object 1 would loop 1-1000ms, play~ object 2 would loop 1001-2000ms, etc, until the last play~ object plays the last section of audio. The play objects would be constantly looping, each representing a section of the buffer which could be recorded into at will.
>


January 8, 2007 | 7:04 am

Cool that’s kind of like the grm freeze plugin!

Peiman
On 8 Jan 2007, at 06:21, karl-otto von oertzen wrote:

> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P message 496 152 39 196617 open 1;
> #P message 374 434 30 196617 open;
> #P newex 512 363 76 196617 prepend target;
> #P newex 493 307 29 196617 t f b;
> #N counter 0 1 64;
> #X flags 0 0;
> #P newobj 512 337 77 196617 counter 0 1 64;
> #P newex 493 282 25 196617 iter;
> #P user multiSlider 493 176 190 91 0. 0.5 64 2681 47 0 0 2 0 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 newex 306 154 76 196617 prepend target;
> #P newex 382 115 27 196617 t i i;
> #P user ezdac~ 318 468 362 501 0;
> #P button 324 59 15 0;
> #P message 495 131 95 196617 target 0 , loopOff 0;
> #P message 496 110 81 196617 target 0 , loop 1;
> #P newex 324 90 40 196617 uzi 64;
> #P newex 319 221 137 196617 poly~ player 64;
> #P flonum 75 182 60 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 75 157 31 196617 / 64;
> #P flonum 75 134 62 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 75 205 68 196617 s sliceLength;
> #P message 29 63 43 196617 replace;
> #P newex 29 84 62 196617 buffer~ bob;
> #P newex 75 108 105 196617 info~ bob;
> #P comment 29 44 100 196617 1 load a sound file;
> #P window linecount 3;
> #P comment 147 160 100 196617 division by 64 to give us the lenght
> of one slice;
> #P window linecount 2;
> #P comment 692 185 100 196617 volume for each instance;
> #P window linecount 1;
> #P comment 337 242 100 196617 your 64 players;
> #P window linecount 3;
> #P comment 346 35 100 196617 2. distribute loopin and loopout
> points for each player;
> #P window linecount 1;
> #P comment 583 110 100 196617 3. loop all;
> #P comment 595 131 100 196617 no loop;
> #P comment 539 152 187 196617 open instance to check what s going on;
> #P connect 29 0 15 0;
> #P connect 10 0 9 0;
> #P connect 9 1 8 0;
> #P fasten 8 6 12 0 158 129 80 129;
> #P connect 12 0 13 0;
> #P connect 13 0 14 0;
> #P connect 14 0 11 0;
> #P fasten 21 1 22 0 404 143 311 143;
> #P connect 28 0 20 0;
> #P connect 15 0 20 0;
> #P fasten 27 0 15 0 517 393 267 393 267 198 324 198;
> #P connect 18 0 15 0;
> #P connect 17 0 15 0;
> #P connect 19 0 16 0;
> #P connect 15 0 20 1;
> #P fasten 16 2 21 0 359 111 387 111;
> #P connect 21 0 15 1;
> #P lcolor 7;
> #P fasten 22 0 15 1 311 180 387 180;
> #P fasten 26 0 15 2 498 351 478 351 478 198 450 198;
> #P connect 23 0 24 0;
> #P connect 24 0 26 0;
> #P fasten 26 1 25 0 517 329 517 329;
> #P connect 25 0 27 0;
> #P window clipboard copycount 30;


January 8, 2007 | 7:26 am

Quote: peimankhosravi@gmail.com wrote on Sun, 07 January 2007 23:04
—————————————————-
> Cool that’s kind of like the grm freeze plugin!
>

hum… i think i ll have to work a little harder until i make something that sounds like some GRM Tool ;)

but you could easily implement some pitch variations for each voice, and also change each voice’s length to get closer to the grm freeze plugin


January 8, 2007 | 9:04 am

If you’re into the whole live recording side of things, you should stutter~ object… This object can have a lot of internal playback buffers~ / players.

Dunno if it does what you wan’t, but stutter is surely among my fav objects for realtime looping.


January 8, 2007 | 11:17 am

First off thank you all very much for your replies- there is some very helpful stuff I’m finding, plenty of "now I get it" moments.

The only problem with the poly~ solution is that I need all 64 outputs to be playing constantly, as inefficient as that is- the reason being that it is feeding a 64 input matrix which switches with a variable ramp time- I might be missing the point though. This, however, is incredibly helpful as I’ve been trying to wrap my head arouns poly~ for another project I’m working on- your patch will be very useful to that end.

Temporalist, your solution is pretty close to what I need-I actually don’t need complete sample accuracy, at least in this part of the patch, but I’d love to know- how did you figure out the whole "44 samples missing" thing? That’s be great to know for future reference.

I do plan on checking out the stutter~ object in the near future- that is another one I need to get my head around- real-time sampling and looping are what I’m interested in doing, so I should get cozy with stutter~…

Right now I am using hr.wave~ for playback, and I’m feeling the sound quality improvement (over the original wave~) is very noticable….

Thanks again everyone for all your help, this all makes for quite a good launching pad for my project!
Cheers, Jeremy


January 8, 2007 | 5:11 pm

> The only problem with the poly~ solution is that I need all 64 outputs to be playing constantly, as inefficient as that is- the reason being that it is feeding a 64 input matrix which switches with a variable ramp time- I might be missing the point though. This, however, is incredibly helpful as I’ve been trying to wrap my head arouns poly~ for another project I’m working on- your patch will be very useful to that end.
>

can u send a patch of what you are trying to do, because with the [poly~] solution all 64 players are playing constantly. in my example they just have all the same length, which could be easily changed.
i am not sure i entirely understand what you are trying to do :
tell me if i am correct or not :
- you want 64 players playing from the same ( long) buffer~
- you want each player to play a chunk of the buffer~
- the content of the buffer is changing as you are recording live input into it
- you want to be able to change the lenght of each chunk dynamically but have no overlap timewise between the players, meaning loopout point of player A does not overlap with loopin point pf player B … ?
i might b missing something ;)
best,
ko


January 8, 2007 | 10:34 pm

Hey Karrrlo,

So the one thing I need that the poly~ solution doesn’t provide is multiple simultaneous outputs- meaning, 64 outputs all playing at once, connected to 64 inputs of a matrix object. Make sense? The poly~ provide 64 possible simultaneous voices, but NOT 64 simultaneously available outputs. Or did I miss something in the patch? i saw it having two outputs.

I could post a patch, but it’s got many abstractions and might be overkill- but let me know if you still need them after my explanation, and I’ll post them.

cheers, J


January 8, 2007 | 11:49 pm

i see, sorry for my slow understanding.
do you need the 64 outputs to further process them individually ( route them to various effects for instance ) or to route them through different outputs of a multichannelled sound card ?
.
in my example you can change the volume of each player via the [multislider].
you could add more outputs to the [poly~] ( i cant remember if there are any limitations, i assume there are, specially CPU wise, more outputs on 64 instances of an abstraction nested in a [poly~] will start taxing your machine ;) ).

maybe you can just use an abstraction repeated 64 times.
there might b a more elegant way to do it though :)

Quote: UnUnUnium wrote on Mon, 08 January 2007 14:34
—————————————————-
> Hey Karrrlo,
>
> So the one thing I need that the poly~ solution doesn’t provide is multiple simultaneous outputs- meaning, 64 outputs all playing at once, connected to 64 inputs of a matrix object. Make sense? The poly~ provide 64 possible simultaneous voices, but NOT 64 simultaneously available outputs. Or did I miss something in the patch? i saw it having two outputs.
>
> I could post a patch, but it’s got many abstractions and might be overkill- but let me know if you still need them after my explanation, and I’ll post them.
>
> cheers, J
—————————————————-


January 9, 2007 | 1:05 am



f.e
January 9, 2007 | 8:32 am


January 9, 2007 | 7:22 pm

Thank you for your reply f.e….

First off, I’m not quite sure I understand how the send item in working in the abstraction you posted (I am quite a new MaxMSP user).

Is the Sprintf changing the suffix of the DummyL DummyR send~ objects depending on the voice number , which would then go to (for example) a DummyL1 DummyR1 receive~ object, which would be connected to output objects within the poly~ patcher? If so, would they have to be out~ objects, or standard outlets?

It’s true that sequencing before the audio is probably a more efficient approach- I do wonder if it would have quite the same effect though, given the ability of the matrix to crossfade… I suppose a long decay could have the same effect. For now I have to go with what I’ve already set up because it is a class assignment due this friday!

Thanks again, Jeremy



f.e
January 10, 2007 | 9:58 pm

Hello,

Jeremy Keenan wrote:
> Thank you for your reply f.e….
>
> First off, I’m not quite sure I understand how the send item in working in the abstraction you posted (I am quite a new MaxMSP user).
>
1st, dont’ mess up bewteen send and send~. Send is for Max message,
send~ is for signals. I assume it may be a typo, but who knows…
>
> Is the Sprintf changing the suffix of the DummyL DummyR send~ objects depending on the voice number , which would then go to (for example) a DummyL1 DummyR1 receive~ object, which would be connected to output objects within the poly~ patcher? If so, would they have to be out~ objects, or standard outlets?
>
The DummyL & R names are only here because send~ needs an initialisation
argument. The sprintf is used here to ‘build’ (concatenate ?) the actual
name of the targetted receive~. It will be whatever you want + the
instance number as a suffix. Then, you only have to set a few receive~
objects outside the poly~, with the corresponding names. Let’s say you
choose ‘Go_Out_L’ & ‘Go_Out_R’, the sprintf will automatically ‘set’ the
send~ objects to target the ‘Go_Out_L1′ & ‘Go_Out_R1′, then the
‘Go_Out_L2′ and so on. So, may sure you have some [receive~ Go_Out_L1] &
so on objects outside to catch the sound. It’s only a way of dynamicaly
naming the targets.
> It’s true that sequencing before the audio is probably a more efficient approach- I do wonder if it would have quite the same effect though, given the ability of the matrix to crossfade… I suppose a long decay could have the same effect. For now I have to go with what I’ve already set up because it is a class assignment due this friday!
>
It realy depends on what you’re after. I like matrix~ very much but i
always try to find another solution before using it because it always
sucked a lot of cpu on my machines (when used intensively).
> Thanks again, Jeremy
>
you’re welcome

f.e
>
>
>
>



jln
January 10, 2007 | 10:22 pm



f.e
January 11, 2007 | 8:21 am


January 11, 2007 | 11:29 am

Jeremy Keenan wrote:
> The outputs are going to be ‘cut up’ by the matrix~, because the
> matrix~ is controlled by a step sequencer that controls the routing
> as well as the ramp time….This is then re-recorded into 1 of 8
> different buffers, which are played back by hr.wave~ with pitch
> control, all synched to a common tempo.

But then you could put easily the 8 outputs into the poly~s and use a
selector~ or matrix~ inside the poly~ to choose the output. You’d create
the whole matrix with the poly~s, as you could also only trigger the
poly~ if its supposed to sound…

This shows it is really essential to describe your original goal, not
only asking for the solution for a step you believe is necesary for your
goal. It might lead to much more efficient overall solutions…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


January 11, 2007 | 3:43 pm

On 11-Jan-2007, at 3:21, f.e wrote:
> I forgot this insane behavior of send/receive… This should be
> stopped right now, it’s against max’s ethical.

;-)


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