> 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
