On June 1, 2013 07:13:25 PM Florian Jung wrote:
> Hi
>
> SndFile has a function to retrieve SampleV* data, which holds audio peak
> and rms information.
> This data is cached at SndFile::readCache and returned by a version of
> SndFile::read.
> (which should be IMHO, and will be, renamed to ::readPeakRms or similar.).
Agreed for sure. Go for it!
Ah, the PEAK/RMS drawing cache system. Yeah, I forgot about that one.
Notice there is unfinished business - some skeletons in there.
#310 s[ch].rms = 0; // TODO rms / mag;
Last time I tried to fix that was several years ago.
To proceed, there was something not right, computationally or conceptually,
I can't recall exactly, I think see [*1] below.
> this ::read function, however, may bypass the cache, namely when the
> requested accuracy is finer than cacheMag. In this case, MusE will read
> from the file directly and calculate the information to return on-the-fly.
Mm, yeah eh... Yikes, looky them sf_seeks for our graphics !:
if (mag < cacheMag) {
float data[channels()][mag];
float* fp[channels()];
for (unsigned i = 0; i < channels(); ++i)
fp[i] = &data[i][0];
sf_count_t ret = 0;
if(sfUI)
ret = sf_seek(sfUI, pos, SEEK_SET);
else
ret = sf_seek(sf, pos, SEEK_SET);
Oh, and then there's sfUI - that's a freakin' weird one, try to follow it.
sfUI kinda takes over if the file is opened read. If opened write it uses
the sf instead. IIRC this had something to do with our wave editor
functions where they create backups and support undo and so on,
or generally writing of files. Not sure.
Maybe eliminate it if possible.
> This creates a problem for me: I rely on the fact that SndFile is only
> seek()ed by me, not by anything outside my scope. (AudioStreams have a
> *private* SndFile, nobody has access to this file).
> However, the AudioStreams shall be able to provide for such a peak-map, too.
>
> My plan is to just use and "stretch" the peak map of the SndFiles
> accordingly. This, however, might result in "overstretching" so that the
> requested accuracy is finer than cacheMag. How should i handle this?
>
>
> For the arranger, this won't be much of a problem, we can easily
> interpolate there.
>
> For the wave editor, i'm not so confident because it allows extreme zoom.
>
> Should I display the output of the AudioStream (that would involve
> creating a copy of the stretcher/sampling rate converter used, creating
> a copy of the SndFile (so i can seek independently))? Problem is, at
> extreme zoom settings this will not resemble the actual file any more,
> but the output of the stretcher. Advantage is, that the user can see
> what will be played. Until he changes the tempo...
>
> Or rather display the output of the SndFile, just stretched accordingly?
> That would only involve a (pretty cheap) copy of the SndFile (so i can
> seek independently). However, this will not resemble what is actually
> played, but rather the SndFile itself. Advantage is that the user gets a
> tempo-independent view on the SndFile.
Mm, don't these two methods amount to the same thing?
I'd say the drawing of the wave needs to line up with the time line exactly
as the user would hear it - that would be method 1 above?
But method 2 "display the output of the SndFile, just stretched accordingly"
amounts to the same as method 1, no? That is, the tempo stretch must
be applied?
Either way, yep you're gonna need separate handles.
(See what I mean about sfUI above? Maybe reclaim it as a true GUI handle,
or rename it appropriately?)
So, in both method 1 and 2, the way I see it you have your GUI handle,
and when it's time to draw, just use it together with your peak cache.
But note that your peak cache should always be up to date and ready to draw -
you may have to recompute your cache (maybe re-save to disk too) whenever
tempo map changes. I think we do that for example in the wave editor when
someone applies editing functions to a wave.
Is that correct?
>
>
> I've a slight tendency towards displaying the SndFile's output, because
> it's cheaper, and *if* i needed this accurate display, then only for
> doing sample-exact cutting. And i would want this to be tempo-independent.
>
> What's your opinion?
[*1]
About peak and rms:
Coincidentally I have some info about this which may relate here.
Try this at home, folks:
Start Jack with a fairly small period, say 128 or less. Start MusE.
Create an Audio Input. Add an oscillator plugin to its effect rack -
try the Analog Oscillator by Steve Harris - and put it on sawtooth
for the best demonstration here. Make sure the track is unmuted.
Now watch the *meters* as you adjust the frequency of the oscillator,
starting with low frequencies.
You will see the meters actually *fluctuate* at rates varying from
'stand still' (meaning even completely off!), to slowly on and off,
to so fast they look solid (normal height).
This is because the meters show the peak value of the signal - but the
problem is we do peaks in a micky-mouse way. Each period we reset
the value to zero and calculate over just that *one* period. If the
period is small, as demonstrated with the sawtooth waveform the peak
will vary *wildly* from period to period!
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.
Cheers.
Tim.
------------------------------------------------------------------------------
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
