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 [email protected] www.performingarts.vt.edu disis.icat.vt.edu l2ork.icat.vt.edu ico.bukvic.net On Nov 22, 2016 00:07, "Matt Barber" <[email protected]> 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 > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/ > listinfo/pd-list > >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
