Re: [Audacity-devel] Real-time effects stacks

[Jorge R. <jro...@ma...>]

Thanks for all the responses.

> It is simply not realistic to attempt this on two hours a week

When I said "a couple hours" I didn't mean two, I realize this is more than
a two hour a week job.

> I have mixed feelings about non-destructive effect stacks in audio
> editors.  Non-destructive real-time effects stacking is a very useful
> and fundamental tool in a digital audio workstation like protools or
> ardour.  That being said, I have always thought of audacity as a
> sample audio editor as opposed a DAW.

The main problem with Ardour is their downloads page:

http://ardour.org/binary_downloads

Where's the Windows binary? My opinion is that Ardour, while it is a good
recording tool, is made by a bunch of Linux elitists who aren't willing to
"pander" to Windows people. To quote Paul:

"you seem to assume that the crowd we would get from there being a windows
version is a desirable thing. many other *nix open source projects have been
overwhelmed when they have ported to windows - a huge, sudden influx of
users with zero background in software development, and no infrastructure to
offer them support. we don't want to end up in that situation."

I don't blame them honestly, X-Chat for example canceled their Windows
version because of how much of a bother it was. .However, the result is that
everybody I know uses and loves Audacity, and nobody knows that Ardour
exists.

Anyhow, Audacity can be more of an "audio processing" tool as opposed to a
DAW, but still process data non-destructively. I would think that not all
users want to process their data completely destructively all the time.
Maybe they would like to keep their "dry" audio data around, and maybe they
would like Audacity to handle this and not have to backup and import the raw
audio data themselves? I think that's reasonable.

> One first step I suggested to another SoC student was to re-factor the
> existing undo stack so it could be accessed on a per-track basis.

This would be helpful, but I don't know if it would be very intuitive to
have to select which track you want to do the undo on. It doesn't make much
sense, and it's not what you would expect the program to do when you hit
ctl-z. Aside from that, while it would solve Mr. Chinen's problem where
Audacity is more of an audio editor than a DAW, it seems like a roundabout
way to accomplish this, using the undo stack to do what a completely
separate stack should do. It smells of a hack to me.

But, it did give me an interesting idea, which is very similar and I think
has the best of both worlds. Each track would have an effects stack, but
instead of being applied to the real-time buffer or to the file itself
destructively, what if a copy of the audio data was made, and the effects
rendered to it immediately and destructively, and Audacity would keep both
versions around? The "dry" version of the audio data would be kept around
for if the user turns effects off or if Audacity needs to re-render the
effects stack, and the "wet" version of the audio data is kept around
playback and exporting?

I like this solution because it involves no real-time effects rendering, it
allows the exporting to happen exactly as fast as it happens right now, and
it does not significantly increase the requirements on hardware, other than
the extra hard drive space needed to store two versions of each track with
effects. What do you guys think?

Finally, I should let you know that I'm not a Summer of Code student, I'm a
professional software developer who is also a recording musician, and thus
I'm not eligible to do SoC. Also, I was expressing my WTF on your continued
usage of CVS when SVN has been out for four years. In any case, I'll pull
Audacity out of CVS soon (ick) and start mucking around in the source code.

PS: Where's the bug tracker? I want to look up why muted tracks aren't saved
to the project file or recognized during export.

-- 
Jorge Rodriguez
Matrieya Studios, LLC
Email: jro...@ma...
Phone: (919) 757-3066