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