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

[Matt Barber]

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