[PD] [delwrite~], or "what Pd operations are/should be realtime?"
Matt Barber
brbrofsvl at gmail.com
Wed Nov 23 19:47:43 CET 2016
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 <ch at 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 <jancsika at yahoo.com
>> <mailto:jancsika at 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 <ico at vt.edu <mailto:
>> ico at 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
>> ico at vt.edu <mailto:ico at 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" <brbrofsvl at gmail.com
>> <mailto:brbrofsvl at 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 at lists.iem.at <mailto:Pd-list at 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 at lists.iem.at <mailto:Pd-list at 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 at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>> stinfo/pd-list
>>
>>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20161123/2871e3a2/attachment.html>
More information about the Pd-list
mailing list