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
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,
yeah, when miller said he takes his time cause he wants to be sure what to do I immediately remember about this request of mine :) but I had to leave the session, anyway, good call matt ;)
there should really be a 'set' method for delread~
+1
btw, there is a clear method for the delay line in pd-l2ork, undocumented, but there, not sure how it is done, but I remember I showed it to this list asking if that was doing it ok in realtime?
cheers
2016-11-22 11:28 GMT-05:00 Alexandre Torres Porres porres@gmail.com:
yeah, when miller said he takes his time cause he wants to be sure what to do I immediately remember about this request of mine :) but I had to leave the session, anyway, good call matt ;)
there should really be a 'set' method for delread~
+1
btw, there is a clear method for the delay line in pd-l2ork, undocumented, but there, not sure how it is done, but I remember I showed it to this list asking if that was doing it ok in realtime?
That patch was authored by Mathieu Bouchard. I asked him to post it on the patch tracker, so he did:https://sourceforge.net/p/pure-data/patches/369/ Here's the original pd user list thread that led to its authorship:http://www.mail-archive.com/pd-list@iem.at/msg41895.html
At some point I submitted the patch to Ivica for inclusion in Pd-l2ork. He included it and said, "Thanks!" To continue the saga, I added an issue about documenting this feature:https://github.com/pd-l2ork/pd/issues/43
If you have a documentation fix I'll merge it into Purr Data, too.
Best, Jonathan
cheers
2016-11-22 11:28 GMT-05:00 Alexandre Torres Porres porres@gmail.com:
yeah, when miller said he takes his time cause he wants to be sure what to do I immediately remember about this request of mine :) but I had to leave the session, anyway, good call matt ;) there should really be a 'set' method for delread~
+1
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Based on the Mathieu's patch it is a simple memset call which as far as I can tell should take very little time even with large buffers. Of course, YMMV based on how powerful is the CPU and how much stuff it is supposed to juggle at the same time.
Best,
Ico
On 11/22/2016 11:29 AM, Alexandre Torres Porres wrote:
btw, there is a clear method for the delay line in pd-l2ork, undocumented, but there, not sure how it is done, but I remember I showed it to this list asking if that was doing it ok in realtime?
cheers
2016-11-22 11:28 GMT-05:00 Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com>:
yeah, when miller said he takes his time cause he wants to be sure what to do I immediately remember about this request of mine :) but I had to leave the session, anyway, good call matt ;) there should really be a 'set' method for delread~ +1
On 2016-11-22 17:29, Alexandre Torres Porres wrote:
there is a clear method for the delay line in pd-l2ork, undocumented, but there, not sure how it is done,
implementing the "clear" is trivial.
however, afaiu this is not the concern that miller has. the concern is, that you are breaking some realtime assumptions (deterministic, bound execution time), with *any* possible implementation.
personally, i don't think that the broken assumption would ever be a problem in real world. (it's not that you couln't build a clearable delay-line in Pd anyhow (using abstractions), which could break those assumptions in even worse ways)
fgamsdr IOhannes
On Wed, 2016-11-23 at 10:48 +0100, IOhannes m zmoelnig wrote:
On 2016-11-22 17:29, Alexandre Torres Porres wrote:
there is a clear method for the delay line in pd-l2ork, undocumented, but there, not sure how it is done,
implementing the "clear" is trivial.
however, afaiu this is not the concern that miller has. the concern is, that you are breaking some realtime assumptions (deterministic, bound execution time), with *any* possible implementation.
This concern seems a bit arbitrary. Someone already brought up the 'const <number>' sent to array example, which is probably a similar operation and already exists. Also, I once found out that resizing arrays that are accessed by tilde objects causes a recalculation of the DSP graph and this leads to drop-outs, too (but might be only noticed when having a huge set of patches loaded so that the DSP graph is very big). Since I found out about this, I try to avoid resizing arrays altogether.
Personally, I think a programming language shouldn't second-guess what is sensible for a programmer to do and what not. It should be up to the programmer whether they want to risk a drop-out or not.
BTW, how can you implement a 'clear' method with abstractions?
Roman
On Wed, Nov 23, 2016 at 11:22 AM, Roman Haefeli reduzent@gmail.com wrote:
On Wed, 2016-11-23 at 10:48 +0100, IOhannes m zmoelnig wrote:
On 2016-11-22 17:29, Alexandre Torres Porres wrote:
there is a clear method for the delay line in pd-l2ork, undocumented, but there, not sure how it is done,
implementing the "clear" is trivial.
however, afaiu this is not the concern that miller has. the concern is, that you are breaking some realtime assumptions (deterministic, bound execution time), with *any* possible implementation.
This concern seems a bit arbitrary. Someone already brought up the 'const <number>' sent to array example, which is probably a similar operation and already exists. Also, I once found out that resizing arrays that are accessed by tilde objects causes a recalculation of the DSP graph and this leads to drop-outs, too (but might be only noticed when having a huge set of patches loaded so that the DSP graph is very big). Since I found out about this, I try to avoid resizing arrays altogether.
Personally, I think a programming language shouldn't second-guess what is sensible for a programmer to do and what not. It should be up to the programmer whether they want to risk a drop-out or not.
BTW, how can you implement a 'clear' method with abstractions?
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Not vanilla, but I use a sound-on-sound looper with [cyclone/poke~] writing into the buffers and [tabread4~] reading.
If [delwrite~] would have a 'const' or 'clear' method I would use that instead, if only because [cyclone/poke~] doesn't have a subnormals-eliminator.
By the way I haven't noticed problems when flushing large buffers (over 1 million samples total) in this looper while other audio is still running.
Katja
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 ico@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@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" brbrofsvl@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
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 brbrofsvl@gmail.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?
On Tue, Nov 22, 2016 at 7:32 AM, Ivica Bukvic ico@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@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" brbrofsvl@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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
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@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@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" brbrofsvl@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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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@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@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@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" brbrofsvl@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
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 jancsika@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@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@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" brbrofsvl@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
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@yahoo.com mailto:jancsika@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@vt.edu <mailto:ico@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@vt.edu <mailto:ico@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@gmail.com <mailto:brbrofsvl@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 <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> _______________________________________________ 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
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 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@yahoo.com mailto:jancsika@yahoo.com> wrote:
> In this case, I'd probably rather see a hybrid approach where asecond 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 wereally 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>> wrote:
For clear, I can imagine having a second empty memory bufferbeing 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@vt.edu mailto:ico@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@gmail.commailto:brbrofsvl@gmail.com> wrote:
Hi list; thanks for a wonderful PdCon (to Stevens and NYUpeople 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 therealtime 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 tospread 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 operationsare/should be realtime, and which are best at load time?"
Thoughts? Matt ______________________________ _________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailinglist UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list < https://lists.puredata.info/listinfo/pd-list%3E
_______________________________________________ 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/li stinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
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 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@yahoo.com <mailto:jancsika@yahoo.com> <mailto:jancsika@yahoo.com <mailto:jancsika@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@vt.edu <mailto:ico@vt.edu> <mailto:ico@vt.edu <mailto:ico@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@vt.edu <mailto:ico@vt.edu> <mailto:ico@vt.edu <mailto:ico@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@gmail.com <mailto:brbrofsvl@gmail.com> <mailto:brbrofsvl@gmail.com <mailto:brbrofsvl@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 <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>> _______________________________________________ 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 <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
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 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@yahoo.com <mailto:jancsika@yahoo.com> <mailto:jancsika@yahoo.com <mailto:jancsika@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@vt.edu <mailto:ico@vt.edu> <mailto:ico@vt.edu <mailto:ico@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@vt.edu <mailto:ico@vt.edu> <mailto:ico@vt.edu <mailto:ico@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@gmail.com <mailto:brbrofsvl@gmail.com> <mailto:brbrofsvl@gmail.com <mailto:brbrofsvl@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 <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>> _______________________________________________ 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 <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
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 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@yahoo.com <mailto:jancsika@yahoo.com> <mailto:jancsika@yahoo.com <mailto:jancsika@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@vt.edu <mailto:ico@vt.edu> <mailto:ico@vt.edu <mailto:ico@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@vt.edu <mailto:ico@vt.edu> <mailto:ico@vt.edu <mailto:ico@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@gmail.com <mailto:brbrofsvl@gmail.com> <mailto:brbrofsvl@gmail.com <mailto:brbrofsvl@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 <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>> _______________________________________________ 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 <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
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
Am Mittwoch, den 23. November 2016 um 21:28:52 Uhr (-0200) schrieb Alexandre Torres Porres:
please show us (and miller) what it is about :)
patch against vanilla pd is attached. Also a small usage example.
Although it's trivial, adding it to pd would be quite useful for me especially since it doesn't break any backwards compatibility. In rehearsals of pieces with long delays/reverbs it's a real time-saver ;-)
-- Orm
wouldn’t memset be faster?
On 24 Nov 2016, at 10:41, Orm Finnendahl orm.finnendahl@selma.hfmdk-frankfurt.de wrote:
Am Mittwoch, den 23. November 2016 um 21:28:52 Uhr (-0200) schrieb Alexandre Torres Porres:
please show us (and miller) what it is about :)
patch against vanilla pd is attached. Also a small usage example.
Although it's trivial, adding it to pd would be quite useful for me especially since it doesn't break any backwards compatibility. In rehearsals of pieces with long delays/reverbs it's a real time-saver ;-)
-- Orm <d_delay.patch><delwrite~-clear-example.pd>_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
wouldn’t memset be faster?
No. But only because compilers are smart enough to spot artisinally-rolled, prematurely unoptimized code and just use memset instead. -Jonathan
On 24 Nov 2016, at 10:41, Orm Finnendahl orm.finnendahl@selma.hfmdk-frankfurt.de wrote:
Am Mittwoch, den 23. November 2016 um 21:28:52 Uhr (-0200) schrieb Alexandre Torres Porres:
please show us (and miller) what it is about :)
patch against vanilla pd is attached. Also a small usage example.
Although it's trivial, adding it to pd would be quite useful for me especially since it doesn't break any backwards compatibility. In rehearsals of pieces with long delays/reverbs it's a real time-saver ;-)
-- Orm <d_delay.patch><delwrite~-clear-example.pd>_______________________________________________ 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
coming from arduino, it is definitely not optimized there, but nice to know!
On 24 Nov 2016, at 17:41, Jonathan Wilkes jancsika@yahoo.com wrote:
wouldn’t memset be faster?
No. But only because compilers are smart enough to spot artisinally-rolled, prematurely unoptimized code and just use memset instead.
-Jonathan
On 24 Nov 2016, at 10:41, Orm Finnendahl <orm.finnendahl@selma.hfmdk-frankfurt.de mailto:orm.finnendahl@selma.hfmdk-frankfurt.de> wrote:
Am Mittwoch, den 23. November 2016 um 21:28:52 Uhr (-0200) schrieb Alexandre Torres Porres:
please show us (and miller) what it is about :)
patch against vanilla pd is attached. Also a small usage example.
Although it's trivial, adding it to pd would be quite useful for me especially since it doesn't break any backwards compatibility. In rehearsals of pieces with long delays/reverbs it's a real time-saver ;-)
-- Orm <d_delay.patch><delwrite~-clear-example.pd>_______________________________________________ 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 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
I don't know about average, but I have heard "longest delay I use is maybe 30-60 seconds" a few times.
In a case where the user wants a "clear" method that works in realtime without dropouts?
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.
When the performer stops, do you want the DSP graph to continue unabated? Or could you ramp down and duck out of dsp computation to trigger the "clear" method? -Jonathan
On Wed, Nov 23, 2016 at 12:35 PM, Jonathan Wilkes jancsika@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@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@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" brbrofsvl@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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
Yeah, this is the kind of thing I think about often. The thing is, if "clear" is included with [delwrite~], and people are using 30-60 seconds of delay, people are going to use "clear" in those circumstances at some point.
For the piece, sure – ramping down, switch~ing off, and clearing would be great. Sometimes you want to start in the middle, and you'd rather have zeroes than detritus from the last pass in the buffer.
On Wed, Nov 23, 2016 at 2:12 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
I don't know about average, but I have heard "longest delay I use is
maybe 30-60 seconds" a few times.
In a case where the user wants a "clear" method that works in realtime without dropouts?
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.
When the performer stops, do you want the DSP graph to continue unabated? Or could you ramp down and duck out of dsp computation to trigger the "clear" method?
-Jonathan
On Wed, Nov 23, 2016 at 12:35 PM, Jonathan Wilkes jancsika@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@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@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" brbrofsvl@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 https://lists.puredata.info/listinfo/pd-list
Yeah, this is the kind of thing I think about often. The thing is, if "clear" is included with [delwrite~], and people are using 30-60 seconds of delay, people are going to use "clear" in those circumstances at some point.
If that turns out to be then it's a matter of revising the algo to "smear" the work of zeroing across the affected blocks, like Cyrille is doing. Or am I missing something?
For the piece, sure – ramping down, switch~ing off, and clearing would be great. Sometimes you want to start in the middle, and you'd rather have zeroes than detritus from the last pass in the buffer.
Makes sense. -Jonathan
On Wed, Nov 23, 2016 at 2:12 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
I don't know about average, but I have heard "longest delay I use is maybe 30-60 seconds" a few times.
In a case where the user wants a "clear" method that works in realtime without dropouts?
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.
When the performer stops, do you want the DSP graph to continue unabated? Or could you ramp down and duck out of dsp computation to trigger the "clear" method? -Jonathan
On Wed, Nov 23, 2016 at 12:35 PM, Jonathan Wilkes jancsika@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@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@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" brbrofsvl@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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
Cyrille is doing it one go by exploiting the "bang" feature of switch~ with an [until] loop to basically "fast forward" the zeroing process by however many blocks long the buffer is. It's really clever, and I don't think it screws anything up on the outside. This is a technique I'd never thought of, and I can imagine some interesting things coming from this (though I'm not sure it's a canonical technique or incidental). There are some things to think about, like whether the [inlet~] vector is cleared or if it just keeps the last 64 samples for each iteration of the [until] loop.
On Wed, Nov 23, 2016 at 4:19 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
Yeah, this is the kind of thing I think about often. The thing is, if
"clear" is included with [delwrite~], and people are using 30-60 seconds of delay, people are going to use "clear" in those circumstances at some point.
If that turns out to be then it's a matter of revising the algo to "smear" the work of zeroing across the affected blocks, like Cyrille is doing. Or am I missing something?
For the piece, sure – ramping down, switch~ing off, and clearing would
be great. Sometimes you want to start in the middle, and you'd rather have zeroes than detritus from the last pass in the buffer.
Makes sense.
-Jonathan
On Wed, Nov 23, 2016 at 2:12 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
I don't know about average, but I have heard "longest delay I use is
maybe 30-60 seconds" a few times.
In a case where the user wants a "clear" method that works in realtime without dropouts?
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.
When the performer stops, do you want the DSP graph to continue unabated? Or could you ramp down and duck out of dsp computation to trigger the "clear" method?
-Jonathan
On Wed, Nov 23, 2016 at 12:35 PM, Jonathan Wilkes jancsika@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@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@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" brbrofsvl@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 https://lists.puredata.info/listinfo/pd-list
Cyrille is doing it one go by exploiting the "bang" feature of switch~ with an [until] loop to basically "fast forward" the zeroing process by however many blocks long the buffer is. It's really clever, and I don't think it screws anything up on the outside. This is a technique I'd never thought of, and I can imagine some interesting things coming from this (though I'm not sure it's a canonical technique or incidental). There are some things to think about, like whether the [inlet~] vector is cleared or if it just keeps the last 64 samples for each iteration of the [until] loop.
I'm just talking in general about the idea of amortizing the cost of the operation across multiple blocks, which I assume is what's happening in his abstraction (or at least what's supposed to happen). Hm... In practice, how do you find Pd-l2ork's "clear" method compares to Cyrille's abstraction?
-Jonathan
I think it's happening all at once in one block.
It's kind of a baroque way of doing it, however clever; an actual clear method would be better, and a memset() call is fast and and among the least controversial ways of zeroing a buffer.
On Wed, Nov 23, 2016 at 9:31 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
Cyrille is doing it one go by exploiting the "bang" feature of switch~
with an [until] loop to basically "fast forward" the zeroing process by however many blocks long the buffer is. It's really clever, and I don't think it screws anything up on the outside. This is a technique I'd never thought of, and I can imagine some interesting things coming from this (though I'm not sure it's a canonical technique or incidental). There are some things to think about, like whether the [inlet~] vector is cleared or if it just keeps the last 64 samples for each iteration of the [until] loop.
I'm just talking in general about the idea of amortizing the cost of the operation across multiple blocks, which I assume is what's happening in his abstraction (or at least what's supposed to happen).
Hm... In practice, how do you find Pd-l2ork's "clear" method compares to Cyrille's abstraction?
-Jonathan
-
Alex -
Alexandre Torres Porres -
Christof Ressi -
cyrille henry -
Derek Kwan -
IOhannes m zmoelnig -
Ivica Bukvic -
Ivica Ico Bukvic
-
Jonathan Wilkes -
katja -
Matt Barber -
Orm Finnendahl -
Roman Haefeli -
Simon Iten