please show us (and miller) what it is about :) 2016-11-23 20:48 GMT-02:00 Orm Finnendahl < [email protected]>:
> 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 <[email protected] > <mailto:[email protected]>> 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 < > [email protected] <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>> 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 < > [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> > 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> > > > > [email protected] <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>> > > > > 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" < > [email protected] <mailto:[email protected]> <mailto: > [email protected] <mailto:[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] <mailto: > [email protected]> <mailto:[email protected] <mailto: > [email protected]>> 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>> > > > > > > > > > > > > > > > > _______________________________________________ > > > > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> 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>> > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > [email protected] <mailto:[email protected]> mailing > list > > > > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list <https://lists.puredata.info/ > listinfo/pd-list> > > > > > > > > > > > > _______________________________________________ > > > > [email protected] <mailto:[email protected]> mailing list > > > > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list <https://lists.puredata.info/ > listinfo/pd-list> > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > [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 > > > > _______________________________________________ > > [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 >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
