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

Matt Barber brbrofsvl at gmail.com
Wed Sep 23 04:50:27 CEST 2015


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150922/2b18431b/attachment.html>


More information about the Pd-list mailing list