hello<br><br><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Also, you should know that the result of [env~] is something akin to a<br>
low-pass filter; the "speed limiting" from the original patch might be<br>
done more efficiently by squaring the signal and sending it through a<br>
(probably aggressive) low-pass filter before sending it to vsnapshot<br>
-- in that case it's possible that regular old snapshot with a larger<br>
[block~] size might work just as well, since you'll be sending a<br>
signal that doesn't change as quickly. You also need to take into<br></blockquote><div>I want to get the peak of the signal which means that any kind of filtering or other manipulation before (or after except rate limiting) vsnapshot~ is not a good idea.<br>
However, a lp filter seems to be a nice way to get peak-to-peak triggering (but only the triggering, not the actual values). I am currenty trying to implement that, using the already existing env~ to determine when the signal is falling at which point the last max magnitude is send to the vu, after some rate limiting, peak "holding" etc.. It seems to work but still needs optimization.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
account that doing message-level computations every sample might be<br>
fairly inefficient in general, and this is not something that [env~]<br></blockquote><div>I guess you have to trigger vsnapshot~ at sample rate to make sure
you don't miss any value. I can't think of any other way.<br>After all, there is no computation going on,other than reading groups of magnitudes and storing the greatest of them.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
is usually doing. Further, updating a vu gui every sample will<br>
probably be almost ridiculously inefficient -- try comparing the two<br>
setups with and without the vu connected (it may be that you have<br>
already taken care of this in the "speed limiting" and are not<br>
actually updating it every sample after all).<br></blockquote><div>That's right :)<br>(It's amazing how cpu-consuming wish can be. And that with GUI objects that look so simple. I wonder how other audio software manages to run say a dozen "vu" indicators or fine-looking spectrum plotting tools, all at fairly high refresh rates with acceptable cpu losses. Maybe a topic for another thread that i don't really want to start at the moment .. :P )<br>
</div><br></div><br>alabala<br clear="all"><br>-- <br>ypatios<br>