The |set table-name( message lets us try a variety of these approaches and then we can make abstractions to wrap our favorite without doubling the memory for every [delwrite~] for a feature that most people won't use ever.
On Tue, Nov 22, 2016 at 1:17 PM, Matt Barber <[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? > > On Tue, Nov 22, 2016 at 7:32 AM, Ivica Bukvic <[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 >> [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/li >>> stinfo/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
