[linux-audio-dev] Freeze?

[Paul Davis]

>     I want my plug-ins frozen the instant I close the parameter editor. ;)

oh, you don't want to do any graphical editing of plugin parameter
automation? :))

>     Agreed, it's a very definite trade-off - storage space for CPU cycles.  
>It is my observation, however, that storage space is cheap, and readilly 
>available.

not my experience. 

>> sorry, but i don't think so. if i have a bus that is channelling audio
>> in from an external device (say, a h/w sampler), you cannot possibly
>> freeze it.
>
>     However, buses which simply contain a submix of several audio tracks can 
>be safely frozen, saving both processing power and disk bandwidth.

sure, but thats a subset of all busses. its not a bus per se.

>     When I finish comping the vocals for a chorus, I want to be left with 1 
>fader, and 1 editable audio track, for the chorus.  If I need to make one of 
>the voices softer, I can bring up the underlying tracks within a second 
>(which is *at least* how long it usually takes me to find a single fader in a 
>48-channel mix).  While I'm making adjustments, Tinara will read all the 
>separate chorus tracks off the disk, mixing them in RT.  When I move back one 
>layer in the mix hierarchy (thereby indicating that I'm finish adjusting 
>things), Tinara will begin re-rendering the submix in the background whenever 
>the transport is idle.  

have you actually experienced how long it takes to "re-render"?
steve's suggestion is an interesting one (use regular playback to
render), but it seems to assume that the user will play the session
from start to finish. if you're mixing, the chances are that you will
be playing bits and pieces of of the session. so when do you get a
chance to re-render? are you going to tie up disk bandwidth and CPU
cycles while the user thinks they are just editing? OK, so you do it
when the transport is idle - my experience is that you won't be done
rendering for a long time, and you're also going to create a suprising
experience for the user at some point - CPU utilization will vary
notable over time, in ways that the user can't predict.

you also seem to assume that the transport being stopped implies no
audio streaming by the program. in ardour (and most other DAWs), this
simply isn't true. ardour's CPU utilization doesn't vary very much
whether the transport is idle or not, unless you have a lot of track
automation, in which case it will go up a bit when rolling.

>     The basic idea is to turn mixing into a process of simplification.  When 
>I'm finishing up a mix, I don't want to deal with a mess of tracks and buses, 
>with CPU power and disk bandwidth being given to things I haven't changed in 
>days.  I want to be able to focus on the particular element or submix that 
>I'm fine-tuning - and have as much DSP power to throw at it as possible.

the focusing part seems great, but seems to be more of a GUI issue
than a fundamental backend one. it would be quite easy in ardour, for
example, to have a way to easily toggle track+strip views rather than
display them all.

the DSP power part seems like a good idea, but i think its much, much
more difficult than you are anticipating. i've been wrong many times
before though.

and btw, the reason Ardour looks a lot like PT is that it makes it
accessible to many existing users. whether or not ardour's internal
design looks like PT, i don't know. i would hope that ardour's
development process has allowed us to end up with a much more powerful
and flexible set of internal objects that can allow many different
models for editing, mixing and so forth to be constructed. the backend
isn't particularly closely connected in any sense, including the
object level, to the GUI.

--p