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