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

[James C. <cr...@in...>]

Jorge Rodriguez wrote:
> 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. 
I don't see it as elitism, more a sign of an already overstretched team 
- as we are too, but that's another story.  Ardour have in fact built 
experimental Windows versions.  There is an experimental version of Jack 
that runs on Windows.  My ideal is that in time we would start using 
Jack too, finding ways to make it reliable on Windows.  If we get it 
right we and Ardour can then start plundering each others code.  
Certainly Paul isn't elitist about that - and is in favour of that 
happening, but he sees it as being probably too far in the future to be 
relevant at this stage.  Real time for Audacity would bring that day 
closer.  In the longer term our two projects need to be 'sharing 
technology' more.

> 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?
The main distinction between this and the actual plan is having a 
per-track effects stack rather than an overall one.  Our plan is to 
achieve the SAME user experience by tagging the single overall stack.  
That the overall effects stack is our undo-stack is 'just' an 
implementation detail that helps us get there in stages faster.

> 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?
We already have that information around for 'undo' so it wouldn't 
increase the hard drive space over what we use now.  We're storing not 
only the dry and wet end-result, but also all intermediate results too.  
By design, audio that is moved around is very cheap because we point to 
blockfiles rather than repeat them.  "What do you guys think?", yeah 
sure, that's where we want to get to.

> 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.
I read the 'CVS?' as 'what's that?' - meaning that you probably also 
wouldn't know what I meant by 'GSoC' in the next sentence either ! , so 
I might as well get both definitions out the way quickly and easily with 
links rather than spell it out.  We considered moving from CVS to SVN 
for GSoC, but decided against it.  That's mostly because we may be 
moving off sourceforge altogether after GSoC.  Moving twice is avoidable 
work.


--James.