[nama] Re: Git for undo/redo and managing state
- From: Joel Roth <joelz@xxxxxxxxx>
- To: nama@xxxxxxxxxxxxx
- Date: Mon, 7 May 2012 10:06:18 -1000
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.
> - Tagging would be the preferred way of keeping track oof rough stages in
> a project.
> > save -t premix -m "Balanced levels, will now apply effects."
> (In current nama, I would save state as premix.json)
I note that tags need a message option
> > 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. :-)
> > 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).
> > ### 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
nama> undo # go to the refrigerator for coffee or beer
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'
The graph would look something like this:
master A - B - C
\ /\ /
undo-* A1-A2-A3 B1-B2-B3
Isn't this cool?
Regards,
>
> Cheers,
> S.M.
>
--
Joel Roth
Other related posts:
