<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_1_1442977203291_3539">Does [soundfiler] rebuild the dsp graph on read, or only if the -resize flag</div><div id="yui_3_16_0_1_1442977203291_3967" dir="ltr">is used? If its the latter then you can just set the right array size ahead of time.</div><div id="yui_3_16_0_1_1442977203291_3841" dir="ltr">Then if you still get dropouts you'll know it's the blocking i/o doing it.</div><div id="yui_3_16_0_1_1442977203291_4059" dir="ltr"><br></div><div id="yui_3_16_0_1_1442977203291_4099" dir="ltr">-Jonathan<br></div> <br><div class="qtdSeparateBR"><br><br></div><div style="display: block;" class="yahoo_quoted"> <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 dir="ltr"> <font face="Arial" size="2"> On Tuesday, September 22, 2015 10:50 PM, Matt Barber <brbrofsvl@gmail.com> wrote:<br> </font> </div> <br><br> <div class="y_msg_container"><div id="yiv4427245962"><div><div dir="ltr"><div class="yiv4427245962gmail_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="yiv4427245962gmail_extra"><br clear="none"><div class="yiv4427245962gmail_quote">On Tue, Sep 22, 2015 at 4:00 PM, Jonathan Wilkes via Pd-list <span dir="ltr"><<a rel="nofollow" shape="rect" ymailto="mailto:pd-list@lists.iem.at" target="_blank" href="mailto:pd-list@lists.iem.at">pd-list@lists.iem.at</a>></span> wrote:<br clear="none"><blockquote class="yiv4427245962gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="yiv4427245962yqt3231400945" id="yiv4427245962yqt48267"><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 clear="none"></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 clear="none"></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="yiv4427245962HOEnZb"><font color="#888888"></font></span><div dir="ltr"><br clear="none"></div><div dir="ltr">-Jonathan</div><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 clear="none"><br clear="none"></div><div><div><div class="yiv4427245962h5"><div dir="ltr"> <font face="Arial" size="2"> On Tuesday, September 22, 2015 12:05 PM, Roman Haefeli <<a rel="nofollow" shape="rect" ymailto="mailto:reduzent@gmail.com" target="_blank" href="mailto:reduzent@gmail.com">reduzent@gmail.com</a>> wrote:<br clear="none"> </font> </div> <br clear="none"><br clear="none"> </div></div><div><div><div class="yiv4427245962h5">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="yiv4427245962"></span><div>_______________________________________________<br clear="none"><a rel="nofollow" shape="rect" ymailto="mailto:Pd-list@lists.iem.at" target="_blank" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br clear="none">UNSUBSCRIBE and account-management -> <a rel="nofollow" shape="rect" target="_blank" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br clear="none"></div><br clear="none"><br clear="none"></div> </div></div><div> </div></div><div> </div></div></div></div></div><br clear="none">_______________________________________________<br clear="none">
<a rel="nofollow" shape="rect" ymailto="mailto:Pd-list@lists.iem.at" target="_blank" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br clear="none">
UNSUBSCRIBE and account-management -> <a rel="nofollow" shape="rect" target="_blank" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br clear="none">
<br clear="none"></blockquote></div><br clear="none"></div></div></div><br><br></div> </div> </div> </div></div></body></html>