<div dir="ltr">The |set table-name( message lets us try a variety of these approaches and then we can make abstractions to wrap our favorite without doubling the memory for every [delwrite~] for a feature that most people won't use ever.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 22, 2016 at 1:17 PM, Matt Barber <span dir="ltr"><<a href="mailto:brbrofsvl@gmail.com" target="_blank">brbrofsvl@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">In this case, I'd probably rather see a hybrid approach where a second buffer is already waiting. Then you could give "clear 300", and it would switch to the empty buffer immediately while guaranteeing that the other one is clear in 300ms. But this is maybe too complicated for the user, and uses too much memory?</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 22, 2016 at 7:32 AM, Ivica Bukvic <span dir="ltr"><<a href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">For clear, I can imagine having a second empty memory buffer being created while delay continues to use the populated one until the memory allocation is complete. At that point a simple change in the pointer should suffice, after which the old buffer gets trashed. This would break determinacy, so perhaps a separate argument could be used to enable this option in which case the object could get another outlet that sends a bang when the procedure is complete.</p>
<p dir="ltr">Best,</p>
<p dir="ltr">-- <br>
Ivica Ico Bukvic, D.M.A.<br>
Associate Professor<br>
Computer Music<br>
ICAT Senior Fellow<br>
Director -- DISIS, L2Ork<br>
Virginia Tech<br>
School of Performing Arts – 0141<br>
Blacksburg, VA 24061<br>
<a href="tel:%28540%29%20231-6139" value="+15402316139" target="_blank">(540) 231-6139</a><br>
<a href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a><br>
<a href="http://www.performingarts.vt.edu" target="_blank">www.performingarts.vt.edu</a><br>
<a href="http://disis.icat.vt.edu" target="_blank">disis.icat.vt.edu</a><br>
<a href="http://l2ork.icat.vt.edu" target="_blank">l2ork.icat.vt.edu</a><br>
<a href="http://ico.bukvic.net" target="_blank">ico.bukvic.net</a></p>
<div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-3280399305541065714h5">On Nov 22, 2016 00:07, "Matt Barber" <<a href="mailto:brbrofsvl@gmail.com" target="_blank">brbrofsvl@gmail.com</a>> wrote:<br type="attribution"></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_-3280399305541065714h5"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Hi list; thanks for a wonderful PdCon (to Stevens and NYU people especially).</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">I had a quick chat with Miller after the "future of Pd" discussion. I told him there is one feature I've heard Pd users ask for many times: a "clear" method for [delwrite~]. A [delwrite~] resize method is something I've heard brought up a number of times as well, but I didn't mention it.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Each of these has a runtime cost that could disrupt the realtime dsp calculation. Clearing a [delwrite~] is a linear-time operation, and for long delay lines it could cause audio dropouts; resizing is more problematic because it's not clear what to do with samples already in the delay line – probably it would need to be cleared as well, which would take even more time (although there is already an indirect resize function when sample rate is changed).</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">On the other hand, Pd arrays can be resized and cleared (const 0) ad libitum, which is more or less the same operation. We usually tell users 'do this at your own risk when computing audio.'</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">So what is the main difference? I think it's that [delwrite~] is a tilde object that is supposed not to cause dropouts on its own. If clearing it could cause a dropout, there are reasons for thinking of that as a bug rather than simply a risk.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Is there a compromise procedure? We could add an option to spread the clearing out over time. For instance "clear 5000" would mean "clear the delay line over the next 5000 ms." A second argument would let the user choose whether to preferentially preserve the most recent samples or the oldest samples. Given only a time argument, default would be to preserve oldest samples (less work has to be done overall since the write pointer would also be filling the line with zeroes). Without a time argument (i.e. "clear" with no arguments), the default would be to clear it immediately with the understanding that there could be a possible dropout.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">A broader topic for another time would be "what Pd operations are/should be realtime, and which are best at load time?"</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Thoughts?</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Matt</div></div>
<br></div></div>______________________________<wbr>_________________<br>
<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/li<wbr>stinfo/pd-list</a><br>
<br></blockquote></div></div>
</blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
<a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/<wbr>listinfo/pd-list</a><br>
<br></blockquote></div><br></div>