[nama] Re: Bug/feature: Buss caching
- From: Joel Roth <joelz@xxxxxxxxx>
- To: nama@xxxxxxxxxxxxx
- Date: Thu, 2 Aug 2012 08:02:18 -1000
On Thu, Aug 02, 2012 at 12:52:26PM -0400, S. Massy wrote:
> 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.
Hidden, with the corresponding bus set to OFF (forcing
member tracks to OFF) seems reasonable to me.
Hidden, with member tracks set to OFF would be okay, too.
This setting, and how to reverse it, should be printed
on the terminal, logged, and associated with the
corresponding git commit.
> 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.
If rendering, would you want to cache as well, or *only*
render?
The only change you would need to make to the caching code
(in CacheTrack.p) would be how you invoke it, and a way to set
$complete_caching_ref, a code reference that is executed
after the caching run.
For analyzing with -ev, we already go through that exact process
for an esoteric function called 'automix'. That would be
the code to look at (in Mix.p).
Sounds like both will be fairly easy to do :-)
Joel
> Cheers,
> S.M.
> --
>
--
Joel Roth
Other related posts:
