[nama] Re: Serialization stuff
- From: Joel Roth <joelz@xxxxxxxxx>
- To: nama@xxxxxxxxxxxxx
- Date: Sun, 18 Sep 2011 09:53:47 -1000
On Sun, Sep 18, 2011 at 11:52:18AM -0400, S. Massy wrote:
> On Sat, Sep 17, 2011 at 10:17:26AM -1000, Joel Roth wrote:
> > I'm still working on this. Last night I tore out
> > some ugly old code.
> That always feels good. Out with the old, in with the new!
Yeah, it does feel good, but it's taking a while...
> > I'm also thinking about a couple other issues:
> > * using git to manage project data
> > * latency compensation
> >
> > Latency compensation, if well thought out,
> > might even allow you to use a hardware effect
> > via the soundcard as an insert, and still
> > keep alignment with all the other signals.
> That would be seriously cool!
> > One issue is calculating the latency in
> > the different arms of the signal-processing network.
> > A second issue is determining the latency of
> > other components of the system, such as the
> > soundcard input and output, that might need
> > to be factored in.
> I'm not sure how you would achieve the first, but the second can be
> fairly easily done using a utility like Fons adriansen's jack_delay
> and a patch cable on the sound card.
For the first, each LADSPA effect reports its own latency.
When several tracks belong to a bus, we
get the longest latency and adjust all sibling tracks to the
same amount. (I have two ways to adjust the latency. One is
by making a change to the 'playat' value for the input. The
other is using a plugin such as LCR Delay.)
Each Ecasound loop device introduces a specific
latency that we also have to add in.
I think that the soundcard latency reported by jack_delay
might also help make a reasonable estimate for soundcard delay under ALSA
> >
> > Git might help branched development.
> > Thinking about syntax, perhaps something like this:
> >
> > nama> save sax_left -m "mix with sax placed to the left"
> >
> > If save_state/git-commit is fast enough, every change of
> > state could be stored as a commit, useful for undo/redo.
>
> Really funnyyou should mention that. Yesterday I just completed a fairly
> big (to me) project for someone, something like 8-10 tracks with loads
> of plugins and fades (nama held up relatively well BTW, though I will
> follow up with a list of bugs :-) ). Anyway, I saved often, of course
> using names like roughmix[1-9], polishedmix[1-9], finalmix[1-9], etc,
> but soon started to forget which number was at which stage and wished
> for something more like a revision control system with timestamps and
> "changelogs". Eventually, I grew dissatisfied with my first
> mix/treatment of the vocals and link_tracked to a second, alternate
> vocals track and ended up with 2 final mixes to show. At this point, I
> would have sold my soul for an RCS style mechanism. So, to cut a long
> story short, I'm very interested in this idea.
Nice to hear that Nama stands up to "industrial" or
"professional" use. (I anticipate your bug list. :-)
Regarding RCS, here are a couple ideas
1. I think RCS is a great way to handle projects, and gives
a huge advantage over the simpler save mechanisms
of most other DAWs.
2. If we simply track State.*, polished_mix would be a
branch.
nama> save polished_mix
would create a branch, the file names State.* would be unchanged.
3. For the user, it might be convenient to have a state file
polished_mix as well. (It also might invite some confusion
if a user expected to be able to edit it directly. We could
discourage that with read-only permissions or a warning
at the top of the file.)
4. What do we do about .namarc, asoundrc, jack parameters, etc?
+ if we don't track them, do we have a sufficiently
reliable representation of the project?
+ if we do track them, our RCS gets very complicated
+ in general .namarc is project independent
+ but specifics (such as Ecasound command-line arguments) could change
in a project
+ we have code (long unused) for per-project namarc
+ project-specific namarc may be confused with ~/.namarc,
modifying latter won't help if there is a
~/nama/project/namarc
+ maybe we need some way to archive a project, saving
the state of all relevant files, so that later
housecleaning does not break old project.
+ in particular .effect_chains picks up cruft from
multiple projects, better that system-generated
effect chains for a project be kept in that
project's State file.
That is my brain dump for this morning!
Regards,
Joel
> Cheers,
> s.M.
>
--
Joel Roth
Other related posts:
