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

[Derek Kwan]

To chime in: 

I've done Stockhausen's Solo Nr. 19 and at least in the form scheme I
interpreted, there were at least 45.6 s delays, and in the other form
schemes there are bound to be longer delays... I suppose Stockhausen
isn't the normal use case though =). 

Derek

On Nov 23, Matt Barber wrote:
> I don't know about average, but I have heard "longest delay I use is maybe
> 30-60 seconds" a few times. The bass piece I presented at PdCon has up to
> 30 seconds of delay for a complex mensuration/transposition canon, and it
> would be very useful to be able to clear it for rehearsal purposes.
> 
> On Wed, Nov 23, 2016 at 12:35 PM, Jonathan Wilkes <jancsika at yahoo.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?
> >
> >
> >
> > Matt,
> > In the user reports, what is the average size of the buffer?  Are we
> > really talking about buffers greater than, say, 1000ms?
> >
> > This sounds like premature optimization to me.
> >
> > -Jonathan
> >
> >
> > 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 <https://lists.puredata.info/listinfo/pd-list>
> >
> >
> >
> > _______________________________________________
> > Pd-list at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> > listinfo/pd-list
> >
> >
> >

-- 
Derek Kwan
www.derekxkwan.com