[nama] Re: Git for undo/redo and managing state
- From: "S. Massy" <lists@xxxxxxxxxxxx>
- To: nama@xxxxxxxxxxxxx
- Date: Mon, 7 May 2012 17:25:57 -0400
On Mon, May 07, 2012 at 10:06:18AM -1000, Joel Roth wrote:
> On Mon, May 07, 2012 at 02:56:38PM -0400, S. Massy wrote:
> > Trying to imagine my workflow, this is what I see:
> > - Saving (committing) is the standard way of saving and would only take
> > messages on rare occasions when something specific was done.
>
> yes, we have an autosave (for undo/redo) under
> consideration, so the standard save could have
> a slighly different message.
>
> There would be one command to undo, another to go back to the
> previous user save.
Sounds like a great idea.
> > > We may want to decouple the currently selected Mixdown
> > > version from the commit, perhaps by deleting the version
> > > field from the Mixdown track before saving.
>
> > I'd like to take it further however and have
> > the ability to "discard" and "approve" mixdowns, especially the former.
> > In a typical project, I sometimes end up with 20 mixdowns, half of them
> > pointless and it can get confusing. I'd definitely like to have the
> > ability to discard a mixdown (decoupled from commit and file erased). A
> > possibly useful counterpart tto that command might be an "approve"
> > command where the commit is tagged and an optional message added, either
> > to the commit or the version comment for the mixdown.
>
> Mixdown is less important if you are using tagged commits.
> I think you would use it mainly for final export...
> unless you're a person who believes in the reality
> of a WAV file more than the label of a commit
> or tag. :-)
There are a couple more reasons to mix down, including:
- Cross-checking a mix on different monitoring systems.
- Using ecasound's -ev op or ecasignalview to look at levels. (This is a
step which could be skipped if we could do this from within nnama, i.e
mixdown to null with an -ev op.)
- Simple and pure insurance.. (If you've got a perfect drum mix, it's
good to have a wave of it in case a json-eating alien finds its way
into your computer.)
>
> > > Should the Mixdown track even allow effects?
> > That would be bad practice, imho. Effects belong on tthe master
> > buss or in the mastering chain.
>
> If effects got onto the Mixdown track, you wouldn't be reliably
> auditioning your mixdowns, which would suck.
> So we should really prohibit that (TODO).
Probably. Imagine if you added effects there by mistake (thinking it was
a user track): it could potentially have a very confusing outcome.
>
> > > ### Undo/Redo
> > >
> > > Just wondering if any of you doing bigger projects
> > > can remember how long saving state takes.
> > > If it's fast enough, I'd like to use git for
> > > undo/redo as well. That would be gravy!
> > Saving is pretty much instantaneous, even on larger project. There is
> > something we need to consider, however, when approaching undo/redo and
> > autosaving/committing. A tree full of meaningless commits would make
> > project management very difficult and undo/redo next to useless. To
> > avoid this, we would need to ensure that only when something relevant to
> > the audio has been done do we allow automatic commit. For instance,
> > mute/solo should not trigger auto-commits, but effect insertion or
> > adjustment should. Very roughly, the logic should probably be something
> > like this:
> > if ($current_time - $last_commit_time >= $save_interval &&
> > $project->{is_dirty}) {
> > commit $current_time;
> > $last_commit_time = $current_time;
> > }
>
> That is reasonable logic for autosave. undo/redo is more like this:
>
> nama> modify_effect AC,AD,V 1,5 * 0.75 # oh shit! it was supposed to be AV,
> not V
So we would need to identify those commands requiring a commit when
isued.
>
> nama> undo # go to the refrigerator for coffee or beer
Iow, with undo/redo capability, you can allow yourself more and more
varied stimulants on the job. :)
>
> I think frequent commits are okay if they are cheap, and
> if we can distinguish commits made by user saves.
>
> There are ways to hide the multiple commits, too.
> They can be squashed into a single commit.
> Or simpler, we could have a separate 'undo' branch that we
> would save incremental changes. At the next user save,
> we would do:
>
> git checkout master
> git merge undo --no-ff
>
> On the master branch at B and C below you would see a single
> commit: Merge 'undo' into 'master'
I like that idea a lot. That would give a lot of flexibility whilst
preserving legibility in the working branches.
> Isn't this cool?
Definitely!
Cheers,
S.M.
Other related posts:
