<html><head></head><body dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="ApplePlainTextBody"><div class="ApplePlainTextBody">I implemented the typical Peak Hold algorithm as described by Ben Bradley, and it does a much better job than an “instant attack, slow decay” type filter.<br><br>However, the problem that Brian points out is valid, so I had a think about it and I’ve made the following modifications to the algorithm:<br><br>We need to keep track of a secondary “fallback” peak, with its own timeout counter. If the main peak hold timeout counter times out, then instead of resetting it to zero, we set it to the value of the fallback peak and copy the vale of the fallback timeout counter. That fallback peak is then the one that gets reset to zero.<br><br>When new data comes in, it is compared firstly to the main peak hold.<br><br>If it is greater or equal then the new data is used as the new peak hold value and the timeout counter is reset to its maximum value. In this case the fallback is reset to zero so that its ready to detect any new secondary peaks that might come along.<br><br>If it’s not greater or equal to the main peak hold, it’s compared to the fallback value. If its higher or equal to that, it replaces that value, and the timeout counter for that is reset.<br><br>And that’s it. It seems to prevent the problem described, and although it’s not perfect in that there are situations in which a “third place” peak could get lost, in practice I doubt you’d care much.<br><br>Tom<br><br>==================<br> Electric Druid<br>Synth & Stompbox DIY<br>==================<br><br><blockquote type="cite">On 20 Mar 2019, at 06:33, rsdio@audiobanshee.com wrote:<br><br>Tom, I think your disappointing results are due to applying a traditional decay to the Peak Hold. What you really want is a literal hold of the same value for some amount of time. The value isn’t actually supposed to decay during that time. Also, you don’t want to make the time window as short as 16 samples, otherwise you’ll see the jumpy results that you don’t like.<br><br>As Ben described, you want an instant attack that updates the Peak on every sample. Then, rather than using typical signal processing for “decay,” just implement a counter that will hold the value constant for a minimum time (unless a new peak arrives).<br><br>To answer your question, what Ben described is the standard algorithm. There are some bugs with the algorithm, and every Peak Hold meter I’ve ever seen has the same bug.<br><br>To be specific, the bug I’m talking about is due to the Peak clearing itself after the Hold time. Each new Peak erases the previous Peak. What can happen is that a new “near” Peak can occur right before the Hold time expires, but the algorithm will completely miss this, clearing the Peak almost immediately. The reason I can be sure that Ben’s description is standard is that all Peak Hold meters have this same flaw.<br></blockquote><br><br><br><blockquote type="cite">On 18 Mar 2019, at 19:11, Ben Bradley <ben.pi.bradley@gmail.com> wrote:<br><br>For peak, use a "hold time" of perhaps 1/2 or 1/5 second. When a peak<br>is detected, set the bargraph level to it, and set a timeout of the<br>hold time. When the timeout occurs, set the peak level to zero. If<br>there's still a signal, it will immediately set the currently held<br>peak to the new peak value. But wait, there's more: Have the peak<br>detection code continue to run during this timeout time, If there's a<br>new higher peak, save it as the current peak AND reset the timeout to<br>the hold time, so it stays at this new level.<br></blockquote></div></body></html>