Hmmm... I was umnder the impression that, except for the overhead of block~ and switch~ objects, there would be no difference in DSP execution time between a patch having lots of subpatches and one with the same amount of computation all thrown in one window. I haven't made any measurements but theoreticall at least there shouldn't be any difference.
cheers Miller On Wed, Aug 07, 2013 at 02:05:45AM +0100, Ed Kelly wrote: > There is another catch with the CPU usage, which I only learned about while > building a big libpd app. If you have subpatches within subpatches this is > usually not a problem with control data. But, it really helps a lot within a > patch if you put all the DSP objects on the same layer (i.e. without and > audio subpatches). > > Of course, the most CPU efficient patch will have no audio subpatches at all. > I think the reason is that subpatch audio is calculated in a block within the > subpatch, and this means a separate process from the master patch and takes > more CPU time. I'm not 100% sure that's the case, but intuitively it seems to > make sense. > > Cheers, > Ed > > Ninja Jamm - a revolutionary new music remix app from Ninja Tune and Seeper, > for iPhone and iPad > http://www.ninjajamm.com/ > > > Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! > http://sharktracks.co.uk/ > > > >________________________________ > > From: Mario Mey <mario...@gmail.com> > >To: J Oliver <jaime.oliv...@gmail.com> > >Cc: pd-list@iem.at > >Sent: Tuesday, 6 August 2013, 3:15 > >Subject: Re: [PD] How to reduce CPU use on unused subpatches-abstracts? > > > > > >Hi, J. Thanks for the response. Following some suggestion (from you, > >Maelstorm, Servando Barreiro), I made some tests. I took the dare to > >post your mail in the thread... maybe it's better to post there, if > >anyone has the same problem or just wants to learn. > > > >Here is the thread: http://puredata.hurleur.com/viewtopic.php?pid=37895 > > > >I answer your mail right there. Could you take a look? > > > >Anyway, as I writed there, I WILL CHECK IT AGAIN, AND I WILL DO SOME > >OTHER TESTS. > > > > > > > > > > > >El 05/08/13 10:36, J Oliver escribió: > >> Hi Mario, > >> > >> There is a thread somewhere about connections vs. s/r & throw/catch, don't > >> have time right now to search for it, but I'm sure it is there. If I > >> remember correctly the overhead is not that big and you don't want to be > >> connecting all that stuff by hand. > >> > >> In any case, there are other things to look for. > >> > >> If you are using graphics objects, or objects like env~ you might want to > >> bring down the refresh rate. Are there any [metro 1] or similar objects > >> lying around which you might have forgotten about? > >> > >> Do you have a lot of GOP? I am not sure this is entirely relevant, but it > >> might be worth researching... > >> > >> Also, control operations do take some cpu. do you have a big control layer? > >> > >> J > >> > >>> Thanks, Roman, but I'm already using [switch~] inside each FX, to stop > >>> processing the signal. I learned it some time ago, from here: > >>> > >>> http://puredata.hurleur.com/viewtopic.php?pid=35939#p35939 > >>> > >>> But I think that [receive~] and [throw~] are still using CPU. > >>> > >>> I didn't try to use inlet~ and outlet~, because I have to make 400 > >>> conections at hand... that's why I asking first. If it will work, I'll do > >>> it (or find a way to automatically do it) > >>> > >>> > >>> > >>> > >>> > >>> El 05/08/13 09:29, Roman Haefeli escribió: > >>>> Hi Mario > >>>> > >>>> Check [switch~] and its help patch. > >>>> > >>>> Roman > >>>> > >>>> > >>>> On Mon, 2013-08-05 at 09:03 -0300, Mario Mey wrote: > >>>>> Hi, there... I really need some help. > >>>>> > >>>>> I'm working on a looper-multi-effects (big) patch. It has more than, > >>>>> more or less, 100 stereo FXs. They are all inside the patch as > >>>>> abstracts. But, to avoid them to consume CPU, each one has a [switch~ 0] > >>>>> if it is not working. So, there're only two FX at a time, where the DSP > >>>>> is on. Something like this: > >>>>> > >>>>> Main patch: > >>>>> > >>>>> adc~ > >>>>> | \ > >>>>> | [s $0-pre-r] > >>>>> [s $0-pre-l] > >>>>> > >>>>> [catch~ $0-post-l] > >>>>> | [catch~ $0-post-r] > >>>>> | / > >>>>> [dac~] > >>>>> > >>>>> (the same for > >>>>> > >>>>> Each FX as file-abstracts (using [fx1 $0] to call them) inside the main > >>>>> patch: > >>>>> > >>>>> [r $1-pre-l] [r $1-pre-r] > >>>>> | / > >>>>> [The-FX-itself.....] > >>>>> | \ > >>>>> [throw~ $1-post-l] [throw~ $1-post-r] > >>>>> > >>>>> > >>>>> [0( [1( > >>>>> | / > >>>>> [switch~] > >>>>> > >>>>> > >>>>> This technics DOES work very well. Buuut... when having 100 FX at the > >>>>> same time (even not working), the CPU increase 15-20%. I repeat, > >>>>> there're only two FX working at the time. The rest are "turned-off". > >>>>> > >>>>> For now, the CPU use is: > >>>>> > >>>>> Ready-to-use, 2 FXs on, DSP on: 47% > >>>>> Recorded and playing 8 stereo-banks, 2 FXs being used, DSP on: 60 - 62% > >>>>> (I have quite a few XRUNS) > >>>>> Ready-to-use, 2 FXs on, DSP off: 7% > >>>>> > >>>>> As you can see, the non-signal processing is very low. > >>>>> > >>>>> What I think is that each FX is working when receiving and/or throwing > >>>>> signal (200 [receive~] and [throw~] objects)... even they are sending > >>>>> and/or processing nothing. > >>>>> > >>>>> Is there any other way to connect all the FXs to the main patch and to > >>>>> have a lower CPU consumption? > >>>>> > >>>>> Maybe [inlet~] and [outlet~] consume less CPU? (I should connect all the > >>>>> FX at hand... or find a aumotated way to do it) > >>>>> > >>>>> Thanks a lot. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Mario Mey > >>>>> > >>>>> _______________________________________________ > >>>>> Pd-list@iem.at mailing list > >>>>> UNSUBSCRIBE and account-management -> > >>>>> http://lists.puredata.info/listinfo/pd-list > >>>> > >>>> _______________________________________________ > >>>> Pd-list@iem.at mailing list > >>>> UNSUBSCRIBE and account-management -> > >>>> http://lists.puredata.info/listinfo/pd-list > >>> > >>> _______________________________________________ > >>> Pd-list@iem.at mailing list > >>> UNSUBSCRIBE and account-management -> > >>> http://lists.puredata.info/listinfo/pd-list > > > > > >_______________________________________________ > >Pd-list@iem.at mailing list > >UNSUBSCRIBE and account-management -> > >http://lists.puredata.info/listinfo/pd-list > > > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list