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

Ivica Bukvic ico at vt.edu
Tue Nov 22 13:32:01 CET 2016

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.


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

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/
> listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20161122/bc21c0d2/attachment.html>

More information about the Pd-list mailing list