.. Call the function SamplesToFloats instead, or in one place, where source
is also always float, just do memcpy.
Dithering never happened in these cases.
... in many places where the function call will later need to be between
modules (or libraries, or the executable) and the annotation will be a necessity
to keep the linkage working on Windows.
That's all that this sweeping commit does.
... whenever they really describe the size of a buffer that fits in memory, or
of a block file (which is never now more than a megabyte and so could be fit in
memory all at once), or a part thereof.
Create WaveTrackCache as a utility class but don't use it anywhere yet.
The possible minor performance problem with effects is fixed by changes
in WaveTrack::GetBestBlockSize().
I've made it where you can enable and disable via experimentals:
EXPERIMENTAL_REALTIME_EFFECTS
EXPERIMENTAL_EFFECTS_RACK
You will notice that, as of now, the only effects currently set up for
realtime are VSTs. Now that this is in, I will start converting the
rest.
As I start to convert the effects, the astute of you may notice that
they no longer directly access tracks or any "internal" Audacity
objects. This isolates the effects from changes in Audacity and makes
it much easier to add new ones.
Anyway, all 3 platforms can now display VST effects in graphical mode.
Yes, that means Linux too. There are quite a few VSTs for Linux if
you search for them.
The so-called "rack" definitely needs some discussion, work, and attention
from someone much better at graphics than me. I'm not really sure it should
stay in as-is. I'd originally planned for it to be simply a utility window
where you can store your (preconfigured) favorite effects. It should probably
revert back to that idea.
You may notice that this DOES include the API work I did. The realtime effects
were too tied to it and I didn't want to redo the whole thing. As I mentioned
elsewhere, the API stuff may or may not be very future proof.
So, let the critter complaints commence. I absolute KNOW there will be some.
(I know I'll be hearing from the Linux peeps pretty darn quickly. ;-))
The problem from the beginning has been that some parts of the code expected to
receive interleaved buffers from Dither and some expected non-interleaved buffers.
I was trying to keep the changes to a minimum, but it just wasn't possible.
The result is that Dither can now accept any combination of non-interleaved and
interleaved source and destination buffers.
I still want to review every single usage of Dither (and all of the intermediaries)
because I've seen allowances here and there for the lack of Dither returning
interleaved buffers. Since it can now return interleaved buffers, some of that
extra processing can be removed.
Paul Licameli
Yuri Chornoivan
Paul Licameli
Leland Lucius
lllucius
benjamin.drung@gmail.com
martynshaw99
james.k.crook@gmail.com
ra