Tim wrote: > So technically we need a (user) roll-off rate for the audio meters, > and rewrite that peak code not to reset each period. > We have such a rate (fixed) for the midi meters but not for audio meters. > > (I've been studying the roll-off rates. Yes Geoff B. I've heard your requests!) > > So I think this may relate here because we also calculate our wave > drawing peaks - not over one period but one 'pixel length'. > Have you ever noticed how the wave drawing seems to change > its shape detail *more* than you might expect? Something just > seems to go sharper or fuzzier than you expected each time you zoom? > Just like you would not expect the meters to fluctuate. > > I think we would have the culprit here. Imagine a low-frequency sawtooth > wave display over high mag pixels - the peaks would be all over the place > at very high mag. > > So, gulp, does that mean, because we need to define some kind of reliable > length over which to calculate graphic peaks at high mag other than just > pixel length, that we need a 'length' adjustment or 'drawing fall-off rate' ? > > So anyway back to the other story, of RMS meter and wave display. > For RMS, I think the unresolved issue was we need a *running* memory value > of some kind for true RMS reading, we can't do it just over one period or > 'pixel length'. And even though this is not peak, a roll-off rate can still be > helpful, and in this case I think it may be required to have to be a > 'length' value.
Am 02.06.2013 01:59, schrieb Geoff Beasley: > It's always surprised me how little floss projects appear in other > peoples soft. Why not ask Fons if you can use his meter balystics etc > from his meter series in MusE ? They totally kick ass and we can have a > choice of meter types that way too ;) I think we should have meters which don't know about MusE's internals in any way. They shall just have a feedWithAudio() functions (which supports variable chunk sizes), and a draw() function. (Generally, I think much more things in MusE should be environment-agnostic) That said, using external meters someone else wrote would even enforce that. If these meters are good an easy to use in QT, then why not :) Tim, or even Geoff :) why not create a branch and implement this? greetings, flo
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
