26 Feb
2004
26 Feb
'04
11:09 a.m.
It was, however, the automatic merits that I wished
mainly to explore.
Freezing has it's merits, but it requires that you dedicate some brain cycles
to deciding when and where you wish to freeze/unfreeze something. I could
sure use those cycles for keeping creativity flowing.
remember: freezing has no merits at all unless you need to save CPU cycles.
the problem is that in a typical DAW session, you can potentially
freeze most tracks most of the time. so how can you tell what the user
wants frozen and what they don't? More importantly, freezing consumes
significant disk resources. Can you afford to do this without it being
initiated by the user? A typical 24 track Ardour session might consume
4-18GB of audio. Freezing all or most of it will double that disk
consumption (and its not exactly what you would call quick, either :)
thus, either you have s/w smart enough to figure out what to freeze
and then do it, which does not come without certain costs, or the user
has to play a significant role in the process.
... and I do think you can freeze a bus, but it
requires that the app has full
knowledge of the connection graph. Mmmm, I see a jack extension forming ;))
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.
--p