[PD] [delwrite~], or "what Pd operations are/should be realtime?"
Alexandre Torres Porres
porres at gmail.com
Thu Nov 24 00:28:52 CET 2016
please show us (and miller) what it is about :)
2016-11-23 20:48 GMT-02:00 Orm Finnendahl <
orm.finnendahl at selma.hfmdk-frankfurt.de>:
> 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 <ch at chnry.net
> <mailto: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> <mailto: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> <mailto: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 <tel:%28540%29%20231-6139>
> > > > ico at vt.edu <mailto:ico at vt.edu> <mailto:ico at vt.edu
> <mailto:ico at 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" <
> brbrofsvl at gmail.com <mailto:brbrofsvl at gmail.com> <mailto:
> 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> <mailto: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 <https://lists.puredata.info/
> listinfo/pd-list>>
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>
> <mailto:Pd-list at lists.iem.at <mailto:Pd-list at 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 at lists.iem.at <mailto:Pd-list at 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 at lists.iem.at <mailto:Pd-list at 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 at lists.iem.at mailing list
> > > > UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
> > > >
> > >
> > > _______________________________________________
> > > Pd-list at lists.iem.at mailing list
> > > UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
> >
> > _______________________________________________
> > Pd-list at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/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/552cc5db/attachment-0001.html>
More information about the Pd-list
mailing list