[nama] Re: Bug/feature: Buss caching
- From: "S. Massy" <lists@xxxxxxxxxxxx>
- To: Julien Claassen <julien@xxxxxxxxxxx>
- Date: Fri, 3 Aug 2012 21:07:10 -0400
[...]
On Thu, Aug 02, 2012 at 09:39:59PM +0200, Julien Claassen wrote:
> I have no really good ideas about analysing the audio yet. There
> are several possibilities. One of course being, to directly just
> pass the input through -ev or -ezf options respectively and print
> the output to the screen. For volume analysis there already does
> exist the ecasignalview. this would take a seperate console to run
> and it doesn't keep all the necessary info, that one might want.
What' I'm after here is the break-down that -ev returns, which, though
not the most precise, still remains as useful a piece of information as
one can get on the command-line. I'm already doing this fairly routinely
for unprocessed tracks, but it would be very useful to be able to do
this for an arbitrary processed track or buss from within nama.
> A third alternative, if already writing a function for analysis,
> one might parse the output of -ev and/or -ezf and stored data. Even
Now that would be a really cool solution: have analysis ops on every
tracks and store their outputs on every run. Unfortunately, I don't
think one can easily achieve this with ecasound. In fact, ecasound's
analysis ops seem a bit of a hack to me in so far as they do not
implement a uniform way of reporting their data to a user, and far less
so to a front-end like nama. Their were implemented in the early days,
before the ECI was invented/implemented. It would be exceedingly
sexy to have a series of analysis ops in ecasound with a common
interface and both real-time and cumulative outputs.
[...]
> I'm sorry to be so unorganised again, but just a last short
> comment on the caching: I hope you didn't get me wrong, I never
> wanted cache on a bus-mix-track to cache the member tracks
> separately. I only suggested, that there might be two ways of
> caching the bus-mix-track: 1. just use it as a mixdown track for its
> member tracks, i.e. not caching effects, that are applied to the
> mixtrack itself. 2. cache the bus-mix-track with everything: a) its
> member tracks piped into it, with all their seperate processing and
> b) effects and/or inserts, that are applied to the bus-mix-track
> itself. That would mean, that after caching, the effects from the
> bus-mix-track would be removed, as happens with caching a normal
> user-track.
From a caching standpoint, I don't think there is much advantage in
implementing a simple pre-effect mixdown approach, since the only gain
you would have over simply caching all member-tracks would be a slightly
lower disc-throughput, while at the same time losing the ability to
modify individual faders. From a rendering/exporting standpoint, this
makes more sense, but that easily be achieved by bypassing all effects
on a buss before performing the operation.
> TTFN
Every time you write this, I have this image of you bouncing away
through the trees.
Cheers,
S.M.
Other related posts:
