[nama] Re: Bug/feature: Buss caching
- From: "S. Massy" <lists@xxxxxxxxxxxx>
- To: Joel Roth <joelz@xxxxxxxxx>
- Date: Thu, 2 Aug 2012 12:52:26 -0400
Hello,
Lots of ideas floating around here.
Here is how I would expect cache to work. Cache works on whatever track
I'm on intelligently: if it's a user-track, the track is cached, if it's
a buss, the output of that buss (minux vol/pan) is cached and all the
member tracks are put out of harm's way until uncached. If I want member
tracks cached but keep the buss mix-track live, all I have to do is use
a for statement on the member tracks and cache them individually.
Another important point to consider is that flesh is weak and brain
doubly so, and we should make it somewhat difficult for someone to muck
about with member-tracks of a cached buss: they should all be set to
off, of course, but perhaps they should also be moved to a "frozen"
pseudo-buss, the purpose of which is to hide/hold inactive tracks and
remind the user of that status.
Finally, and on a somewhat unrelated topic, I am pondering trying my
hand at duplicating and modifying (or at least learning from) the
caching code to achieve to operations: rendering and analysing.
Rendering would be much like caching, except it would be a one time
operation and the resulting audio would be dumped in a separate "render"
directory: its purpose is to make it easy to export submixes. Analysis
would be like rendering to null and paging the output of the -ev op to
the console, and its purpose is to give an idea of how much effects are
affecting the signal.
Cheers,
S.M.
--
Other related posts:
