[PD] Understanding the mechanics of rebuilding Pd's DSP graph

Mon Nov 23 18:31:28 CET 2015

This is an enormously helpful discussion.
Just reading it in-depth now.
I think this should be summarized for inclusion into an FAQ.

I have some circuit design experience (many years ago).
I worked with netlists for Spice and other circuit simulators.

My first big program in C (1989?) was a program which
traversed a Spice deck (a linked list) and among other things,
found "orphaned networks" which didn't go anywhere.
It's a network which ultimately has no input and no outputs.

There is no need to electrically simulate such orphans
(this was in the 1980s when computers were mainframes
and time was really expensive), and there is no need to
make these into silicon. So such circuits are "optimized out"
(deleted.)

*My question is, does PD compute audio for an orphaned [osc~] with no
leads?*

*What about a complex "orphaned network" containing various tilde objects?*

*Are these computed? Or optimized out during compilation?*

What I've heard here from Jonathan is,
"adding any tilde object recreates the DSP graph".

So just placing an [osc~] with no wires recalculates the graph?
The would seem like a waste.

Furthermore-- this can even be improved. If I take an [osc~] and connect
a wire to an object which is part of an active DSP graph (not orphaned),
then we clearly need to recompile.

However, if I connect the [osc~] to an "orphaned network" (no I/O),
then this does not need to recompile the graph.

I imagine there must be a PD agent which looks at the objects you've just
instantiated
and decides whether the DSP graph should be recompiled.

Is there any room for improvement here?

Thanks,
BH

On Tue, Sep 22, 2015 at 11:19 PM, Jonathan Wilkes via Pd-list <
pd-list at lists.iem.at> wrote:

> Does [soundfiler] rebuild the dsp graph on read, or only if the -resize
> flag
> is used?  If its the latter then you can just set the right array size
> ahead of time.
> Then if you still get dropouts you'll know it's the blocking i/o doing it.
>
> -Jonathan
>
>
>
> On Tuesday, September 22, 2015 10:50 PM, Matt Barber <brbrofsvl at gmail.com>
> wrote:
>
>
> There's nothing wrong per se with resizing an array -- but there are good
> reasons not to do it while a patch is running after a [tab*] object has
> referred to it. I have myself only noticed audio dropouts when I'm resizing
> a table with soundfiler; I thought it must have been a disk-access
> bottleneck (soundfiler runs synchronously, yes?), but it would make sense
> if it in very large patches that a resize triggering a DSP recalc could do
> it. Though, then wouldn't adding any tilde object do the same?
>
> On Tue, Sep 22, 2015 at 4:00 PM, Jonathan Wilkes via Pd-list <
> pd-list at lists.iem.at> wrote:
>
> In C, what's the overhead of having function_call(return array->x_size)
> instead
> of array->x_size inside a perform routine?
>
> If that's not significant, it seems like it'd be better to over-allocate
> the array at creation/resize time and report the requested size to the
> user.  That way reallocation (and dsp-rebuilding) is only necessary if
> there's a substantial size change, or if the array is used by an external
> that uses the old API.
>
> That's certainly more difficult to do than just rebuilding the graph on
> every resizing.  But to me it's preferable to telling new users, "Here's how
> to resize an array, which is a central feature for using objects like
> [tabplay~] and
> 'Put' menu arrays and [soundfiler], but in reality don't use it because
> [[explanation of Pd's implementation details go here]]."
>
> -Jonathan
>
>
> On Tuesday, September 22, 2015 12:05 PM, Roman Haefeli <reduzent at gmail.com>
> wrote:
>
>
> On Sun, 2015-09-20 at 22:19 +0200, IOhannes m zmölnig wrote:
> > On 09/17/2015 11:55 PM, Roman Haefeli wrote:
> >
> > > Is the time it takes to recalculate the graph only dependent on the
> > > number of tilde-objects running in the current instance of Pd? If so,
> is
> > > that a linear correlation? 10 times more tilde-objects means it takes
> 10
> > > times as long to recalculate the graph?
> >
> > [skipping those]
>
> Simple tests suggests that the relation is linear. But maybe this
> depends on the kind of graph? What I tested: I created 500 audio
> processing abstractions dynamically and then I measured the time it
> takes to send 'dsp 0, dsp 1' to pd. I did the same test again with 1000
> instances and time doubled.
>
> > > Why is resizing tables so much slower, when tilde-objects are
> > > referencing it? I noticed that even resizing very small tables can be a
> > > cause for audio drop-outs. I wonder whether 'live-resizing' should be
> > > avoided altogether.
> >
> > because the table-accessing objects will only check whether a table
> > exists and of what size it is) when the DSP graph is re-calculated.
> > this is a speed optimization, so those objects don't need to check the
> > table existance/size in each signal block.
> > the way how it is implemented is, that a table is marked as "being used
> > in DSP processing" by a referencing object. as soon as such a table
> > changes it's size (or is deleted), the DSP graph is notified - by means
> > of recalculation.
>
> Now, after knowing all these facts, it seems unwise to do table resizing
> at all, especially for quite small tables. With today's amounts of RAM
> available, it seems wise to allocate enough at patch-loading time and
> only utilize the necessary part of it.
>
> > i guess the API could be changed to *unuse* a table (a simple refcounter
> > should do), so that as soon as no DSP-object is referencing the object
> > within the DSP-graph, any substantial change to it wouldn't trigger a
> > DSP  graph recompilation.
>
> The ability to recompile only a partition of the graph in general would
> be a huge gain, IMHO. The ability to resize arrays without recompilation
> isn't that big an advantage, is it? It would allow for a little simpler
> patching, though.
>
>
> Roman
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>

-- 
--
May you, and all beings
be happy and free from suffering :)
-- ancient Buddhist Prayer (Metta)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151123/6d46f03c/attachment.html>