>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
