<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Oh... "<b>compile</b>"... I'm afraid of
that word. Once (during some days), I tried to compile Pd... but
with no good results.<br>
<br>
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.<br>
<br>
To profile Pd, is there an option in my version, or I have to
change code, like "#define PROFILE 1"?<br>
<br>
Cheers.<br>
<br>
<br>
El 07/08/13 16:53, Miller Puckette escribió:<br>
</div>
<blockquote cite="mid:20130807195314.GC7956@fuzz.ucsd.edu"
type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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: <a class="moz-txt-link-freetext" href="http://puredata.hurleur.com/viewtopic.php?pid=37430">http://puredata.hurleur.com/viewtopic.php?pid=37430</a>
(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ó:
</pre>
<blockquote type="cite">
<pre wrap="">On Wed, 2013-08-07 at 08:40 +0200, IOhannes m zmölnig wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 08/07/13 03:15, Miller Puckette wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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
_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a class="moz-txt-link-freetext" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a class="moz-txt-link-freetext" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>