Re: Editing notes in a separate file

[Carl Sorensen]

On 1/2/10 10:06 AM, "Michael J. O'Donnell" <address@hidden> wrote:

> You are proposing very good solutions for the short term production of
> scores. I am more concerned with the very long term management of the
> information.
> 
> The object is to
> 
> 1. have a file containing data entry from the MS which represents the
> uncorrected manuscript, and which (almost) never needs to change;
> 
> 2. introduce all changes, including musical corrections and adjustments,
> for performance scores, without modifying the MS data entry.
> 
> For the short term, the tag method is a very good way to produce
> multiple versions in a project involving one person or small group of
> collaborators. In the case of a historical MS, there should be one
> representation of the MS, archived and (almost) never changed. Various
> derived scores should be produced separately from the MS representation,
> using it as input. The editors of the derived scores may be completely
> independent of those who produced the MS representation.
> 
> Sure, a future editor may take a copy of the MS representation, and
> modify it. But each such step introduces extra confusion in the
> information, and leads to other sorts of errors.
> 
> I was trying to keep the description short, but I guess I provided too
> little information. Here's some context:
> 
> I have  a beautiful facsimile of the Canonici Misc MA, Bodleian 213,
> which I acquired on a whim when I was singing a DuFay song taken from
> the MS. I wondered whether Lilypond provided a notation in which it
> would be sensible to typeset the entire MS in a form that looked a lot
> like the MS, allowed for very easy proof reading of the data entry (and
> discussion of the questionable choices), then also allowed systematic
> editing of performance scores in modern notation, with a variety of
> editorial choices.
> 
> I started experimenting with the first song, covering 3 folio sides. I
> observed the fundamental problems with Lilypond's support of mensural
> notation, but I can work on prototypes that will be easy to adapt when
> developers fix that part of Lilypond some day. I cooked up my own
> prototype of a set of macros that produce mensural notation or modern
> notation from parameters (this is not quite trivial, since Lilypond's
> representation of mensural durations is a bit tangled, and even
> ambiguous regarding actual performance duration in the case of perfectum
> vs. imperfectum).
> 
> I have reached the point where I produce crude but somewhat useful
> prototypes of both the mensural and modern notation. Synchronizing
> duration between the three voices in the modern notation currently
> requires me to enter corrections in the primary representation of the
> notes from the MS. Tags make it easy to include or exclude those
> corrections, but I am still faced with entering every variant of every
> correction into the MS data, which would be better left alone while
> editing the modern version. The problem is not so much the tags that I
> enter now (although the need to experiment with a variety of different
> synchronizations already makes it a pain), but with those that I or
> someone else would want in 10 or 20 years or even much later. MSs and
> information of this sort lie fallow for a long time before reaching users.
> 
> I didn't expect Lilypond to have the right feature for this
> information-management problem, and I expect to either scale back the
> goal of the work, or to work out some preprocessing with tools outside
> of Lilypond (which degrades the robustness of the product, since other
> users need to collect the same tools). In the hope that I had overlooked
> something (I've read the whole notation manual, but there are clearly
> things that haven't made it in yet---I've found some of them in the
> *.scm and *.ly sources but there are bound to be others that I've
> missed) I posted the query.
> 
> Regarding my own knowledge: I am the merest dilletante regarding ancient
> music, and piece together my editorial decisions from Wikipedia articles
> and other easily accessible sources. I don't hope to produce an
> authoritative edition of Bodleian 213, only something that's
> structurally convenient to correct using better knowledge from my
> further learning or from real experts. On the other hand, I am an
> expert, with decades of experience, in information management. I may not
> have explained the problem with continual addition of tagged corrections
> to the same original file of MS data very well, but it is a huge one
> that comes back to bite projects when someone revisits data after some
> years.
> 


May I suggest that the proper way to handle this is not to try to turn
LilyPond into an information manager?

Instead, the proper way is to use an information manager with LilyPond.

I would recommend that the semantically appropriate way to handle this is to
stop thinking of a piece as a single file, and instead, think of it as a git
repository (or the equivalent, but I think git is *perfect* for this
application).

Each different edition is a different branch on the tree, and the LilyPond
file *for that branch* is changed, but the original manuscript file is still
available in the master branch.

Changes in the manuscript file can be applied to each branch via git's
patching algorithms.  And if desired, custom git commands that will
automatically apply changes to the source manuscript to every other edition
could be created.

Each different edition is then available as a branch, to be run through
LilyPond at any desired time.

And the changes between the different editions are easily available through
the git diff command.

HTH,

Carl