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
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
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
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
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
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@gmail.com To: J Oliver jaime.oliver2@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
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/%C3%82
From: Mario Mey mariomey@gmail.com To: J Oliver jaime.oliver2@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
On 08/07/13 03:15, Miller Puckette wrote:
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.
i once did make measurements, and they showed that your assumption is correct.
or at least, it showed that it *was* correct at that time. this was on a P2-400MHz in 1998 or so, where a 16 channel spatialization patch would eat about 95% of the CPU - regardless of whether you used a single huge patch or organized the code into subpatches/abstractions.
eventually i went for using abstractions, and let the PC run at 95% for the 2 weeks show.
those were the times.
fgmasdr IOhannes
On Wed, 2013-08-07 at 08:40 +0200, IOhannes m zmölnig wrote:
On 08/07/13 03:15, Miller Puckette wrote:
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.
i once did make measurements, and they showed that your assumption is correct.
or at least, it showed that it *was* correct at that time. this was on a P2-400MHz in 1998 or so, where a 16 channel spatialization patch would eat about 95% of the CPU - regardless of whether you used a single huge patch or organized the code into subpatches/abstractions.
eventually i went for using abstractions, and let the PC run at 95% for the 2 weeks show.
I once made some informal tests to measure the overhead of [switch~]. It turned out it is quite big and if you're running hundreds or thousands instances of [switch~] you probably gain nothing by turning DSP off in subpatches. I don't know what the sweet spot is it seems using [switch~] is only worth for subpatches with a minimum amount of (DSP) complexity.
Roman
Thanks all for responding. After doing some tests, with suggestion from mail-list and from (Maelstorm), I want to show you the current structure of the complete patch (the same I wrote in forum):
/Main patch (meh_system.pd)// //• OSC messaging (for the tablet), input and output (EQ), BPM, metronome, Beats-to-rec, mode selector, etc.// //• FXs Console x2 (meh_console.pd)// //- - FXs & group selector, X-Y pad, Hold button, some signal and message redirection, etc. (subpatches)// //- - FXs groups x8 subpatches.// //- - - FXs abstracts x100 (fx-*.pd) ***// //• Sample Bank X8 (meh_bank.pd)// //- - Control subpatch [pd toggle-color-seteos]// //- - Sample - Resample subpatch [pd rec-sample-resample] ***// //- - Looping subpatch [pd rec-looping] ***// //- - Overdub subpatch [pd overdub] ***// //- - Playing subpatch [pd play]// // /The ones that have ***, have [switch~] inside. Using throw~/catch~ and s~/r~, the audio signals (right/left, sample/resample) get inside and outside all that subpatches-abstracts.
After adding switch~ inside them, *I got these RESULTS*:
/•/ Ready-to-use, 2 FXs on: *26%* (there are 2 FXs always on, although they are muted) /• /7 Banks playing, 1 Overdubbing, 2 FXs on: *32%* /• /DSP off: *6%*
As you can see, from 47%, I achieve 20% less than before. I think it is very good! But, with DSP off, I have 6%.... and there's no message processing. Maelstorm told me that it is too much for doing nothing... and, we think that it is because of having all that abstracts there. If I delete them, I have 1-2%.
The FX Console abstract (main patch has 2 of them) has all the FXs inside (100 items). Each FX has 4 to 8 abstracts inside (most of them are DIY2 effects, by Hardoff, but it also has a Panel abstract and some others). So... 2 * 100 * 6 = 1200 abstracs, more or less. Even if they are swithched off... THEY ARE THERE. Maybe this increase the CPU to 6%?
I repeat the WIP thread, where MEH-SYSTEM can be downloaded and tested: http://puredata.hurleur.com/viewtopic.php?pid=37430 (it uses externals from PdExt and the zip includes ipoke2~.pd_linux for 64bits (my version of ipoke~, by Katja), but it's only for overdubbing)
Thanks again.
El 07/08/13 04:57, Roman Haefeli escribió:
On Wed, 2013-08-07 at 08:40 +0200, IOhannes m zmölnig wrote:
On 08/07/13 03:15, Miller Puckette wrote:
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.
i once did make measurements, and they showed that your assumption is correct.
or at least, it showed that it *was* correct at that time. this was on a P2-400MHz in 1998 or so, where a 16 channel spatialization patch would eat about 95% of the CPU - regardless of whether you used a single huge patch or organized the code into subpatches/abstractions.
eventually i went for using abstractions, and let the PC run at 95% for the 2 weeks show.
I once made some informal tests to measure the overhead of [switch~]. It turned out it is quite big and if you're running hundreds or thousands instances of [switch~] you probably gain nothing by turning DSP off in subpatches. I don't know what the sweet spot is it seems using [switch~] is only worth for subpatches with a minimum amount of (DSP) complexity.
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Here's an idea ... perhaps your patch is generating hundreds of thousands of symbols to instantiate all the abstractions, and this sould be making gensym() run slowly. To test this possibility easily you could change
#define HASHSIZE 1024
to
#define HASHSIZE 65536
or so, recompile and see if that makes it run faster.
(Of course, I don't know why gensym() would be getting called periodically when Pd is idling; perhaps you could find that out by profiling Pd?)
cheers Miller
On Wed, Aug 07, 2013 at 04:32:30PM -0300, Mario Mey wrote:
Thanks all for responding. After doing some tests, with suggestion from mail-list and from (Maelstorm), I want to show you the current structure of the complete patch (the same I wrote in forum):
/Main patch (meh_system.pd)// //• OSC messaging (for the tablet), input and output (EQ), BPM, metronome, Beats-to-rec, mode selector, etc.// //• FXs Console x2 (meh_console.pd)// //- - FXs & group selector, X-Y pad, Hold button, some signal and message redirection, etc. (subpatches)// //- - FXs groups x8 subpatches.// //- - - FXs abstracts x100 (fx-*.pd) ***// //• Sample Bank X8 (meh_bank.pd)// //- - Control subpatch [pd toggle-color-seteos]// //- - Sample - Resample subpatch [pd rec-sample-resample] ***// //- - Looping subpatch [pd rec-looping] ***// //- - Overdub subpatch [pd overdub] ***// //- - Playing subpatch [pd play]// // /The ones that have ***, have [switch~] inside. Using throw~/catch~ and s~/r~, the audio signals (right/left, sample/resample) get inside and outside all that subpatches-abstracts.
After adding switch~ inside them, *I got these RESULTS*:
/•/ Ready-to-use, 2 FXs on: *26%* (there are 2 FXs always on, although they are muted) /• /7 Banks playing, 1 Overdubbing, 2 FXs on: *32%* /• /DSP off: *6%*
As you can see, from 47%, I achieve 20% less than before. I think it is very good! But, with DSP off, I have 6%.... and there's no message processing. Maelstorm told me that it is too much for doing nothing... and, we think that it is because of having all that abstracts there. If I delete them, I have 1-2%.
The FX Console abstract (main patch has 2 of them) has all the FXs inside (100 items). Each FX has 4 to 8 abstracts inside (most of them are DIY2 effects, by Hardoff, but it also has a Panel abstract and some others). So... 2 * 100 * 6 = 1200 abstracs, more or less. Even if they are swithched off... THEY ARE THERE. Maybe this increase the CPU to 6%?
I repeat the WIP thread, where MEH-SYSTEM can be downloaded and tested: http://puredata.hurleur.com/viewtopic.php?pid=37430 (it uses externals from PdExt and the zip includes ipoke2~.pd_linux for 64bits (my version of ipoke~, by Katja), but it's only for overdubbing)
Thanks again.
El 07/08/13 04:57, Roman Haefeli escribió:
On Wed, 2013-08-07 at 08:40 +0200, IOhannes m zmölnig wrote:
On 08/07/13 03:15, Miller Puckette wrote:
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.
i once did make measurements, and they showed that your assumption is correct.
or at least, it showed that it *was* correct at that time. this was on a P2-400MHz in 1998 or so, where a 16 channel spatialization patch would eat about 95% of the CPU - regardless of whether you used a single huge patch or organized the code into subpatches/abstractions.
eventually i went for using abstractions, and let the PC run at 95% for the 2 weeks show.
I once made some informal tests to measure the overhead of [switch~]. It turned out it is quite big and if you're running hundreds or thousands instances of [switch~] you probably gain nothing by turning DSP off in subpatches. I don't know what the sweet spot is it seems using [switch~] is only worth for subpatches with a minimum amount of (DSP) complexity.
Roman
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
Oh... "*compile*"... I'm afraid of that word. Once (during some days), I tried to compile Pd... but with no good results.
I will try to download the source, look for a easy-to-compile tutorial... but, if it takes me so much time, I think I'll go on with the current version of PdExt (0.43.4). Maybe I will try it later... or later... or even more later.
To profile Pd, is there an option in my version, or I have to change code, like "#define PROFILE 1"?
Cheers.
El 07/08/13 16:53, Miller Puckette escribió:
Here's an idea ... perhaps your patch is generating hundreds of thousands of symbols to instantiate all the abstractions, and this sould be making gensym() run slowly. To test this possibility easily you could change
#define HASHSIZE 1024
to
#define HASHSIZE 65536
or so, recompile and see if that makes it run faster.
(Of course, I don't know why gensym() would be getting called periodically when Pd is idling; perhaps you could find that out by profiling Pd?)
cheers Miller
On Wed, Aug 07, 2013 at 04:32:30PM -0300, Mario Mey wrote:
Thanks all for responding. After doing some tests, with suggestion from mail-list and from (Maelstorm), I want to show you the current structure of the complete patch (the same I wrote in forum):
/Main patch (meh_system.pd)// //• OSC messaging (for the tablet), input and output (EQ), BPM, metronome, Beats-to-rec, mode selector, etc.// //• FXs Console x2 (meh_console.pd)// //- - FXs & group selector, X-Y pad, Hold button, some signal and message redirection, etc. (subpatches)// //- - FXs groups x8 subpatches.// //- - - FXs abstracts x100 (fx-*.pd) ***// //• Sample Bank X8 (meh_bank.pd)// //- - Control subpatch [pd toggle-color-seteos]// //- - Sample - Resample subpatch [pd rec-sample-resample] ***// //- - Looping subpatch [pd rec-looping] ***// //- - Overdub subpatch [pd overdub] ***// //- - Playing subpatch [pd play]// // /The ones that have ***, have [switch~] inside. Using throw~/catch~ and s~/r~, the audio signals (right/left, sample/resample) get inside and outside all that subpatches-abstracts.
After adding switch~ inside them, *I got these RESULTS*:
/•/ Ready-to-use, 2 FXs on: *26%* (there are 2 FXs always on, although they are muted) /• /7 Banks playing, 1 Overdubbing, 2 FXs on: *32%* /• /DSP off: *6%*
As you can see, from 47%, I achieve 20% less than before. I think it is very good! But, with DSP off, I have 6%.... and there's no message processing. Maelstorm told me that it is too much for doing nothing... and, we think that it is because of having all that abstracts there. If I delete them, I have 1-2%.
The FX Console abstract (main patch has 2 of them) has all the FXs inside (100 items). Each FX has 4 to 8 abstracts inside (most of them are DIY2 effects, by Hardoff, but it also has a Panel abstract and some others). So... 2 * 100 * 6 = 1200 abstracs, more or less. Even if they are swithched off... THEY ARE THERE. Maybe this increase the CPU to 6%?
I repeat the WIP thread, where MEH-SYSTEM can be downloaded and tested: http://puredata.hurleur.com/viewtopic.php?pid=37430 (it uses externals from PdExt and the zip includes ipoke2~.pd_linux for 64bits (my version of ipoke~, by Katja), but it's only for overdubbing)
Thanks again.
El 07/08/13 04:57, Roman Haefeli escribió:
On Wed, 2013-08-07 at 08:40 +0200, IOhannes m zmölnig wrote:
On 08/07/13 03:15, Miller Puckette wrote:
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.
i once did make measurements, and they showed that your assumption is correct.
or at least, it showed that it *was* correct at that time. this was on a P2-400MHz in 1998 or so, where a 16 channel spatialization patch would eat about 95% of the CPU - regardless of whether you used a single huge patch or organized the code into subpatches/abstractions.
eventually i went for using abstractions, and let the PC run at 95% for the 2 weeks show.
I once made some informal tests to measure the overhead of [switch~]. It turned out it is quite big and if you're running hundreds or thousands instances of [switch~] you probably gain nothing by turning DSP off in subpatches. I don't know what the sweet spot is it seems using [switch~] is only worth for subpatches with a minimum amount of (DSP) complexity.
Roman
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
Oops, sorry - I think I'm leading you astray - it might take a long time to figure out how to patch sources adn recompile Pd if you aren't already habituated to compiling software.
Anyway, I don't really know that it's gensym() that's taking the 6% of your processor - that's just a guess. So I'm not sure what to try next...
Miller
On Wed, Aug 07, 2013 at 05:23:16PM -0300, Mario Mey wrote:
Oh... "*compile*"... I'm afraid of that word. Once (during some days), I tried to compile Pd... but with no good results.
I will try to download the source, look for a easy-to-compile tutorial... but, if it takes me so much time, I think I'll go on with the current version of PdExt (0.43.4). Maybe I will try it later... or later... or even more later.
To profile Pd, is there an option in my version, or I have to change code, like "#define PROFILE 1"?
Cheers.
El 07/08/13 16:53, Miller Puckette escribió:
Here's an idea ... perhaps your patch is generating hundreds of thousands of symbols to instantiate all the abstractions, and this sould be making gensym() run slowly. To test this possibility easily you could change
#define HASHSIZE 1024
to
#define HASHSIZE 65536
or so, recompile and see if that makes it run faster.
(Of course, I don't know why gensym() would be getting called periodically when Pd is idling; perhaps you could find that out by profiling Pd?)
cheers Miller
On Wed, Aug 07, 2013 at 04:32:30PM -0300, Mario Mey wrote:
Thanks all for responding. After doing some tests, with suggestion from mail-list and from (Maelstorm), I want to show you the current structure of the complete patch (the same I wrote in forum):
/Main patch (meh_system.pd)// //• OSC messaging (for the tablet), input and output (EQ), BPM, metronome, Beats-to-rec, mode selector, etc.// //• FXs Console x2 (meh_console.pd)// //- - FXs & group selector, X-Y pad, Hold button, some signal and message redirection, etc. (subpatches)// //- - FXs groups x8 subpatches.// //- - - FXs abstracts x100 (fx-*.pd) ***// //• Sample Bank X8 (meh_bank.pd)// //- - Control subpatch [pd toggle-color-seteos]// //- - Sample - Resample subpatch [pd rec-sample-resample] ***// //- - Looping subpatch [pd rec-looping] ***// //- - Overdub subpatch [pd overdub] ***// //- - Playing subpatch [pd play]// // /The ones that have ***, have [switch~] inside. Using throw~/catch~ and s~/r~, the audio signals (right/left, sample/resample) get inside and outside all that subpatches-abstracts.
After adding switch~ inside them, *I got these RESULTS*:
/•/ Ready-to-use, 2 FXs on: *26%* (there are 2 FXs always on, although they are muted) /• /7 Banks playing, 1 Overdubbing, 2 FXs on: *32%* /• /DSP off: *6%*
As you can see, from 47%, I achieve 20% less than before. I think it is very good! But, with DSP off, I have 6%.... and there's no message processing. Maelstorm told me that it is too much for doing nothing... and, we think that it is because of having all that abstracts there. If I delete them, I have 1-2%.
The FX Console abstract (main patch has 2 of them) has all the FXs inside (100 items). Each FX has 4 to 8 abstracts inside (most of them are DIY2 effects, by Hardoff, but it also has a Panel abstract and some others). So... 2 * 100 * 6 = 1200 abstracs, more or less. Even if they are swithched off... THEY ARE THERE. Maybe this increase the CPU to 6%?
I repeat the WIP thread, where MEH-SYSTEM can be downloaded and tested: http://puredata.hurleur.com/viewtopic.php?pid=37430 (it uses externals from PdExt and the zip includes ipoke2~.pd_linux for 64bits (my version of ipoke~, by Katja), but it's only for overdubbing)
Thanks again.
El 07/08/13 04:57, Roman Haefeli escribió:
On Wed, 2013-08-07 at 08:40 +0200, IOhannes m zmölnig wrote:
On 08/07/13 03:15, Miller Puckette wrote:
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.
i once did make measurements, and they showed that your assumption is correct.
or at least, it showed that it *was* correct at that time. this was on a P2-400MHz in 1998 or so, where a 16 channel spatialization patch would eat about 95% of the CPU - regardless of whether you used a single huge patch or organized the code into subpatches/abstractions.
eventually i went for using abstractions, and let the PC run at 95% for the 2 weeks show.
I once made some informal tests to measure the overhead of [switch~]. It turned out it is quite big and if you're running hundreds or thousands instances of [switch~] you probably gain nothing by turning DSP off in subpatches. I don't know what the sweet spot is it seems using [switch~] is only worth for subpatches with a minimum amount of (DSP) complexity.
Roman
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
Quoth Mario Mey, on 07/08/2013 20:32:
/./ Ready-to-use, 2 FXs on: *26%* (there are 2 FXs always on, although they are muted)
Are the effects that are always on [freeverb]? This could consume CPU, see these threads:
http://www.mail-archive.com/pd-list@iem.at/msg27143.html http://www.mail-archive.com/pd-list@iem.at/msg56905.html
The FX that are on are not always the same. The system lets you select 2 FX (one FX for each Console. It can be complex, having more than one. Eg: Delay/HPF). And, when the system starts, LPF are in both Consoles.
And no, I'm not using Freverb~. For reverb, I use st-pureverb, from DIY2 collection, by Hardoff.
Thanks.
El 08/08/13 05:41, James Dunn escribió:
Quoth Mario Mey, on 07/08/2013 20:32:
/./ Ready-to-use, 2 FXs on: *26%* (there are 2 FXs always on, although they are muted)
Are the effects that are always on [freeverb]? This could consume CPU, see these threads:
http://www.mail-archive.com/pd-list@iem.at/msg27143.html http://www.mail-archive.com/pd-list@iem.at/msg56905.html
On Wed, Aug 7, 2013 at 2:57 AM, Roman Haefeli reduzent@gmail.com wrote:
On Wed, 2013-08-07 at 08:40 +0200, IOhannes m zmölnig wrote:
On 08/07/13 03:15, Miller Puckette wrote:
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.
i once did make measurements, and they showed that your assumption is correct.
or at least, it showed that it *was* correct at that time. this was on a P2-400MHz in 1998 or so, where a 16 channel spatialization patch would eat about 95% of the CPU - regardless of whether you used a single huge patch or organized the code into subpatches/abstractions.
eventually i went for using abstractions, and let the PC run at 95% for the 2 weeks show.
I once made some informal tests to measure the overhead of [switch~]. It turned out it is quite big and if you're running hundreds or thousands instances of [switch~] you probably gain nothing by turning DSP off in subpatches. I don't know what the sweet spot is it seems using [switch~] is only worth for subpatches with a minimum amount of (DSP) complexity.
Roman
I don't know why this is so... When you add a [switch~] object, it adds a prologue and epilogue around the perform routines from each object in the subpatch. The runtime behavior is just like [block~], except when the patch is switched off, the switch prologue returns a pointer to the epilogue, instead of the next item in the dsp chain (don't quote me--I may need to read some code to find exact behavior, but that's the gist of it).
To me, this is pretty minimal and reasonable. Maybe there's an unintended consequence like cache misses when skipping over part of the dsp chain.
Chuck
Whoa!
I wonder - this was a libpd app I made, and it definitely made a difference putting all the DSP on one layer, but it was complex and I may have missed a trick here. It runs on an iPhone, and I wonder if there is a difference in how that works. resolving abstractions and subpatches with audio dropped the CPU load on an iPhone 4 from 132% to 71%.
Unless teh people writing the GUI fixed a big bad bug without telling me? I didn't seem like that at the time...if it wasn't the case I could have saved myself some pain.
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: Charles Z Henry czhenry@gmail.com To: Roman Haefeli reduzent@gmail.com Cc: pd-list pd-list@iem.at Sent: Wednesday, 7 August 2013, 21:48 Subject: Re: [PD] How to reduce CPU use on unused subpatches-abstracts?
On Wed, Aug 7, 2013 at 2:57 AM, Roman Haefeli reduzent@gmail.com wrote:
On Wed, 2013-08-07 at 08:40 +0200, IOhannes m zmölnig wrote:
On 08/07/13 03:15, Miller Puckette wrote:
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.
i once did make measurements, and they showed that your assumption is correct.
or at least, it showed that it *was* correct at that time. this was on a P2-400MHz in 1998 or so, where a 16 channel spatialization patch would eat about 95% of the CPU - regardless of whether you used a single huge patch or organized the code into subpatches/abstractions.
eventually i went for using abstractions, and let the PC run at 95% for the 2 weeks show.
I once made some informal tests to measure the overhead of [switch~]. It turned out it is quite big and if you're running hundreds or thousands instances of [switch~] you probably gain nothing by turning DSP off in subpatches. I don't know what the sweet spot is it seems using [switch~] is only worth for subpatches with a minimum amount of (DSP) complexity.
Roman
I don't know why this is so... When you add a [switch~] object, it adds a prologue and epilogue around the perform routines from each object in the subpatch. The runtime behavior is just like [block~], except when the patch is switched off, the switch prologue returns a pointer to the epilogue, instead of the next item in the dsp chain (don't quote me--I may need to read some code to find exact behavior, but that's the gist of it).
To me, this is pretty minimal and reasonable. Maybe there's an unintended consequence like cache misses when skipping over part of the dsp chain.
Chuck _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Charles Z Henry -
Ed Kelly -
IOhannes m zmölnig -
J Oliver -
James Dunn -
Mario Mey -
Miller Puckette -
Roman Haefeli