[PD] [delwrite~], or "what Pd operations are/should be realtime?"

[Alex]

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.

On Tue, Nov 22, 2016 at 1:17 PM, Matt Barber <brbrofsvl at gmail.com> wrote:

> 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?
>
> On Tue, Nov 22, 2016 at 7:32 AM, Ivica Bukvic <ico at vt.edu> wrote:
>
>> 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.
>>
>> Best,
>>
>> --
>> Ivica Ico Bukvic, D.M.A.
>> Associate Professor
>> Computer Music
>> ICAT Senior Fellow
>> Director -- DISIS, L2Ork
>> Virginia Tech
>> School of Performing Arts – 0141
>> Blacksburg, VA 24061
>> (540) 231-6139
>> ico at vt.edu
>> www.performingarts.vt.edu
>> disis.icat.vt.edu
>> l2ork.icat.vt.edu
>> ico.bukvic.net
>>
>> On Nov 22, 2016 00:07, "Matt Barber" <brbrofsvl at gmail.com> wrote:
>>
>>> Hi list; thanks for a wonderful PdCon (to Stevens and NYU people
>>> especially).
>>>
>>> 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.
>>>
>>> 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).
>>>
>>> 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.'
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> A broader topic for another time would be "what Pd operations are/should
>>> be realtime, and which are best at load time?"
>>>
>>> Thoughts?
>>>
>>> Matt
>>>
>>> _______________________________________________
>>> Pd-list at lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>>> stinfo/pd-list
>>>
>>>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20161122/666a492b/attachment-0001.html>