Actually, I just tried again to simply copy a couple of voices and it only took a fraction of a second with a very short dropout - even with the dsp on.
I have recently installed Natty instead of Lucid on a new machine. Maybe it has something to do with realloc that Mathieu mentioned. So it looks like dynamic patching of voices isn't "that" much of a problem here anymore. It still takes 7-8 seconds to create 16 voices in my case with the dsp off (12 with the dsp on) but that's still faster than restarting the patch. I would never have checked again if nobody would have mentioned it. I have attached a patch that I used for testing. These voices were receiving their input with [receive] so no connections were needed. If you are using wired inlets you will have to dynamically add the connections of course. I added a cut & paste at the end because for some reasons the voices didn't get initialized correctly. Not sure if this is needed for other voice-abstractions. Ingo > -----Ursprüngliche Nachricht----- > Von: [email protected] [mailto:[email protected]] Im Auftrag von > Roman Haefeli > Gesendet: Donnerstag, 29. September 2011 08:36 > An: Ludwig Maes > Cc: Pd List > Betreff: Re: [PD] Fwd: Variable number of objects? > > On Wed, 2011-09-28 at 19:29 +0200, Ludwig Maes wrote: > > > > > > ---------- Forwarded message ---------- > > From: Ludwig Maes <[email protected]> > > Date: 28 September 2011 19:29 > > Subject: Re: [PD] Variable number of objects? > > To: Ingo <[email protected]> > > > > > > I actually meant more in general, also for non-~ signals (i.e. also > > control rate .pd patches). I referred to polysynth such that people > > would see more easily what I meant. Are there really no such > > primitives? That seems like quite a restriction... > > > > How can that take 10 seconds?? I dont see what would cause such a huge > > overhead, i'd expect an increase in computations & memory though (say > > from 10 voices to 11: 10% increase in cpu workload & ram dedicated to > > these voices..., I fail to see what would necessitate a long > > initialization...) > > > > also, how is it done even with the long delays? > > > > > As I understand it, the whole DSP is recompiled whenever it is changed. > So, if you have a very large patch (and Ingo seems to be an expert in > very large patches) and you create another voice, it's easily possible > to eat up quite some time. > > Also, it's probably much slower the first time, if the voice abstraction > is built of many other abstractions, which need to be read from disk. > > But I guess you are right about the increase in CPU workload _after_ the > DSP graph has been recompiled: A switch from 10 two 11 instances is > expected to show only an increase of 10% in CPU usage. > > It's been said, that often you can gain quite some time while turning > off DSP during dynamic instantiation. But I guess, this makes only a > difference when performing several instantiations at the same time. When > DSP is on, each cycle would cause a complete DSP graph recompilation, > whereas when DSP is off, it's only recompiled once (after turning it on > again). > > > > Roman > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list
#N canvas 609 0 565 676 10; #X text 193 513 pos left; #X text 251 513 pos top; #X obj 244 568 pack f f f; #X msg 117 554 selectall; #X msg 87 554 cut; #X msg 47 554 paste; #X obj 30 608 s reset_system_delay; #X obj 262 243 f; #X obj 294 243 + 1; #X obj 228 280 sel; #X obj 246 228 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X msg 228 307 0; #X obj 160 307 spigot; #X obj 262 435 t b f f; #X obj 272 462 * 20; #X msg 406 372 clear; #X obj 30 527 t b b b b; #X obj 193 124 f; #X text 305 513 argument (voice number); #X text 277 108 set number of voices; #X obj 298 16 loadbang; #X obj 247 110 nbx 2 14 1 24 0 1 empty empty empty 0 -8 0 10 -261682 -1 -1 4 256; #X msg 214 531 30; #X obj 272 482 + 20; #N canvas 268 529 331 383 voicecanvas 1; #X restore 26 18 pd voicecanvas; #X obj 406 392 s pd-voicecanvas; #X obj 273 48 bng 15 250 50 0 empty empty add_voices -52 7 1 9 -257985 -1 -1; #X obj 47 581 s pd-voicecanvas; #X obj 244 608 s pd-voicecanvas; #X msg 244 588 obj \$1 \$2 samplevoice \$3; #X obj 30 507 pipe 100; #X text 20 279 pipe can be set faster; #X text 242 623 send to <window-name>; #X obj 298 63 t b b b; #X obj 337 244 nbx 2 14 0 16 0 0 empty empty empty 0 -8 0 10 -261682 -1 -1 0 256; #X obj 262 295 +; #X obj 289 402 s pd-voicecanvas; #X msg 289 382 obj 30 10 inlet; #X obj 262 315 t f f; #X obj 289 355 t b b; #X obj 289 335 sel 1; #X msg 262 201 0; #X obj 193 144 t b f f; #X obj 160 280 pipe 100; #X text 339 333 clear subpatch and create inlet; #X text 339 343 when starting from 1st voice; #X msg 443 212 set \$1; #X obj 346 477 f; #X text 371 476 set automatic voice offset; #X obj 406 21 bng 15 250 50 0 empty empty reset 17 7 0 10 -258113 -1 -1; #X msg 406 39 0; #X text 367 242 automatic voice number offset; #X obj 298 43 del 1000; #X connect 2 0 29 0; #X connect 3 0 27 0; #X connect 4 0 27 0; #X connect 5 0 27 0; #X connect 7 0 8 0; #X connect 7 0 43 0; #X connect 8 0 7 1; #X connect 8 0 35 0; #X connect 8 0 9 0; #X connect 9 0 11 0; #X connect 9 0 30 0; #X connect 10 0 7 0; #X connect 11 0 12 1; #X connect 12 0 10 0; #X connect 13 0 22 0; #X connect 13 1 14 0; #X connect 13 2 2 2; #X connect 13 2 47 1; #X connect 14 0 23 0; #X connect 15 0 25 0; #X connect 16 0 6 0; #X connect 16 1 5 0; #X connect 16 2 4 0; #X connect 16 3 3 0; #X connect 16 3 47 0; #X connect 17 0 42 0; #X connect 20 0 52 0; #X connect 21 0 17 1; #X connect 22 0 2 0; #X connect 23 0 2 1; #X connect 26 0 33 0; #X connect 29 0 28 0; #X connect 30 0 16 0; #X connect 33 0 17 0; #X connect 33 1 21 0; #X connect 33 2 34 0; #X connect 34 0 35 1; #X connect 35 0 38 0; #X connect 37 0 36 0; #X connect 38 0 13 0; #X connect 38 1 40 0; #X connect 39 0 37 0; #X connect 39 1 15 0; #X connect 40 0 39 0; #X connect 41 0 7 0; #X connect 42 0 41 0; #X connect 42 1 12 1; #X connect 42 2 9 1; #X connect 43 0 12 0; #X connect 46 0 34 0; #X connect 47 0 46 0; #X connect 49 0 50 0; #X connect 50 0 34 0; #X connect 50 0 15 0; #X connect 52 0 33 0;
#N canvas 601 430 450 300 10; #X obj 20 20 inlet;
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
