Re: Extracting a "score diff" from two [or more] Lilypond sources
Hi there, > It would provide a way for people who should learn how to use version control > to kick that can down the road a while longer. Well put. =) I'm happy to work with Jean and Valentin's suggestions/snippets for now. Thanks to everyone for the helpful input! — Kieren
Re: Extracting a "score diff" from two [or more] Lilypond sources
On Mon, Jan 24, 2022 at 05:02:14PM -0800, Flaming Hakama by Elaine wrote: >On Mon, Jan 24, 2022 at 3:40 PM Kieren MacMillan ><[1]kie...@kierenmacmillan.info> wrote: [...] > I think it's fair to state that the vast majority of people using > Lilypond don't use version control. > >Sure, that may be the case. >On the other hand, do most lilypond users have this issue? >In any case, for anyone who does have this sort of a workflow task >to accomplish, >I would suggest that it is in their interest to learn to use git. >You might as well also ask, do the majority of lilypond users back >up their files regularly? >I'd guess most probably don't, or not regularly enough. >But if they decided to use git, they could get that for free. >Want to collaborate on projects? I mean the list goes on. Sorry for barging in here, but I second this recommendation. One can certainly do useful work with lilypond using a careful, manual system of backup files (and perhaps zip files if your project is large). But because it's manual, it's also error-prone, liable to human error, and, in a long-term project, time-consuming and hard to manage. Using a real version control system (not necessarily git -- though I do recommend it -- but whatever version control software you fancy) alleviates most of the tedium of managing backups yourself, does so reliably, stores copies of *all* versions of your project should you at some point suddenly need to revisit an old version from several months ago (that you may have discarded the backup of, in the manual system). It makes it convenient for collaborative projects, remote off-site backups are within a few keypresses, etc.. Better yet, in my own lilypond projects I've used git branches to make experimental changes -- while composing, perhaps an idea strikes that requires intrusive changes; no problem, start a new branch, sketch it out, if it turned out to be a bad idea after all, just discard the branch and go back to where I left off and keep going with the original version. No fiddly manual backup system and confusing yourself over exactly which backup was the last "good" one. If it turned out to be a good idea, merge it back to the main branch and keep going. Sometimes multiple ideas strike; I try each of them in turn, each in their own branch, then pick the best of the crop. What is *not* to recommend? I can see only advantages to using version control software. Yes it requires effort to learn, but it totally pays off in the long run. More than compensates for the initial learning curve for the convenience, reliability, and power it gives you. It takes a huge load off your shoulders for managing an intricate, fragile system of manual backups, and puts new power at your fingertips. This is true not just for lilypond projects; in fact I recommend version control for *any* project that involves extensive editing of some product over an extended period of time. And you get diffing between any two versions of your project for free. The one thing I can see here that could sweeten the deal even further, is a tool that takes a version control diff and generates a lilypond score with the changes highlighted somehow. Say in red and bold font, for example, or as ossia staves. Now *that* I can see as a valuable undertaking, if it can be pulled off. T -- Javascript is what you use to allow third party programs you don't know anything about and doing you know not what to run on your computer. -- Charles Hixson
Re: Extracting a "score diff" from two [or more] Lilypond sources
On Mon, Jan 24, 2022 at 3:40 PM Kieren MacMillan < kie...@kierenmacmillan.info> wrote: > Hi Elaine, > > > You're probably not going to appreciate this suggestion, > > because it does not aspire to the auto-magic you desire. > > However, it is clear to me that the best practice for all software dev > is to use commit messages. > > I do appreciate the detailed and considered response. > > That being said… ;) > > As with most of the programming I do — in Lilypond and otherwise — a > primary goal of mine is to create things that are useful *for the largest > number of people* (not just me). I appreciate that sentiment. > I think it's fair to state that the vast majority of people using Lilypond > don't use version control. Sure, that may be the case. On the other hand, do most lilypond users have this issue? In any case, for anyone who does have this sort of a workflow task to accomplish, I would suggest that it is in their interest to learn to use git. You might as well also ask, do the majority of lilypond users back up their files regularly? I'd guess most probably don't, or not regularly enough. But if they decided to use git, they could get that for free. Want to collaborate on projects? I mean the list goes on. > In addition to making my own workflow easier [than it would be if I had to > micro-schedule my edits, micro-commit with flags/comments, *not* do other > edits at the same time, etc.], You only need to micro-schedule as much as suits your workflow. A commit that says "cut m57-122 in Song X, and started fixing articulations in woodwinds in Song Y" would be just as useful for the end purpose as having separate commits. > I'm hoping the tool might be useful for any Lilypond user [using version > control or not] who wanted to compare the musical content of two score > sources. > That does sound to me like version control. We have 2 score sources that are mostly the same, so much so that you only want to know the differences. But they are not versions of the same thing? Sounds like version out-of-control. But seriously, I get the intent. The humourous slant on it would be to say that It would provide a way for people who should learn how to use version control to kick that can down the road a while longer. > I look forward to seeing how far I can get with the "automagic" solutions > before compromising on a solution that requires version control at all > (never mind highly-granular use of v.c.). > > Thanks, > Kieren. My curiosity in this would guess the next step in an automated approach would involve compiling each score to the lilypond model, then printing that. Then comparing the two as text file diffs. I'm not sure that would yield consumable results. But it would be attempting to compare two semantic representations. Thanks, Elaine Alt 415 . 341 .4954 "*Confusion is highly underrated*" ela...@flaminghakama.com Producer ~ Composer ~ Instrumentalist ~ Educator -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Re: Extracting a "score diff" from two [or more] Lilypond sources
Kieren MacMillan writes: >> So? I can assure you my kitchen table is perfectly useful for me even >> though the carpenter did not constrain themselves to use only the kind >> of tools that I myself have in the house. >> >> And frankly, I would not think of paying them for the additional effort >> taken by hobbling themselves in that manner. > > Um… wut? That makes zero sense. An analogy that actually fits what > we're talking about would be a chef who gave you a recipe which is > impossible to execute without an appliance to which you have no > access. > > — Kieren Kieren, just who is the target for which you are planning to keep your tools for extracting version change information for your musicians confined to some set of persons without access to version control and presumably also not to versions other than some marked printed copies? The last commit in the LilyPond codebase from you has been in 2010, and using OpenLilyLib takes installing and updating it via Git, doesn't it? So how are you planning to give those tools not requiring version control to people, and how are they going to get access to versioned compositions to apply them to? I just have problems figuring out the rationale behind that constraint. -- David Kastrup
Re: Extracting a "score diff" from two [or more] Lilypond sources
> So? I can assure you my kitchen table is perfectly useful for me even > though the carpenter did not constrain themselves to use only the kind > of tools that I myself have in the house. > > And frankly, I would not think of paying them for the additional effort > taken by hobbling themselves in that manner. Um… wut? That makes zero sense. An analogy that actually fits what we're talking about would be a chef who gave you a recipe which is impossible to execute without an appliance to which you have no access. — Kieren
Re: Extracting a "score diff" from two [or more] Lilypond sources
Kieren MacMillan writes: > Hi Elaine, > >> You're probably not going to appreciate this suggestion, >> because it does not aspire to the auto-magic you desire. >> However, it is clear to me that the best practice for all software >> dev is to use commit messages. > > I do appreciate the detailed and considered response. > > That being said… ;) > > As with most of the programming I do — in Lilypond and otherwise — a > primary goal of mine is to create things that are useful *for the > largest number of people* (not just me). I think it's fair to state > that the vast majority of people using Lilypond don't use version > control. So? I can assure you my kitchen table is perfectly useful for me even though the carpenter did not constrain themselves to use only the kind of tools that I myself have in the house. And frankly, I would not think of paying them for the additional effort taken by hobbling themselves in that manner. -- David Kastrup
Re: Extracting a "score diff" from two [or more] Lilypond sources
Hi Elaine, > You're probably not going to appreciate this suggestion, > because it does not aspire to the auto-magic you desire. > However, it is clear to me that the best practice for all software dev is to > use commit messages. I do appreciate the detailed and considered response. That being said… ;) As with most of the programming I do — in Lilypond and otherwise — a primary goal of mine is to create things that are useful *for the largest number of people* (not just me). I think it's fair to state that the vast majority of people using Lilypond don't use version control. In addition to making my own workflow easier [than it would be if I had to micro-schedule my edits, micro-commit with flags/comments, *not* do other edits at the same time, etc.], I'm hoping the tool might be useful for any Lilypond user [using version control or not] who wanted to compare the musical content of two score sources. I look forward to seeing how far I can get with the "automagic" solutions before compromising on a solution that requires version control at all (never mind highly-granular use of v.c.). Thanks, Kieren.
Re: Extracting a "score diff" from two [or more] Lilypond sources
> > > -- Forwarded message -- > From: Kieren MacMillan > To: David Kastrup > Cc: Lilypond-User Mailing List > Bcc: > Date: Sat, 22 Jan 2022 17:34:31 -0500 > Subject: Re: Extracting a "score diff" from two [or more] Lilypond sources > Hi David, > > > What version control system are you using for your score? It will > > probably easiest to look at the source code diffs and do a manual > > summary from those. > You're probably not going to appreciate this suggestion, because it does not aspire to the auto-magic you desire. However, it is clear to me that the best practice for all software dev is to use commit messages. Commit often, once per thing that you'd like noted in your report, and with a meaningful commit message. Then your commit history is your report. > > The problem is that during various stages of composition / arranging / > engraving / coding: >1. there can be huge differences in code that represent only a few > small differences in notated output; > This is why you want to use messages to specify the intent of the commit. >2. there can be very small differences in code that represent > many/large differences in notated output; and > Another reason to use messages to specify the intent of the commit. >3. there can be many, many small changes in code (cleanup, > variable-izing, moving tweaks to/from the edition-engraver, file splitting, > etc.) that literally have *no* effect on the notated output. > You have the decision to either commit granually, so some commits would not be relevant to your report. Or, this stuff can be included as part of things that are relevant. Which would make this rather like the first case. > > Especially in the third case, combing through all those changes to > manually summarize changes worth noting to others would be time-consuming > and error-prone. If my process were more luxurious, I'd do a "'notable > changes' only" pass, manually summarize the diff(s), and then do the other > code work in a separate pass — the issue is that the timeline of a workshop > doesn't grant me that luxury, so I was hoping there was an automagic way of > figuring out exactly and only those things that needed to be communicated > to the MD/performers in any given score update. > The place to do this is as you work on it, not after. Since these changes are being requested of you, you probably know what the edits are going to be before you start coding, yes? So then, as you go down your list of edits to make, as you fix each one, commit the code with a message referencing the task you just completed. When you are done, your commit history will document the work you accomplished. If, for some reason, you do not know the list of edits you are going to do when you sit down to work, then you just have to do it as you go. When you complete something that is worth reporting, make a commit with a message. Doesn't matter if the entire work is incomplete, since the purpose of partial commits is the message. If you need to distinguish between partial commits and release-able versions, the typical way is to use git tag to identify which ones are stable. And/or adopt a commit message strategy that clearly identifies which ones represent a release. I know this won't help retroactively. But I suspect it should be an easy workflow to adopt since the overhead to making incremental commits is tiny. > > Thanks, > Kieren. > HTH, Elaine Alt 415 . 341 .4954 "*Confusion is highly underrated*" ela...@flaminghakama.com Producer ~ Composer ~ Instrumentalist ~ Educator -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >
Re: Extracting a "score diff" from two [or more] Lilypond sources
Hello Kieren, as long as we can store the Information in the file such formatting things can be easily done from within Lilypond. I'll try to do a small example. Cheers, Valentin 23.01.2022 17:32:01 Kieren MacMillan : > Hi Valentin, > >> What about this: We could have a small script that takes a diff of the new >> file >> and the old file and creates a new version of the new file where all changed >> (music) lines are tagged. This way we do not need to try to match two streams >> against the other one, but we do in already know more or less the parts that >> have changed and the parts that haven’t. > > Oh! This could work as a replacement or even complement to the changes [text] > list. > Could this script, for example, colour all changes red (qv. the regression > tests and how the differences are visually obvious)? > > Thanks, > Kieren.
Re: Extracting a "score diff" from two [or more] Lilypond sources
Hi Valentin, > What about this: We could have a small script that takes a diff of the new > file > and the old file and creates a new version of the new file where all changed > (music) lines are tagged. This way we do not need to try to match two streams > against the other one, but we do in already know more or less the parts that > have changed and the parts that haven’t. Oh! This could work as a replacement or even complement to the changes [text] list. Could this script, for example, colour all changes red (qv. the regression tests and how the differences are visually obvious)? Thanks, Kieren.
Re: Extracting a "score diff" from two [or more] Lilypond sources
Hi Kieren, What about this: We could have a small script that takes a diff of the new file and the old file and creates a new version of the new file where all changed (music) lines are tagged. This way we do not need to try to match two streams against the other one, but we do in already know more or less the parts that have changed and the parts that haven’t. Cheers, Valentin Am Sonntag, 23. Jänner 2022, 16:40:47 CET schrieb Kieren MacMillan: > Hi Valentin, > > > While it is theoretically possible to compare two streams of music events > > it would also require lots of logic to properly do what we want. > > I'm up to the challenge of building that logic! =) > > > One way to achieve what you want could be storing the > > whole history in the source. > > Oof… way too much admin brainpower required for that. I don't know the speed > at which other people compose / arrange / engrave, or the deadlines they're > faced with, but slowing down my creative process in order to write/enter > details on which changes should be communicated to the conductor/performers > and which don't have to be would likely be worse than the current situation > (which is me just manually noting the main changes as I make them, doing a > second cursory pass once the score is "final", and typing up the list to > include with the score). > > If I can't make the "compare two music streams" idea work, it really isn't > worth it (for me) to set up a different system which requires any real > manual input/focus. > > Thanks, > Kieren. signature.asc Description: This is a digitally signed message part.
Re: Extracting a "score diff" from two [or more] Lilypond sources
Hi Valentin, > While it is theoretically possible to compare two streams of music events > it would also require lots of logic to properly do what we want. I'm up to the challenge of building that logic! =) > One way to achieve what you want could be storing the > whole history in the source. Oof… way too much admin brainpower required for that. I don't know the speed at which other people compose / arrange / engrave, or the deadlines they're faced with, but slowing down my creative process in order to write/enter details on which changes should be communicated to the conductor/performers and which don't have to be would likely be worse than the current situation (which is me just manually noting the main changes as I make them, doing a second cursory pass once the score is "final", and typing up the list to include with the score). If I can't make the "compare two music streams" idea work, it really isn't worth it (for me) to set up a different system which requires any real manual input/focus. Thanks, Kieren.
Re: Extracting a "score diff" from two [or more] Lilypond sources
Hi Jean, > Minimal, but perhaps already usable? Astounding! I think this is totally useable for my purposes! Once this workshop is over, I'm going to dive in and see if I can turn this into an 'update reporting framework'. Thank you so much. Kieren
Re: Extracting a "score diff" from two [or more] Lilypond sources
Hi Kieren,
While it is theoretically possible to compare two streams of music events it
would also require lots of logic to properly do what we want.
One way to achieve what you want could be storing the whole history in the
source.
I have recently sent out this showcase example of how we can store more
information in our score and then extract this information automatically.
For example you could save each change with the date when you did it and
suddenly you can very easily compare different states of the score.
A different idea might be to use the point and click information stored in the
pdf. We could parse both pdfs of point and click coordinates, use diffs of the
source files to translate these coordinates and this determine which parts of
the pdfs have changed (or are at least close to a change).
Cheers,
Valentin\version "2.22"
%%% includeable BACKEND, content at line 225
#(define EDIT_DEBUG_MODE 'warning)
%{
Takes a list of edit ids and music and assigns ids to music. ids can be given as pair
'(id . val) where val is the local prevalence of the edit.
%}
edits =
#(define-music-function (ids music) (list? ly:music?)
(define (get-symbol tag) (if (symbol? tag) tag (car tag)))
(define (tag-music id music)
(ly:music-set-property! music 'edit-id (get-symbol id)))
(map tag-music ids (ly:music-property music 'elements))
(ly:music-set-property! music 'edit-ids ids)
music)
%{
Pick specific edits. Collisions are resolved using prevalence value. Triggers a
warning if in some place no specified edit exists. Change the value of
EDIT_DEBUG_MODE to 'suppress to not trigger a warning or to anything else to
trigger an error if this happens.
%}
selectEdits =
#(define-music-function (edit-ids-prevs music) (list? ly:music?)
(define (get-symbol tag) (if (symbol? tag) tag (car tag)))
(define (get-prev tag) (if (symbol? tag) 0 (cdr tag)))
(define (symbol-prev tag) (cons (get-symbol tag) (get-prev tag)))
(define ((complete-prev prev-vals) tag)
(if (pair? tag) tag
(cons tag (assoc-get tag prev-vals 0
(define (handle-hub music)
(let* ((local-tags (ly:music-property music 'edit-ids))
(edit-ids (map get-symbol edit-ids-prevs))
(prev-vals (map symbol-prev edit-ids-prevs))
(filtered-tags (filter (lambda (x) (member (get-symbol x) edit-ids)) local-tags))
(preved-tags (map (complete-prev prev-vals) filtered-tags))
(max-tag (car (reduce (lambda (x y) (if (> (cdr x) (cdr y)) x y)) (cons #f #f) preved-tags)))
(music-length (ly:music-length music))
(elements (ly:music-property music 'elements))
(selected-elements (if max-tag (filter (lambda (x) (equal? (ly:music-property x 'edit-id) max-tag)) elements) '()))
(tmp-joined-element (make-music 'SimultaneousMusic 'elements selected-elements))
(selected-length (ly:music-length tmp-joined-element))
(adjusted-elements (if (equal? selected-length music-length) selected-elements
(append selected-elements (list (skip-of-length music))
(ly:music-set-property! music 'elements adjusted-elements)
(if (not max-tag)
(if (equal? EDIT_DEBUG_MODE 'warning)
(ly:music-warning music "No available edit ID was selected!")
(if (not (equal? EDIT_DEBUG_MODE 'suppress))
(ly:music-error music "No available edit ID was selected!"))
(define (iter music)
(let ((elt (ly:music-property music 'element))
(elts (ly:music-property music 'elements))
(edit-ids (ly:music-property music 'edit-ids)))
(if (null? edit-ids)
(begin
(if (not (null? elt)) (iter elt))
(map iter elts))
(handle-hub music
(iter music)
music)
%{
Color specific edits some way
%}
colorEdits =
#(define-music-function (edit-colors grobs music) (list? list? ly:music?)
(define (color-tweaks grobs color)
(if (null? grobs) '()
(cons (cons (cons (car grobs) 'color) color) (color-tweaks (cdr grobs) color
(define (iter music current-color)
(let* ((elt (ly:music-property music 'element))
(elts (ly:music-property music 'elements))
(edit-id (ly:music-property music 'edit-id))
(this-color (assoc-get edit-id edit-colors current-color))
(tweaks (ly:music-property music 'tweaks)))
(if (not (null? this-color))
(ly:music-set-property! music 'tweaks (append tweaks (color-tweaks grobs this-color
(if (not (null? elt)) (iter elt this-color))
(map (lambda (x) (iter x this-color)) elts)))
(iter music '())
music)
%{
Add footnotes to edits
%}
annotateEdits =
#(define-music-function (edit-details music) (list? ly:music?)
(define (iter music carry-edit)
(let* ((elt (ly:music-property music 'element))
(elts (ly:music-property music
Re: Extracting a "score diff" from two [or more] Lilypond sources
Le 23/01/2022 à 00:14, Jean Abou Samra a écrit :
Le 22/01/2022 à 22:51, Kieren MacMillan a écrit :
Hi all!
Given multiple Lilypond sources, I'm hoping to find a way to output a
"diff file" describing the musical differences *as would be perceived
by a human reading the score*. For example, given
Score #1 = \score { \new Staff << { c'1 c' } >> }
Score # 2 = \score { \new Staff \new Voice << { c'1*1/2 s2 c''1
} >> }
diff ( Score1 , Score2 ) would say [in effect] "m2: Score #1 has c'1
while Score #2 has c''1."
Because coding style, "hacks" (like c'1*1/2 s2), variable/context
separation, and other code-based differences aren't [directly]
relevant, I can't just use standard text/diff tools. Is there a way
two "music streams" (oof, I'm definitely talking out my butt right
now!) can be compared in Lilypond and some/most/all of the
human-perceivable musical differences be automatically detected?
Thanks for any brainstorms, ideas, or (dare I dream!?) snippets!
Kieren.
You could actually output the music stream using
\include "event-listener.ly", and do a textual diff.
I guess that provides a start?
I remember now that the \displayLilyMusic machinery can output a
much more readable representation. You could try
\version "2.22.1"
\layout {
\context {
\Voice
\consists
#(lambda (context)
(let ((id (ly:context-id context))
(timing (ly:context-find context 'Score)))
(make-engraver
(listeners
((music-event engraver ev)
(ly:message "~a\tmes ~a\tmom ~a\t~a"
id
(ly:context-property timing 'internalBarNumber)
(ly:moment-main
(ly:context-property timing 'measurePosition))
((@@ (lily) music->lily-string)
(ly:event-property ev 'music-cause
}
}
<<
\new Voice = "voice1" \relative {
c'8 d e f g16 f e d c8 f16 d
R1
\breathe
}
\new Voice = "voice2" \relative {
4. r8 4
}
>>
Minimal, but perhaps already usable?
That being said, if you use version control in all
its capability, you just have to commit frequently
(Git terminology, but it would work with any system)
and particularly before and after doing any change
that you want to remember. That might turn out to
be the easiest option in the end.
Best,
Jean
Re: Extracting a "score diff" from two [or more] Lilypond sources
Just thinking out loud -- could a diff in the midi events be helpful? The midi events represent sounds, which is the most important output the musicians need to know about, and they are virtually unaffected by tweaks, etc. Ccarl From: lilypond-user on behalf of Kieren MacMillan Sent: Saturday, January 22, 2022 3:34 PM To: David Kastrup Cc: Lilypond-User Mailing List Subject: Re: Extracting a "score diff" from two [or more] Lilypond sources Hi David, > What version control system are you using for your score? It will > probably easiest to look at the source code diffs and do a manual > summary from those. The problem is that during various stages of composition / arranging / engraving / coding: 1. there can be huge differences in code that represent only a few small differences in notated output; 2. there can be very small differences in code that represent many/large differences in notated output; and 3. there can be many, many small changes in code (cleanup, variable-izing, moving tweaks to/from the edition-engraver, file splitting, etc.) that literally have *no* effect on the notated output. Especially in the third case, combing through all those changes to manually summarize changes worth noting to others would be time-consuming and error-prone. If my process were more luxurious, I'd do a "'notable changes' only" pass, manually summarize the diff(s), and then do the other code work in a separate pass — the issue is that the timeline of a workshop doesn't grant me that luxury, so I was hoping there was an automagic way of figuring out exactly and only those things that needed to be communicated to the MD/performers in any given score update. Thanks, Kieren.
Re: Extracting a "score diff" from two [or more] Lilypond sources
Le 22/01/2022 à 22:51, Kieren MacMillan a écrit :
Hi all!
Given multiple Lilypond sources, I'm hoping to find a way to output a "diff
file" describing the musical differences *as would be perceived by a human reading
the score*. For example, given
Score #1 = \score { \new Staff << { c'1 c' } >> }
Score # 2 = \score { \new Staff \new Voice << { c'1*1/2 s2 c''1 } >> }
diff ( Score1 , Score2 ) would say [in effect] "m2: Score #1 has c'1 while Score #2
has c''1."
Because coding style, "hacks" (like c'1*1/2 s2), variable/context separation, and other
code-based differences aren't [directly] relevant, I can't just use standard text/diff tools. Is
there a way two "music streams" (oof, I'm definitely talking out my butt right now!) can
be compared in Lilypond and some/most/all of the human-perceivable musical differences be
automatically detected?
Thanks for any brainstorms, ideas, or (dare I dream!?) snippets!
Kieren.
You could actually output the music stream using
\include "event-listener.ly", and do a textual diff.
I guess that provides a start?
Best,
Jean
Re: Extracting a "score diff" from two [or more] Lilypond sources
Hi David, > What version control system are you using for your score? It will > probably easiest to look at the source code diffs and do a manual > summary from those. The problem is that during various stages of composition / arranging / engraving / coding: 1. there can be huge differences in code that represent only a few small differences in notated output; 2. there can be very small differences in code that represent many/large differences in notated output; and 3. there can be many, many small changes in code (cleanup, variable-izing, moving tweaks to/from the edition-engraver, file splitting, etc.) that literally have *no* effect on the notated output. Especially in the third case, combing through all those changes to manually summarize changes worth noting to others would be time-consuming and error-prone. If my process were more luxurious, I'd do a "'notable changes' only" pass, manually summarize the diff(s), and then do the other code work in a separate pass — the issue is that the timeline of a workshop doesn't grant me that luxury, so I was hoping there was an automagic way of figuring out exactly and only those things that needed to be communicated to the MD/performers in any given score update. Thanks, Kieren.
Re: Extracting a "score diff" from two [or more] Lilypond sources
Kieren MacMillan writes: > p.s. Motivating use case: > > I'm cranking out scores for my newest musical > (https://www.ccpacanada.com/the-quest/). Rehearsals started on > Tuesday, and changes always come fast and furious during the > workshopping of a brand new piece. Every time I send the Musical > Director an updated score, I would love to not have to list all the > changes (I'm not yet rich or famous enough to have a music assistant > to do that kind of grunt work!), so I'd love to just pass two scores > through a "Music AI" and include that output with the new score. What version control system are you using for your score? It will probably easiest to look at the source code diffs and do a manual summary from those. -- David Kastrup
Re: Extracting a "score diff" from two [or more] Lilypond sources
p.s. Motivating use case:
I'm cranking out scores for my newest musical
(https://www.ccpacanada.com/the-quest/). Rehearsals started on Tuesday, and
changes always come fast and furious during the workshopping of a brand new
piece. Every time I send the Musical Director an updated score, I would love to
not have to list all the changes (I'm not yet rich or famous enough to have a
music assistant to do that kind of grunt work!), so I'd love to just pass two
scores through a "Music AI" and include that output with the new score.
— Kieren
> On Jan 22, 2022, at 4:51 PM, Kieren MacMillan
> wrote:
>
> Hi all!
>
> Given multiple Lilypond sources, I'm hoping to find a way to output a "diff
> file" describing the musical differences *as would be perceived by a human
> reading the score*. For example, given
>
>Score #1 = \score { \new Staff << { c'1 c' } >> }
>
>Score # 2 = \score { \new Staff \new Voice << { c'1*1/2 s2 c''1 } >> }
>
> diff ( Score1 , Score2 ) would say [in effect] "m2: Score #1 has c'1 while
> Score #2 has c''1."
>
> Because coding style, "hacks" (like c'1*1/2 s2), variable/context separation,
> and other code-based differences aren't [directly] relevant, I can't just use
> standard text/diff tools. Is there a way two "music streams" (oof, I'm
> definitely talking out my butt right now!) can be compared in Lilypond and
> some/most/all of the human-perceivable musical differences be automatically
> detected?
>
> Thanks for any brainstorms, ideas, or (dare I dream!?) snippets!
> Kieren.
