Am 02.06.2013 01:16, schrieb Tim E. Real:
> Mm, yeah eh... Yikes, looky them sf_seeks for our graphics !:
> ... freakin' weird one, try to follow it. 

indeed. Let's fix that :)

> 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.

I will have to consider and maybe eliminate this with my AudioStreams
anyway, don't bother with it :)


> Mm, don't these two methods amount to the same thing?

at "far away"-zoom levels, they do.

however, if you have zoomed "near", then:

1. will display the wave form which you will hear, but
2. will display the wave form actually in the file.

let's assume your file is pure sine 1000Hz, and recorded at a tempo of
60bpm. But your song's tempo is 120bpm, so we're shrinking the file by 50%.

1. will display a 1000Hz wave, however inaccurate! When in the displayed
   wave form you can see a zero-crossing, this is not true for the
   original file. If you need to sample-exact cut the end of the file,
   this will be bad.

2. will display a 2000Hz wave, but if you cut where's a zero-crossing,
   then you will actually cut the file at a zero-crossing.


> 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? 

right

> 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?

well, no. Method 1 requires us to calculate the peaks on the stretched
wave. That involves a lot of calculations.

Method 2 requires us to (easily) interpolate the peaks of the
*unstretched* wave file. That is, varying the increment of an array
index, nothing more. Requires no cpu power.


> 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.

Only if I use method 1. With method 2, there is no need for a "readily
stretched cache". We can just use the "unstretched" cache and "stretch"
it on-the-fly. As noted above, this will only be a varying incement of
the for-loop which copies the data from the cache to the result buffer.

That's why i strongly prefer method 2.


greetings,
flo

Attachment: 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

Reply via email to