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 <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> 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 > > www.performingarts.vt.edu > > disis.icat.vt.edu > > l2ork.icat.vt.edu > > ico.bukvic.net > > > > On Nov 22, 2016 00:07, "Matt Barber" <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 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/ > > listinfo/pd-list > > > > > > -- Derek Kwan www.derekxkwan.com _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list