Re: [PD] max value of last n samples
On Son, 2018-02-04 at 13:12 +, Dario Sanfilippo wrote: > Hi, Roman. I guess that fexpr~ implies block 1 but probably a few > other things too: 256 instantiations of the feedback loop in my > abstractions are around 44% load whereas the same number of [fexpr~ > max($x1[0], $y[-1]*$x2[0])] are peaking at 95%. Ah, good to know. There is no point in doing this [fexpr~] then. Thanks for testing. Roman signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] max value of last n samples
hi, I tried only using fexpr~, here's what I got [image: Imagem inline 1] #N canvas 627 57 454 302 10; #X obj 352 105 v n_\$0; #X floatatom 352 74 5 0 0 0 - - -, f 5; #X obj 59 117 v count_\$0; #X obj 132 112 fexpr~ count_\$0 = $y2[-1] + 1 \; if(count_\$0 > n_\$0 \, 1 \, count_\$0); #X obj 34 153 fexpr~ max($x1[0] \, if($x2[-1] \, $y1[-1] \, -1)) \; ; #X obj 270 195 samphold~; #X obj 321 154 expr~ $v1 != 1; #X obj 34 25 noise~; #X text 80 25 <= input; #X text 342 249 <= output; #X obj 270 246 else/display~; #X text 177 73 'n' number of samples >; #X connect 1 0 0 0; #X connect 3 1 6 0; #X connect 4 0 5 0; #X connect 5 0 10 0; #X connect 6 0 4 1; #X connect 6 0 5 1; #X connect 7 0 4 0; 2018-02-04 12:56 GMT-02:00 Dario Sanfilippo: > That's certainly the way to go for efficiency: 256 rpole~ objects are > about 10% load against 44% load of the PD-implemented counterpart. > > D > > > On 4 February 2018 at 14:41, Matt Davey wrote: > >> Really at that point, you’d have to be asking youself if there is any way >> to use an external. >> >> >> On Sunday, February 4, 2018, Dario Sanfilippo >> wrote: >> >>> Hi, Roman. I guess that fexpr~ implies block 1 but probably a few other >>> things too: 256 instantiations of the feedback loop in my abstractions are >>> around 44% load whereas the same number of [fexpr~ max($x1[0], >>> $y[-1]*$x2[0])] are peaking at 95%. >>> >>> D >>> >>> >>> On 4 February 2018 at 12:33, Roman Haefeli wrote: >>> On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote: > There's an implementation of a peak holder in this blog post: http:// > dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-in- > pure-data. BTW: the peak envelope part could be also implemented using fexpr~: [fexpr~ max($x1[0], ($y[-1]*$f2)] This has the advantage of not requiring a re-blocked subpatch with blocksize=1. However, I wonder which is computationally less expensive. Is there a rule of thumb whether [fexpr~] or [block~ 1] is faster? Roman ___ 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 > > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] max value of last n samples
That's certainly the way to go for efficiency: 256 rpole~ objects are about 10% load against 44% load of the PD-implemented counterpart. D On 4 February 2018 at 14:41, Matt Daveywrote: > Really at that point, you’d have to be asking youself if there is any way > to use an external. > > > On Sunday, February 4, 2018, Dario Sanfilippo > wrote: > >> Hi, Roman. I guess that fexpr~ implies block 1 but probably a few other >> things too: 256 instantiations of the feedback loop in my abstractions are >> around 44% load whereas the same number of [fexpr~ max($x1[0], >> $y[-1]*$x2[0])] are peaking at 95%. >> >> D >> >> >> On 4 February 2018 at 12:33, Roman Haefeli wrote: >> >>> On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote: >>> > There's an implementation of a peak holder in this blog post: http:// >>> > dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-in- >>> > pure-data. >>> >>> BTW: the peak envelope part could be also implemented using fexpr~: >>> >>> [fexpr~ max($x1[0], ($y[-1]*$f2)] >>> >>> This has the advantage of not requiring a re-blocked subpatch with >>> blocksize=1. However, I wonder which is computationally less expensive. >>> Is there a rule of thumb whether [fexpr~] or [block~ 1] is faster? >>> >>> Roman >>> ___ >>> 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
Re: [PD] max value of last n samples
Really at that point, you’d have to be asking youself if there is any way to use an external. On Sunday, February 4, 2018, Dario Sanfilippowrote: > Hi, Roman. I guess that fexpr~ implies block 1 but probably a few other > things too: 256 instantiations of the feedback loop in my abstractions are > around 44% load whereas the same number of [fexpr~ max($x1[0], > $y[-1]*$x2[0])] are peaking at 95%. > > D > > > On 4 February 2018 at 12:33, Roman Haefeli wrote: > >> On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote: >> > There's an implementation of a peak holder in this blog post: http:// >> > dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-in- >> > pure-data. >> >> BTW: the peak envelope part could be also implemented using fexpr~: >> >> [fexpr~ max($x1[0], ($y[-1]*$f2)] >> >> This has the advantage of not requiring a re-blocked subpatch with >> blocksize=1. However, I wonder which is computationally less expensive. >> Is there a rule of thumb whether [fexpr~] or [block~ 1] is faster? >> >> Roman >> ___ >> 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
Re: [PD] max value of last n samples
Hi, Roman. I guess that fexpr~ implies block 1 but probably a few other things too: 256 instantiations of the feedback loop in my abstractions are around 44% load whereas the same number of [fexpr~ max($x1[0], $y[-1]*$x2[0])] are peaking at 95%. D On 4 February 2018 at 12:33, Roman Haefeliwrote: > On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote: > > There's an implementation of a peak holder in this blog post: http:// > > dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-in- > > pure-data. > > BTW: the peak envelope part could be also implemented using fexpr~: > > [fexpr~ max($x1[0], ($y[-1]*$f2)] > > This has the advantage of not requiring a re-blocked subpatch with > blocksize=1. However, I wonder which is computationally less expensive. > Is there a rule of thumb whether [fexpr~] or [block~ 1] is faster? > > Roman > ___ > 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
Re: [PD] max value of last n samples
On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote: > There's an implementation of a peak holder in this blog post: http:// > dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-in- > pure-data. BTW: the peak envelope part could be also implemented using fexpr~: [fexpr~ max($x1[0], ($y[-1]*$f2)] This has the advantage of not requiring a re-blocked subpatch with blocksize=1. However, I wonder which is computationally less expensive. Is there a rule of thumb whether [fexpr~] or [block~ 1] is faster? Roman signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] max value of last n samples
On Sam, 2018-02-03 at 12:42 +, Dario Sanfilippo wrote: > I see what you mean, Roman. So you'd need the N-size block to be > processed beforehand, which would imply an N-size delay in the > output, is that right? Actually, your peak holder implementation does the job well for me. I was (and am) still curious, though, how to implement what I initially asked for which is apparently called 'sliding window maximum' [1]. What I like about your implementation is that you managed to start a timer when a peak is detected and you do that in the signal domain. > I haven't thought of it, no idea whether that could be achieved by > changing the feedback period in the peak holder and/or adding a delay > in the input. Maybe I'll try something later. If you're curious, that's fine, but it's not necessary to spend more time for my case. I'm happy with your peak holder ;-) Roman [1] https://articles.leetcode.com/sliding-window-maximum/ > Cheers, > Dario > > On 3 February 2018 at 09:33, Roman Haefeli> wrote: > > On Sam, 2018-02-03 at 02:47 +, Dario Sanfilippo wrote: > > > Thanks, Roman. > > > > > > On 2 February 2018 at 21:28, Roman Haefeli > > > wrote: > > > > On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote: > > > > > There's an implementation of a peak holder in this blog > > > > post: http:// > > > > > dariosanfilippo.tumblr.com/post/162523174771/lookahead- > > limiting- > > > > in- > > > > > pure-data. I remember testing it but please let me know if > > you > > > > find a > > > > > bug. > > > > > > > > Very nice write up. Thanks for sharing. > > > > > > > > > The current peak is replaced to whatever the input is after a > > > > desired > > > > > time, and the counter is reset whenever a new peak is found. > > It > > > > > should be easy to change it so that the peak is reset > > > > periodically. > > > > > > > > It's not exactly equivalent with what I've asked, since your > > > > implementation only takes new peaks into account after the hold > > > > period > > > > has ended. > > > Perhaps my wording in the previous email was confusing: what > > happens > > > is that every new peak will update the output immediately, and > > > whenever that happens the countdown starts so that, should no > > other > > > peak be detected after that time, the output will be set to > > whatever > > > the input is in that moment. > > > > > > > Assume an input signal consisting of a series of 1-sample > > > > impulses with a period that is slightly lower than the hold > > period. > > > > The > > > > output signal has a gap before each second impulse. For the use > > > > case in > > > > your article (which is also the use case I'm interested in), > > that > > > > doesn't matter much, because the peak holder signal is fed to a > > > > peak > > > > enveloper which somewhat masks those gaps. > > > In that case, we should expect a full-amp DC out of the peak > > holder > > > for the impulses are faster than the hold time, and that's what > > we > > > actually get: > > > > > > Yes, correct. If the peaks reach the same level or are higher than > > the > > ones before, then the hold period is prolonged. But when they have > > less > > amplitude than the ones before, gaps appear. See: > > > > https://netpd.org/~roman/tmp/peakholder_gaps.png > > > > With a true max(x[0-(-N)], a downward stairway would appear and > > there > > wouldn't be any gaps. > > > > As I said, that is only small difference and for the purpose of a > > look- > > ahead limiter it probably doesn't matter that much. > > > > Roman > > > > ___ > > Pd-list@lists.iem.at mailing list > > UNSUBSCRIBE and account-management -> https://lists.puredata.info/l > > istinfo/pd-list > > signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] max value of last n samples
I see what you mean, Roman. So you'd need the N-size block to be processed beforehand, which would imply an N-size delay in the output, is that right? I haven't thought of it, no idea whether that could be achieved by changing the feedback period in the peak holder and/or adding a delay in the input. Maybe I'll try something later. Cheers, Dario On 3 February 2018 at 09:33, Roman Haefeliwrote: > On Sam, 2018-02-03 at 02:47 +, Dario Sanfilippo wrote: > > Thanks, Roman. > > > > On 2 February 2018 at 21:28, Roman Haefeli > > wrote: > > > On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote: > > > > There's an implementation of a peak holder in this blog > > > post: http:// > > > > dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting- > > > in- > > > > pure-data. I remember testing it but please let me know if you > > > find a > > > > bug. > > > > > > Very nice write up. Thanks for sharing. > > > > > > > The current peak is replaced to whatever the input is after a > > > desired > > > > time, and the counter is reset whenever a new peak is found. It > > > > should be easy to change it so that the peak is reset > > > periodically. > > > > > > It's not exactly equivalent with what I've asked, since your > > > implementation only takes new peaks into account after the hold > > > period > > > has ended. > > Perhaps my wording in the previous email was confusing: what happens > > is that every new peak will update the output immediately, and > > whenever that happens the countdown starts so that, should no other > > peak be detected after that time, the output will be set to whatever > > the input is in that moment. > > > > > Assume an input signal consisting of a series of 1-sample > > > impulses with a period that is slightly lower than the hold period. > > > The > > > output signal has a gap before each second impulse. For the use > > > case in > > > your article (which is also the use case I'm interested in), that > > > doesn't matter much, because the peak holder signal is fed to a > > > peak > > > enveloper which somewhat masks those gaps. > > In that case, we should expect a full-amp DC out of the peak holder > > for the impulses are faster than the hold time, and that's what we > > actually get: > > > Yes, correct. If the peaks reach the same level or are higher than the > ones before, then the hold period is prolonged. But when they have less > amplitude than the ones before, gaps appear. See: > > https://netpd.org/~roman/tmp/peakholder_gaps.png > > With a true max(x[0-(-N)], a downward stairway would appear and there > wouldn't be any gaps. > > As I said, that is only small difference and for the purpose of a look- > ahead limiter it probably doesn't matter that much. > > Roman > > ___ > 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
Re: [PD] max value of last n samples
On Sam, 2018-02-03 at 02:47 +, Dario Sanfilippo wrote: > Thanks, Roman. > > On 2 February 2018 at 21:28, Roman Haefeli> wrote: > > On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote: > > > There's an implementation of a peak holder in this blog > > post: http:// > > > dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting- > > in- > > > pure-data. I remember testing it but please let me know if you > > find a > > > bug. > > > > Very nice write up. Thanks for sharing. > > > > > The current peak is replaced to whatever the input is after a > > desired > > > time, and the counter is reset whenever a new peak is found. It > > > should be easy to change it so that the peak is reset > > periodically. > > > > It's not exactly equivalent with what I've asked, since your > > implementation only takes new peaks into account after the hold > > period > > has ended. > Perhaps my wording in the previous email was confusing: what happens > is that every new peak will update the output immediately, and > whenever that happens the countdown starts so that, should no other > peak be detected after that time, the output will be set to whatever > the input is in that moment. > > > Assume an input signal consisting of a series of 1-sample > > impulses with a period that is slightly lower than the hold period. > > The > > output signal has a gap before each second impulse. For the use > > case in > > your article (which is also the use case I'm interested in), that > > doesn't matter much, because the peak holder signal is fed to a > > peak > > enveloper which somewhat masks those gaps. > In that case, we should expect a full-amp DC out of the peak holder > for the impulses are faster than the hold time, and that's what we > actually get: Yes, correct. If the peaks reach the same level or are higher than the ones before, then the hold period is prolonged. But when they have less amplitude than the ones before, gaps appear. See: https://netpd.org/~roman/tmp/peakholder_gaps.png With a true max(x[0-(-N)], a downward stairway would appear and there wouldn't be any gaps. As I said, that is only small difference and for the purpose of a look- ahead limiter it probably doesn't matter that much. Roman signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] max value of last n samples
Thanks, Roman. On 2 February 2018 at 21:28, Roman Haefeliwrote: > On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote: > > There's an implementation of a peak holder in this blog post: http:// > > dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-in- > > pure-data. I remember testing it but please let me know if you find a > > bug. > > Very nice write up. Thanks for sharing. > > > The current peak is replaced to whatever the input is after a desired > > time, and the counter is reset whenever a new peak is found. It > > should be easy to change it so that the peak is reset periodically. > > It's not exactly equivalent with what I've asked, since your > implementation only takes new peaks into account after the hold period > has ended. Perhaps my wording in the previous email was confusing: what happens is that every new peak will update the output immediately, and whenever that happens the countdown starts so that, should no other peak be detected after that time, the output will be set to whatever the input is in that moment. > Assume an input signal consisting of a series of 1-sample > impulses with a period that is slightly lower than the hold period. The > output signal has a gap before each second impulse. For the use case in > your article (which is also the use case I'm interested in), that > doesn't matter much, because the peak holder signal is fed to a peak > enveloper which somewhat masks those gaps. > In that case, we should expect a full-amp DC out of the peak holder for the impulses are faster than the hold time, and that's what we actually get: [image: Inline images 2] So the peak envelope is only used to transition from the peak to the non-peak value exponentially. > > I'm going to use your implementation for peak holding. Thanks! > > Roman > Sure, you're welcome. I hope that this makes more sense. Dario > > > ___ > 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
Re: [PD] max value of last n samples
check [pd [fexpr~] Examples] in the help file of expr~ :) [image: Imagem inline 1] 2018-02-02 13:59 GMT-02:00 Roman Haefeli: > On Fre, 2018-02-02 at 16:30 +0100, tim vets wrote: > > is this any good? > > [ fexpr~ if($x1[0]>$y1[-1], $x1[0], $y1[-1]) ] > > This will never return from the highest value ever experienced. I > really need the output to return after N samples. > > > not sure how to reset it though... > > Exactly. > > Roman > ___ > 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
Re: [PD] max value of last n samples
On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote: > There's an implementation of a peak holder in this blog post: http:// > dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-in- > pure-data. I remember testing it but please let me know if you find a > bug. Very nice write up. Thanks for sharing. > The current peak is replaced to whatever the input is after a desired > time, and the counter is reset whenever a new peak is found. It > should be easy to change it so that the peak is reset periodically. It's not exactly equivalent with what I've asked, since your implementation only takes new peaks into account after the hold period has ended. Assume an input signal consisting of a series of 1-sample impulses with a period that is slightly lower than the hold period. The output signal has a gap before each second impulse. For the use case in your article (which is also the use case I'm interested in), that doesn't matter much, because the peak holder signal is fed to a peak enveloper which somewhat masks those gaps. I'm going to use your implementation for peak holding. Thanks! Roman signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] max value of last n samples
There's an implementation of a peak holder in this blog post: http://dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-in-pure-data. I remember testing it but please let me know if you find a bug. The current peak is replaced to whatever the input is after a desired time, and the counter is reset whenever a new peak is found. It should be easy to change it so that the peak is reset periodically. I hope it helps. Dario On 2 February 2018 at 13:52, Roman Haefeliwrote: > Hey all > > Can this be done in vanilla? I'd like to output the maximum value of > the last N input samples in the signal domain. Ideally N would be > adjustable. > > It bugs my mind, but I can't think of a solution for this simply > problem. > > Roman > ___ > 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
Re: [PD] max value of last n samples
If you need this as a mesage, you can continually stuff the signal into an array and use array max (which can be set to look at a subinterval of the array.) You can use an array as a circular buffer by always maintaining two write pointers into the same array - whichever one is in front at any time is at the head of a contiguous strip of past samples. I don't know any way to get the value out as a signal (something for me to think about)... cheers Miller On Fri, Feb 02, 2018 at 04:59:30PM +0100, Roman Haefeli wrote: > On Fre, 2018-02-02 at 16:30 +0100, tim vets wrote: > > is this any good? > > [ fexpr~ if($x1[0]>$y1[-1], $x1[0], $y1[-1]) ] > > This will never return from the highest value ever experienced. I > really need the output to return after N samples. > > > not sure how to reset it though... > > Exactly. > > Roman > ___ > 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
Re: [PD] max value of last n samples
On Fre, 2018-02-02 at 23:27 +0900, Matt Davey wrote: > i did something like that with a bang~ just triggering a counter to > read samples from tabsend~, but not very efficient, of course. I don't mind converting to message and then back to signal. I did that a few times, too. But I believe you'll be one block behind then, won't you? You can't process a block of audio, do messages and then process a block of audio all within one single block, or am I missing something? Maybe you can by bang~ing a switch~ed subpatch? Roman signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] max value of last n samples
On Fre, 2018-02-02 at 16:30 +0100, tim vets wrote: > is this any good? > [ fexpr~ if($x1[0]>$y1[-1], $x1[0], $y1[-1]) ] This will never return from the highest value ever experienced. I really need the output to return after N samples. > not sure how to reset it though... Exactly. Roman signature.asc Description: This is a digitally signed message part ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] max value of last n samples
is this any good? [ fexpr~ if($x1[0]>$y1[-1], $x1[0], $y1[-1]) ] not sure how to reset it though... gr, Tim 2018-02-02 15:58 GMT+01:00 martin brinkmann: > On 02/02/18 14:52, Roman Haefeli wrote: > > Can this be done in vanilla? I'd like to output the maximum value of > > the last N input samples in the signal domain. Ideally N would be > > adjustable. > > i have used cascaded samphold~ objects in a similar situation. > though n is not exactly adjustable this way... > > for bigger n (> blocksize) the bang~/tabread-solution is probably better. > > > ___ > 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
Re: [PD] max value of last n samples
On 02/02/18 14:52, Roman Haefeli wrote: > Can this be done in vanilla? I'd like to output the maximum value of > the last N input samples in the signal domain. Ideally N would be > adjustable. i have used cascaded samphold~ objects in a similar situation. though n is not exactly adjustable this way... for bigger n (> blocksize) the bang~/tabread-solution is probably better. signature.asc Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list