please show us (and miller) what it is about :)
2016-11-23 20:48 GMT-02:00 Orm Finnendahl < orm.finnendahl@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@chnry.net
mailto:ch@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 delayI 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@yahoo.com mailto:jancsika@yahoo.com <mailto:jancsika@yahoo.com mailto:jancsika@yahoo.com>> wrote:
> In this case, I'd probably rather see a hybridapproach 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 thebuffer? 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@vt.edu mailto:ico@vt.edu <mailto:ico@vt.edu mailto:ico@vt.edu>> wrote:
For clear, I can imagine having a second emptymemory 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@vt.edu <mailto:ico@vt.edu> <mailto:ico@vt.eduwww.performingarts.vt.edu <http://www.performingarts.vt.edu%3E <http://www.performingarts.vt.edu/ < http://www.performingarts.vt.edu/%3E%3E
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@gmail.com mailto:brbrofsvl@gmail.com <mailto: brbrofsvl@gmail.com mailto:brbrofsvl@gmail.com>> wrote:
Hi list; thanks for a wonderful PdCon (toStevens and NYU people especially).
I had a quick chat with Miller after the "futureof 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 coulddisrupt 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 andcleared (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'sthat [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 anoption 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 "whatPd operations are/should be realtime, and which are best at load time?"
Thoughts? Matt ______________________________ _________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at mailto: 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 https://lists.puredata.info/ listinfo/pd-list>
_______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at><mailto:Pd-list@lists.iem.at mailto:Pd-list@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%3E%3E
_______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailinglist
UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list https://lists.puredata.info/ listinfo/pd-list
_______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> 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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> 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