<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em seg., 4 de mai. de 2020 às 15:20, Roman Haefeli <<a href="mailto:reduzent@gmail.com">reduzent@gmail.com</a>> escreveu:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
That's exactly how the big analog consoles do it. </blockquote><div><br></div><div>well, that changes things :) </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Or maybe there is a<br>
decay, but a much quicker one, whereas for the peak there is a even a<br>
short hold time.<br></blockquote><div><br></div><div>sorry, "a even a short hold time"?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
You can't have proper peak detection using [env~]. It will always<br>
calculate an rms value.<br></blockquote><div><br></div><div>Sure, hence it's a variation, which takes into account the peak, not RMS.</div><div><br></div><div>My idea was in fact to propose this as a second output for [env~]</div><div><br></div><div>but anyway, seems [slop~] is doing the trick now and that what I thought was bad was actually how things work, so all I can say is that we could make a better/proper example on how to feed both RMS and peak into [vu]</div></div></div>