[nama] Re: Git for undo/redo and managing state


On Sun, May 06, 2012 at 09:33:23PM -1000, Joel Roth wrote:
> ### Managing state with git
> Three ways user can use git-based saving:
> 1. make a commit
>  + purpose: to save state (may be automated)
>  + invoke by: save -m <message> (-m is optional)
> 2. tag
>  + purpose: to identify the HEAD commit at any significant
>    moment in project development
>  + invoke by: tag <tagname> or using -t <tagname> as argument to save
>  + tag <commit_id> can be used to tag any git commit
> 3. branch
>  + purpose: to direct development along a new path
>  + invoke by: branch <branchname> or using -b <branchname> 
>    as an argument to save
>  + -b <branchname> can only create a new branch
>  + branch <branchname> can select a different existing branch
> Comments:
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.
- 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)
- Branching use-cases would include:
   - Trying out an idea, to be deleted or merged (staging).
   - Trying out alternate processing for possible A/B'ing (parallel,
   - Offering alternate mmixes or remixes (parallel,
   ...but is less likely to be used in a project than the first two
   methods described.

> ### Special considerations:
> Mixdown
> When we create a mixdown, we can associate a Mixdown
> version (Mixdown_3.wav) with the commit used to make it.
> I might want to use version comments to record
> this association. In that case, track and version comments
> should be separated out from the git-managed project
> data structure. Perhaps a file named project_comments.json.
> 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.
> The reason is that if we go back to an earlier commit, the
> currently selected Mixdown version should not change.
> Although if we go to exactly the commit used to generate
> Mixdown_2.wav, we should tell the user. (Generally, it will
> work the other way: she listens to Mixdown_2.wav and decides
> to go back to the corresponding commit.)
It all sounds fine to me. 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.

> However if someone applies effects to the Mixdown track,
> obviously the saved state should certainly associate with a
> particular version.
> Or does a Mixdown track even allow effects? Should it
> allow effects?  The details are complicated!
That would be bad practice, imho. Effects belong on tthe master
buss or in the mastering chain.

> Track caching
> This seems like it should be similar to handling mixdown,
> but we do it differently.
> We will use effect chains to store the effects, inserts and
> original track version number used to generate a new WAV
> file.
> (Up to now we didn't manage inserts, but I think we need
> this.)
> That will let us go back to the dynamic form of a previously
> cached track.
> Effect chains used for this purpose will be outside the
> git-managed project data structure
> (project_effect_chains.json)
Sounds right to me.

> ### 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;
...or something of the kind.


Other related posts: