Hi, FYI, I patched vanilla pd when I prepared performances of Nono pieces by introducing a clear method into the delwrite~ a couple of years ago to speed up restarts at rehearsals. I already thought about proposing this as a change to the vanilla sources. It's quite trivial and I can send the patch if Miller is interested...
-- Orm Am Mittwoch, den 23. November 2016 um 20:25:48 Uhr (+0100) schrieb cyrille henry: > on my computer, using this patch, I can clear a 10mn delay with no click > (using a 50ms audio setting buffer)... > > > Le 23/11/2016 à 20:07, cyrille henry a écrit : > > i don't understand the question. > > delwrite/delread emulate a tape delay, where the write pointer did not > > move, it's the read pointer (delread) that can move. > > > > anyway, I did not fully test this patch neither. I just made it because I > > prefer to patch than to complain. > > > > cheers > > c > > > > > > Le 23/11/2016 à 19:47, Matt Barber a écrit : > > > 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 > > > <mailto: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> > > > <mailto: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> <mailto: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 <tel:%28540%29%20231-6139> > > > i...@vt.edu <mailto:i...@vt.edu> <mailto:i...@vt.edu > > > <mailto:i...@vt.edu>> > > > www.performingarts.vt.edu > > > <http://www.performingarts.vt.edu> <http://www.performingarts.vt.edu/ > > > <http://www.performingarts.vt.edu/>> > > > disis.icat.vt.edu <http://disis.icat.vt.edu> > > > <http://disis.icat.vt.edu/> > > > l2ork.icat.vt.edu <http://l2ork.icat.vt.edu> > > > <http://l2ork.icat.vt.edu/> > > > ico.bukvic.net <http://ico.bukvic.net> > > > <http://ico.bukvic.net/> > > > > > > On Nov 22, 2016 00:07, "Matt Barber" <brbrof...@gmail.com > > > <mailto:brbrof...@gmail.com> <mailto: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> > > > <mailto: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 > > > <https://lists.puredata.info/listinfo/pd-list>> > > > > > > > > > > > > _______________________________________________ > > > Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> > > > <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> mailing list > > > UNSUBSCRIBE and account-management -> > > > https://lists.puredata.info/listinfo/pd-list > > > <https://lists.puredata.info/listinfo/pd-list> > > > <https://lists.puredata.info/listinfo/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/listinfo/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/listinfo/pd-list > > > <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 > > > > > > > _______________________________________________ > > 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 _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
