As discussed in the previous thread, we can't clear delay buffers in Pd (you can do it with tapin~ in max, for instance), at least not with [delwrite~], [delay~] and [z~]. So we're pretty much tied up and needed it for an "moving sum" object or a "moving average" filter.
It doesn't seem hard to allow a "clear" message into delwrite~ for the next update.
[delay~] in Max actually can also clear, so we could add this feature in [cyclone/delay~]!
and [z~] could also be cleared, maybe, why not?
cheers
http://sourceforge.net/p/pure-data/patches/369/
On Tuesday, December 8, 2015 1:38 PM, Alexandre Torres Porres <porres@gmail.com> wrote:
As discussed in the previous thread, we can't clear delay buffers in Pd (you can do it with tapin~ in max, for instance), at least not with [delwrite~], [delay~] and [z~]. So we're pretty much tied up and needed it for an "moving sum" object or a "moving average" filter. It doesn't seem hard to allow a "clear" message into delwrite~ for the next update.
[delay~] in Max actually can also clear, so we could add this feature in [cyclone/delay~]! and [z~] could also be cleared, maybe, why not? cheers _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
2015-12-08 17:12 GMT-02:00 Jonathan Wilkes jancsika@yahoo.com:
wow, a request from over 4 years :)
On Tuesday, December 8, 2015 1:38 PM, Alexandre Torres Porres < porres@gmail.com> wrote:
As discussed in the previous thread, we can't clear delay buffers in Pd (you can do it with tapin~ in max, for instance), at least not with [delwrite~], [delay~] and [z~]. So we're pretty much tied up and needed it for an "moving sum" object or a "moving average" filter.
It doesn't seem hard to allow a "clear" message into delwrite~ for the next update.
[delay~] in Max actually can also clear, so we could add this feature in [cyclone/delay~]!
and [z~] could also be cleared, maybe, why not?
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Yep. It looks like it got included in Pd-l2ork in November of that same year. -Jonathan
On Tuesday, December 8, 2015 2:27 PM, Alexandre Torres Porres <porres@gmail.com> wrote:
2015-12-08 17:12 GMT-02:00 Jonathan Wilkes jancsika@yahoo.com:
http://sourceforge.net/p/pure-data/patches/369/
wow, a request from over 4 years :)
On Tuesday, December 8, 2015 1:38 PM, Alexandre Torres Porres <porres@gmail.com> wrote:
As discussed in the previous thread, we can't clear delay buffers in Pd (you can do it with tapin~ in max, for instance), at least not with [delwrite~], [delay~] and [z~]. So we're pretty much tied up and needed it for an "moving sum" object or a "moving average" filter. It doesn't seem hard to allow a "clear" message into delwrite~ for the next update.
[delay~] in Max actually can also clear, so we could add this feature in [cyclone/delay~]! and [z~] could also be cleared, maybe, why not? cheers _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Actually, [z~] is cleared everytime you change the right inlet (try feeding it with [osc~] and then switch between high values like 22000 and 44000, you'll certainly here the dropout)! I've just found out, that this is the behaviour my abstraction [cmavg~] needs for changing the number of samples to be averaged (together with clearing the [rpole~]). When you replace [z~] with a pair of [delwrite~] and [delread~], it won't work properly! So [delwrite~] definitely needs a method for clearing the buffer!
Gesendet: Dienstag, 08. Dezember 2015 um 19:37 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "Miller Puckette" mpuckett@imusic1.ucsd.edu, "Fred Jan Kraan" fjkraan@xs4all.nl, "IOhannes m zmoelnig" zmoelnig@iem.at Cc: "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: [PD] no "clear" message option in [cyclone/delay~], [delwrite~] and [z~]
As discussed in the previous thread, we can't clear delay buffers in Pd (you can do it with tapin~ in max, for instance), at least not with [delwrite~], [delay~] and [z~]. So we're pretty much tied up and needed it for an "moving sum" object or a "moving average" filter. It doesn't seem hard to allow a "clear" message into delwrite~ for the next update. [delay~] in Max actually can also clear, so we could add this feature in [cyclone/delay~]! and [z~] could also be cleared, maybe, why not? cheers_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I don't quite get it, how does a number clear [rpole~] in the first place?
Gesendet: Dienstag, 08. Dezember 2015 um 20:38 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Matt Barber" brbrofsvl@gmail.com, "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: [PD] no "clear" message option in [cyclone/delay~], [delwrite~] and [z~]
Actually, [z~] is cleared everytime you change the right inlet
Cool So you just need a [change] object to prevent the same number from clearing [rpole~], that's why I was having a problem with it!
in your patch, a number triggers a clear message to rpole~, if the number is the same, it clears it and ruins the patch forever, a [change] object prevents this.
see attachment.
2015-12-08 17:46 GMT-02:00 Christof Ressi christof.ressi@gmx.at:
I don't quite get it, how does a number clear [rpole~] in the first place?
Gesendet: Dienstag, 08. Dezember 2015 um 20:38 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Matt Barber" brbrofsvl@gmail.com, "pd-list@lists.iem.at" < pd-list@lists.iem.at> Betreff: Re: [PD] no "clear" message option in [cyclone/delay~], [delwrite~] and [z~]
Actually, [z~] is cleared everytime you change the right inlet
Cool
So you just need a [change] object to prevent the same number from clearing [rpole~], that's why I was having a problem with it!
Thanks, now I get it! I changed my patch accordingly. I wasn't even aware that sending the same number twice will screw things up (because I've probably never done it). Cheers
Gesendet: Dienstag, 08. Dezember 2015 um 20:59 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: Re: [PD] no "clear" message option in [cyclone/delay~], [delwrite~] and [z~]
in your patch, a number triggers a clear message to rpole~, if the number is the same, it clears it and ruins the patch forever, a [change] object prevents this. see attachment. 2015-12-08 17:46 GMT-02:00 Christof Ressi christof.ressi@gmx.at:I don't quite get it, how does a number clear [rpole~] in the first place?
Gesendet: Dienstag, 08. Dezember 2015 um 20:38 Uhr Von: "Alexandre Torres Porres" <porres@gmail.com[porres@gmail.com]> An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]> Cc: "Matt Barber" <brbrofsvl@gmail.com[brbrofsvl@gmail.com]>, "pd-list@lists.iem.at[pd-list@lists.iem.at]" <pd-list@lists.iem.at[pd-list@lists.iem.at]> Betreff: Re: [PD] no "clear" message option in [cyclone/delay~], [delwrite~] and [z~]
Actually, [z~] is cleared everytime you change the right inlet
Cool So you just need a [change] object to prevent the same number from clearing [rpole~], that's why I was having a problem with it!
actuallym this newer design is better
2015-12-08 17:46 GMT-02:00 Christof Ressi christof.ressi@gmx.at:
I don't quite get it, how does a number clear [rpole~] in the first place?
Gesendet: Dienstag, 08. Dezember 2015 um 20:38 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Matt Barber" brbrofsvl@gmail.com, "pd-list@lists.iem.at" < pd-list@lists.iem.at> Betreff: Re: [PD] no "clear" message option in [cyclone/delay~], [delwrite~] and [z~]
Actually, [z~] is cleared everytime you change the right inlet
Cool
So you just need a [change] object to prevent the same number from clearing [rpole~], that's why I was having a problem with it!
2015-12-08 17:16 GMT-02:00 Christof Ressi christof.ressi@gmx.at:
Actually, [z~] is cleared everytime you change the right inlet
Although it serves well for the mean filter, I just came across the need to clear the buffer for the same delay size, so I can't use [z~] or [delay~] or [delwrite~]/[delread~]...
so only option is [fexpr~] - which has a block limit but suits me
anyway, not a bad idea to add a clear method to [z~] anyway
cheers
On 12/11/2015 11:01 PM, Alexandre Torres Porres wrote:
2015-12-08 17:16 GMT-02:00 Christof Ressi christof.ressi@gmx.at:
Actually, [z~] is cleared everytime you change the right inlet
Although it serves well for the mean filter, I just came across the need to clear the buffer for the same delay size, so I can't use [z~] or [delay~] or [delwrite~]/[delread~]...
so only option is [fexpr~] - which has a block limit but suits me
anyway, not a bad idea to add a clear method to [z~] anyway
how about giving [z~] a dummy delay (e.g. 'required+1') to trigger the clearing, and then set it back to the original value ('required')? not very elegant, but works *now*.
fmadsr IOhannes
Cool, works, and if your planing on doing something, besides a clear message you could also think of a "set" message where it receives a list of numbers setting the samples in the delay line (max list size = delay size).
The "set" message would really make it much more powerful ;) - reminding that delay~ and delwrite~ don't have this, only fexpr~
Let me know how you feel about the suggestion, and when you could do that if you're considering adding such features.
cheers
2015-12-11 20:08 GMT-02:00 IOhannes m zmölnig zmoelnig@iem.at:
On 12/11/2015 11:01 PM, Alexandre Torres Porres wrote:
2015-12-08 17:16 GMT-02:00 Christof Ressi christof.ressi@gmx.at:
Actually, [z~] is cleared everytime you change the right inlet
Although it serves well for the mean filter, I just came across the need
to
clear the buffer for the same delay size, so I can't use [z~] or [delay~] or [delwrite~]/[delread~]...
so only option is [fexpr~] - which has a block limit but suits me
anyway, not a bad idea to add a clear method to [z~] anyway
how about giving [z~] a dummy delay (e.g. 'required+1') to trigger the clearing, and then set it back to the original value ('required')? not very elegant, but works *now*.
fmadsr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Alexandre,
Cool, works, and if your planing on doing something, besides a clear message you could also think of a "set" message where it receives a list of numbers setting the samples in the delay line (max list size = delay size).
The [clear( message is as simple as DSP can get; just zero the entire buffer. Most other operations are more complex. What do you mean by setting samples in the delay line? Trying to set more than a few will get very inefficient, and from the message domain it will be hard to control where they be placed in the signal stream.
The "set" message would really make it much more powerful ;) - reminding that delay~ and delwrite~ don't have this, only fexpr~
I tried understanding what fexpr~ does with [set ...( but failed miserable :-(.
Let me know how you feel about the suggestion, and when you could do that if you're considering adding such features.
About the feature requests, maybe you could try to make a persistent overview (web page or in the http://puredata.info wiki)? Trying to find them in this list later is no fun, and it will be useful when I or some future cyclone maintainer might find the time to implement them. It allows for some extra explanation and maybe an abstraction to demonstrate the feature.
I just managed to install the Max/MSP 4.6 help patches and counted 470 objects there. Count 100 for vanilla Pd and 150 for cyclone, there are 220 to go...
cheers
Greetings,
Fred Jan
2015-12-11 20:08 GMT-02:00 IOhannes m zmölnig <zmoelnig@iem.at mailto:zmoelnig@iem.at>:
On 12/11/2015 11:01 PM, Alexandre Torres Porres wrote: > 2015-12-08 17:16 GMT-02:00 Christof Ressi <christof.ressi@gmx.at <mailto:christof.ressi@gmx.at>>: > >> Actually, [z~] is cleared everytime you change the right inlet > > > Although it serves well for the mean filter, I just came across the need to > clear the buffer for the same delay size, so I can't use [z~] or [delay~] > or [delwrite~]/[delread~]... > > so only option is [fexpr~] - which has a block limit but suits me > > anyway, not a bad idea to add a clear method to [z~] anyway how about giving [z~] a dummy delay (e.g. 'required+1') to trigger the clearing, and then set it back to the original value ('required')? not very elegant, but works *now*. fmadsr IOhannes _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
2015-12-13 8:06 GMT-02:00 Fred Jan Kraan fjkraan@xs4all.nl:
Hi Alexandre,
About the feature requests, maybe you could try to make a persistent overview (web page or in the http://puredata.info wiki)?
Sure, I already had plans to collect all I have found into a shared doc, hold on
cheers
- Alexandre Torres Porres porres@gmail.com [2015-12-08 19:38]:
As discussed in the previous thread, we can't clear delay buffers in Pd
You could build an abstraction that implements a delay using Pd tables (arrays). Don't forget about order-forcing the objects to allow sub-vectorsize delays. Then you can clear it by sending a ; mytable const 0 message.
On 2015-12-08 07:37 PM, Alexandre Torres Porres wrote:
[delay~] in Max actually can also clear, so we could add this feature in [cyclone/delay~]!
This is an easy one :-). It will be part of the next update.
cheers
Greetings,
Fred Jan
-
Alexandre Torres Porres -
Christof Ressi -
Fred Jan Kraan -
IOhannes m zmölnig -
Jonathan Wilkes -
Peter P.