[PD] How to reduce CPU use on unused subpatches-abstracts?

Wed Aug 7 03:15:18 CEST 2013

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 <mariomey at gmail.com>
> >To: J Oliver <jaime.oliver2 at gmail.com> 
> >Cc: pd-list at 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 at iem.at mailing list
> >>>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> >>>>
> >>>> _______________________________________________
> >>>> Pd-list at iem.at mailing list
> >>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> >>>
> >>> _______________________________________________
> >>> Pd-list at iem.at mailing list
> >>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> >
> >
> >_______________________________________________
> >Pd-list at iem.at mailing list
> >UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> >
> >

> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list