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@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 <reduz...@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@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list