Ha ha ha! Great. I'm not sure if that would ever have occurred to me. I didn't check rigorously, but does it move the write pointer back to where it started?
On Wed, Nov 23, 2016 at 1:40 PM, cyrille henry <c...@chnry.net> wrote: > > here is a vanilla way to clear a delay line. > cheers > c > > Le 23/11/2016 à 18:59, Matt Barber a écrit : > >> 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 <jancs...@yahoo.com >> <mailto:jancs...@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 <i...@vt.edu <mailto: >> i...@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 >> i...@vt.edu <mailto:i...@vt.edu> >> www.performingarts.vt.edu <http://www.performingarts.vt.edu/> >> disis.icat.vt.edu <http://disis.icat.vt.edu/> >> l2ork.icat.vt.edu <http://l2ork.icat.vt.edu/> >> ico.bukvic.net <http://ico.bukvic.net/> >> >> On Nov 22, 2016 00:07, "Matt Barber" <brbrof...@gmail.com >> <mailto:brbrof...@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@lists.iem.at <mailto:Pd-list@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@lists.iem.at <mailto:Pd-list@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@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li >> stinfo/pd-list >> >> > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/ > listinfo/pd-list > >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list