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