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
i did something like that with a bang~ just triggering a counter to read samples from tabsend~, but not very efficient, of course.
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
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.
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 mnb@martin-brinkmann.de:
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
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
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
check [pd [fexpr~] Examples] in the help file of expr~ :)
[image: Imagem inline 1]
2018-02-02 13:59 GMT-02:00 Roman Haefeli reduzent@gmail.com:
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
There's an implementation of a peak holder in this blog post: http://dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-in-pu.... 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 Haefeli reduzent@gmail.com wrote:
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
On Fre, 2018-02-02 at 18:31 +0000, 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
Thanks, Roman.
On 2 February 2018 at 21:28, Roman Haefeli reduzent@gmail.com wrote:
On Fre, 2018-02-02 at 18:31 +0000, 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
On Sam, 2018-02-03 at 02:47 +0000, Dario Sanfilippo wrote:
Thanks, Roman.
On 2 February 2018 at 21:28, Roman Haefeli reduzent@gmail.com wrote:
On Fre, 2018-02-02 at 18:31 +0000, 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
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 Haefeli reduzent@gmail.com wrote:
On Sam, 2018-02-03 at 02:47 +0000, Dario Sanfilippo wrote:
Thanks, Roman.
On 2 February 2018 at 21:28, Roman Haefeli reduzent@gmail.com wrote:
On Fre, 2018-02-02 at 18:31 +0000, 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
On Sam, 2018-02-03 at 12:42 +0000, 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 reduzent@gmail.com wrote:
On Sam, 2018-02-03 at 02:47 +0000, Dario Sanfilippo wrote:
Thanks, Roman.
On 2 February 2018 at 21:28, Roman Haefeli reduzent@gmail.com wrote:
On Fre, 2018-02-02 at 18:31 +0000, 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
On Fre, 2018-02-02 at 18:31 +0000, 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
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 reduzent@gmail.com wrote:
On Fre, 2018-02-02 at 18:31 +0000, 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
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 sanfilippo.dario@gmail.com 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 reduzent@gmail.com wrote:
On Fre, 2018-02-02 at 18:31 +0000, 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
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 hard.off@gmail.com 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 sanfilippo.dario@gmail.com 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 reduzent@gmail.com wrote:
On Fre, 2018-02-02 at 18:31 +0000, 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
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 sanfilippo.dario@gmail.com:
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 hard.off@gmail.com 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 sanfilippo.dario@gmail.com 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 reduzent@gmail.com wrote:
On Fre, 2018-02-02 at 18:31 +0000, 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
On Son, 2018-02-04 at 13:12 +0000, 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
-
Alexandre Torres Porres -
Dario Sanfilippo -
martin brinkmann -
Matt Davey -
Miller Puckette -
Roman Haefeli -
tim vets