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 <reduz...@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 <reduz...@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
> > 

Attachment: 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

Reply via email to