<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">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?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 22, 2015 at 4:00 PM, Jonathan Wilkes via Pd-list <span dir="ltr"><<a href="mailto:pd-list@lists.iem.at" target="_blank">pd-list@lists.iem.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div>In C, what's the overhead of having function_call(return array->x_size) instead</div><div>of array->x_size inside a perform routine?</div><div><br></div><div dir="ltr">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.</div><div dir="ltr"><br></div><div dir="ltr">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</div><div dir="ltr">to resize an array, which is a central feature for using objects like [tabplay~] and</div><div dir="ltr">'Put' menu arrays and [soundfiler], but in reality don't use it because</div><div dir="ltr">[[explanation of Pd's implementation details go here]]."</div><span class="HOEnZb"><font color="#888888"><div dir="ltr"><br></div><div dir="ltr">-Jonathan</div></font></span><div> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"> <div><br><br></div><div><div><div class="h5"><div dir="ltr"> <font size="2" face="Arial"> On Tuesday, September 22, 2015 12:05 PM, Roman Haefeli <<a href="mailto:reduzent@gmail.com" target="_blank">reduzent@gmail.com</a>> wrote:<br clear="none"> </font> </div>  <br clear="none"><br clear="none"> </div></div><div><div><div class="h5">On Sun, 2015-09-20 at 22:19 +0200, IOhannes m zmölnig wrote:<br clear="none">> On 09/17/2015 11:55 PM, Roman Haefeli wrote:<br clear="none">> <br clear="none">> > Is the time it takes to recalculate the graph only dependent on the<br clear="none">> > number of tilde-objects running in the current instance of Pd? If so, is<br clear="none">> > that a linear correlation? 10 times more tilde-objects means it takes 10<br clear="none">> > times as long to recalculate the graph?<br clear="none">> <br clear="none">> [skipping those]<br clear="none"><br clear="none">Simple tests suggests that the relation is linear. But maybe this<br clear="none">depends on the kind of graph? What I tested: I created 500 audio<br clear="none">processing abstractions dynamically and then I measured the time it<br clear="none">takes to send 'dsp 0, dsp 1' to pd. I did the same test again with 1000<br clear="none">instances and time doubled.<br clear="none"><br clear="none">> > Why is resizing tables so much slower, when tilde-objects are<br clear="none">> > referencing it? I noticed that even resizing very small tables can be a<br clear="none">> > cause for audio drop-outs. I wonder whether 'live-resizing' should be<br clear="none">> > avoided altogether.<br clear="none">> <br clear="none">> because the table-accessing objects will only check whether a table<br clear="none">> exists and of what size it is) when the DSP graph is re-calculated.<br clear="none">> this is a speed optimization, so those objects don't need to check the<br clear="none">> table existance/size in each signal block.<br clear="none">> the way how it is implemented is, that a table is marked as "being used<br clear="none">> in DSP processing" by a referencing object. as soon as such a table<br clear="none">> changes it's size (or is deleted), the DSP graph is notified - by means<br clear="none">> of recalculation.<br clear="none"><br clear="none">Now, after knowing all these facts, it seems unwise to do table resizing<br clear="none">at all, especially for quite small tables. With today's amounts of RAM<br clear="none">available, it seems wise to allocate enough at patch-loading time and<br clear="none">only utilize the necessary part of it.  <br clear="none"><br clear="none">> i guess the API could be changed to *unuse* a table (a simple refcounter<br clear="none">> should do), so that as soon as no DSP-object is referencing the object<br clear="none">> within the DSP-graph, any substantial change to it wouldn't trigger a<br clear="none">> DSP  graph recompilation.<br clear="none"><br clear="none">The ability to recompile only a partition of the graph in general would<br clear="none">be a huge gain, IMHO. The ability to resize arrays without recompilation<br clear="none">isn't that big an advantage, is it? It would allow for a little simpler<br clear="none">patching, though.<div><br clear="none"><br clear="none">Roman</div><br clear="none"></div></div><span class=""><div>_______________________________________________<br clear="none"><a rel="nofollow" shape="rect" href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list<br clear="none">UNSUBSCRIBE and account-management -> <a rel="nofollow" shape="rect" href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br clear="none"></div><br clear="none"><br clear="none"></span></div>  </div></div><div> </div></div><div>  </div></div></div></div><br>_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
<br></blockquote></div><br></div>