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.
Extracting a "score diff" from two [or more] Lilypond sources
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.
Re: confused about segno sign, Fine and D.S. al Fine and generating correct midi output
Hi Valentin; Although there might be better ways to achieve this I appreciate your code snippet. Ken On Sat, Jan 22, 2022 at 1:28 PM Valentin Petzel wrote: > > Fugue! That comes from being shortsighted and not checking names twice. I > apologize! > > As I see it putting something like this into the official release would be a > bit problematic, as the whole thing is might cause very weird behaviour. > > There are probably cleaner ways to achieve this result. > > Cheers, > Valentin > > 22.01.2022 19:27:12 Kenneth Wolcott : > > > Hi Valentin; > > > > I feel too honored to be mistaken for Kieren :-) > > > > Thank you so much for the "Jump" code; it is very interesting. > > > > The details are ***WAY*** beyond my understanding, but it looks very > > useful and usable. > > > > I will experiment with it. > > > > Is there a possibility that the next release of Lilypond would have > > such functionality built-in? > > > > Thanks, > > Ken > > > > On Sat, Jan 22, 2022 at 5:27 AM Valentin Petzel wrote: > >> > >> Hello Kieren, that seems to be correct. > >> > >> One could also try something like this. > >> > >> Cheers, > >> Valentin > >> > >> Am Samstag, 22. Jänner 2022, 03:22:42 CET schrieb Kenneth Wolcott: > >>> Hi; > >>> > >>> I have a piece of music from which I am engraving that confuses me. > >>> > >>> At bar #13 there is the Segno sign. > >>> > >>> At the end of bar #20 there is a "Fine". > >>> > >>> At the end of the piece (bar #37) there is a "D.S. al Fine". > >>> > >>> I'd like to have Lilypond generate midi output that would match this > >>> intent. > >>> > >>> Does this mean: > >>> Play all the way through; then start at the Segno and continue until the > >>> Fine? > >>> > >>> I think that's what it means. > >>> > >>> So I need to have bar #1 to bar #12 in one macro; > >>> bar #13 through bar #20 in a second macro; > >>> and the third macro would contain bars 21-33. > >>> > >>> Then I need "M_one", "M_two", "M_three", followed by "M_two" to > >>> implement this in the midi score section. > >>> > >>> Is that correct? > >>> > >>> Thanks, > >>> Ken Wolcott
Re: confused about segno sign, Fine and D.S. al Fine and generating correct midi output
Fugue! That comes from being shortsighted and not checking names twice. I apologize! As I see it putting something like this into the official release would be a bit problematic, as the whole thing is might cause very weird behaviour. There are probably cleaner ways to achieve this result. Cheers, Valentin 22.01.2022 19:27:12 Kenneth Wolcott : > Hi Valentin; > > I feel too honored to be mistaken for Kieren :-) > > Thank you so much for the "Jump" code; it is very interesting. > > The details are ***WAY*** beyond my understanding, but it looks very > useful and usable. > > I will experiment with it. > > Is there a possibility that the next release of Lilypond would have > such functionality built-in? > > Thanks, > Ken > > On Sat, Jan 22, 2022 at 5:27 AM Valentin Petzel wrote: >> >> Hello Kieren, that seems to be correct. >> >> One could also try something like this. >> >> Cheers, >> Valentin >> >> Am Samstag, 22. Jänner 2022, 03:22:42 CET schrieb Kenneth Wolcott: >>> Hi; >>> >>> I have a piece of music from which I am engraving that confuses me. >>> >>> At bar #13 there is the Segno sign. >>> >>> At the end of bar #20 there is a "Fine". >>> >>> At the end of the piece (bar #37) there is a "D.S. al Fine". >>> >>> I'd like to have Lilypond generate midi output that would match this >>> intent. >>> >>> Does this mean: >>> Play all the way through; then start at the Segno and continue until the >>> Fine? >>> >>> I think that's what it means. >>> >>> So I need to have bar #1 to bar #12 in one macro; >>> bar #13 through bar #20 in a second macro; >>> and the third macro would contain bars 21-33. >>> >>> Then I need "M_one", "M_two", "M_three", followed by "M_two" to >>> implement this in the midi score section. >>> >>> Is that correct? >>> >>> Thanks, >>> Ken Wolcott
Re: learning (names of) markup commands in scheme: documentation
[Berhard]
Actually, the lilypond.org web server was very insistent that even
when I googled English, I should read German whenever it was
available; therefore I assumed the versions were on par. I will think
about configuring one browser / profile without language preferences
so that I can access the English version directly.
(For documentation with a specialised audience, I always wonder if
such divergence between versions would be better avoided with
linguistic monoculture, but I really appreciate the effort! [And I
hope this does not sound deprecating – it's not meant to be!, it's
just a difficult issue.]).
Divergence depends on the state of maintenance of the
respective translation. The Italian and French ones are
completely up-to-date. I started using LilyPond aged
13 or so and barely able to make sense of the English
words like \header in the LilyPond input, let alone to
read the documentation in English. I don't think our
audience, however specialized, is so much more able
to speak English than with other software. The translations
do bring enormous value.
What would be ideal would be translating the documentation
via Gettext-based tools so the maintenance would be
automatic and English text would be displayed in case
the translation is outdated on a certain paragraph.
I dream of that, but the thing is, tools to do that only
emerged after the main body of translation was done,
and there would be an enormous lot of material to
convert by now ...
Le 22/01/2022 à 10:47, Bernhard Fisseni a écrit :
Good morning, Jean,
thank you very much for your detailed explanation! This helps me to
understands things a bit better.
Jean Abou Samra schrieb am 21.01.22 um 19:30:
Le 21/01/2022 à 08:57, Bernhard Fisseni a écrit :
- There is a point in processing when one has to convert every "line"
(in my example) to markup, although the interpretation happens
automatically in other places (see interpret-markup-list in
apply-last-strut).
I'm not sure what you mean here. Can you clarify?
What I meant was that while in the Lilypond source, one can have a top
\markup, which makes more or less all its argument a markup, when
writing the markup commands, one occasionally has to apply
(interpret-markup) or (interpret-markup-list) to inner arguments to
return the right type, e.g. in the recursive function I wrote. If I
understand correctly, one is doing piecewise evaluation "by hand".
It feels rather natural if one understands the general system, I
suppose, as there are these different explicit and implicit
conversions of syntax into markup. (If that is too cryptic, I am
sorry; it is probably not such an important point.)
Well, the "right type" here is not a markup, but a
stencil, namely a device-independent representation of
graphical output. A markup is not a stencil, but merely
the promise of a stencil that will be parameterized by
properties. So when you do interpret-markup, this is not
converting some kind of syntax into a markup, but a markup
into a stencil. When you write \markup in your source file,
you enter markup mode. You can then compose your markup
using commands. The application of a command as
\command [first-arg] [second-arg] [etc.] yields a markup.
Many markup commands take one or several markup arguments,
so when you write \markup \bold \italic a, this ends
up as a markup made from the command \bold, with an argument
that is \markup \italic a (no need to repeat \markup within
the nested construction as you are already in markup mode).
At this point, the compound \markup gets interpreted. That's
the entry point. Then, it is up to the markup command
of that top-level markup to interpret the markup sub-arguments.
Usually it will interpret them (it doesn't have to), but
it is intentional to leave it to the command to do it and
not to do it automatically. Because the command may want to
interpret its markup subarguments with different parameters.
A typical example: \bold is defined as
(define-markup-command (bold layout props arg)
(markup?)
(interpret-markup layout (prepend-alist-chain 'font-series 'bold
props) arg))
which interprets the markup argument with a modified
"props" alist chain (list of alists) that adds settings
so that any string inside "arg" gets interpreted in
a bold font.
Is it clearer to you now?
[David]
Yes, and not only make-CMD-markup, but more importantly
CMD-markup
CMD-markup-function
Hm?
#(write #{ \markup \bold a #})
=> (# "a")
[Me]
Homework for me: figure out why this does not result
in constant spacing regardless of the heights of
the markups (that part of the code is rather complicated).
Cough. It does. The default baseline-skip just turns
out to be about what you want. If you add more lines,
it starts colliding. How could that have worked? Silly me.
That suggestion is moot: at best it helps you reduce
the minimum distance (baseline-skip) without padding
interfering. You still need manual adjustments.
I
Re: confused about segno sign, Fine and D.S. al Fine and generating correct midi output
Hi Valentin; I feel too honored to be mistaken for Kieren :-) Thank you so much for the "Jump" code; it is very interesting. The details are ***WAY*** beyond my understanding, but it looks very useful and usable. I will experiment with it. Is there a possibility that the next release of Lilypond would have such functionality built-in? Thanks, Ken On Sat, Jan 22, 2022 at 5:27 AM Valentin Petzel wrote: > > Hello Kieren, that seems to be correct. > > One could also try something like this. > > Cheers, > Valentin > > Am Samstag, 22. Jänner 2022, 03:22:42 CET schrieb Kenneth Wolcott: > > Hi; > > > > I have a piece of music from which I am engraving that confuses me. > > > > At bar #13 there is the Segno sign. > > > > At the end of bar #20 there is a "Fine". > > > > At the end of the piece (bar #37) there is a "D.S. al Fine". > > > > I'd like to have Lilypond generate midi output that would match this > > intent. > > > > Does this mean: > > Play all the way through; then start at the Segno and continue until the > > Fine? > > > > I think that's what it means. > > > > So I need to have bar #1 to bar #12 in one macro; > > bar #13 through bar #20 in a second macro; > > and the third macro would contain bars 21-33. > > > > Then I need "M_one", "M_two", "M_three", followed by "M_two" to > > implement this in the midi score section. > > > > Is that correct? > > > > Thanks, > > Ken Wolcott
Re: confused about segno sign, Fine and D.S. al Fine and generating correct midi output
Le 22/01/2022 à 14:27, Valentin Petzel a écrit : Hello Kieren, I think you meant someone else :-) that seems to be correct. One could also try something like this. It deserves to be mentioned that \repeat segno has been implemented by Dan Eble in the development branch. It will be included in the next release. \unfoldRepeats then works just the way one would expect it to. Best, Jean
Re: confused about segno sign, Fine and D.S. al Fine and generating correct midi output
Hello Kieren, that seems to be correct. One could also try something like this. Cheers, Valentin Am Samstag, 22. Jänner 2022, 03:22:42 CET schrieb Kenneth Wolcott: > Hi; > > I have a piece of music from which I am engraving that confuses me. > > At bar #13 there is the Segno sign. > > At the end of bar #20 there is a "Fine". > > At the end of the piece (bar #37) there is a "D.S. al Fine". > > I'd like to have Lilypond generate midi output that would match this > intent. > > Does this mean: > Play all the way through; then start at the Segno and continue until the > Fine? > > I think that's what it means. > > So I need to have bar #1 to bar #12 in one macro; > bar #13 through bar #20 in a second macro; > and the third macro would contain bars 21-33. > > Then I need "M_one", "M_two", "M_three", followed by "M_two" to > implement this in the midi score section. > > Is that correct? > > Thanks, > Ken WolcottunfoldJumpMarks = #(define-music-function (music) (ly:music?) (let ((jump-points '()) (jump-marks '()) (chained-jumps '()) (current-fine #f) (result-music '())) (define (search-music music) (let ((this-jump-points (ly:music-property music 'jump-points)) (jump-details (ly:music-property music 'jump-details))) (for-each (lambda (x) (set! jump-points `((,x . ,music) . ,jump-points))) this-jump-points) (if (not (null? jump-details)) (set! jump-marks `((,music . ,jump-details)) (define (listify-music music-list) (if (null? music-list) '() (begin (ly:music-set-property! (car music-list) 'LIST-next (listify-music (cdr music-list))) (car music-list (define (walk-search-music music) (let ((elts (ly:music-property music 'elements))) (listify-music elts) (map search-music elts) (if (not (assoc-get 'BEGIN-OF-PIECE jump-points #f)) (set! jump-points `((BEGIN-OF-PIECE . ,(car elts)) . ,jump-points) (define (build-music) (let ((current-pos (assoc-get 'BEGIN-OF-PIECE jump-points))) (while #t (set! result-music (cons current-pos result-music)) (let* ((mem-pos current-pos) (next-el (ly:music-property current-pos 'LIST-next)) (this-j-point (any (lambda (x) (if (or (eq? current-pos (assoc-get (car x) jump-points)) (and ;; treat end of music as begin-jump-mark END-OF-PIECE (equal? (car x) 'END-OF-PIECE) (null? next-el))) x #f)) chained-jumps)) (this-jump-instruction (assq-ref jump-marks current-pos)) (this-jump-instruction (if this-jump-instruction this-jump-instruction '( (if this-j-point ;; reached a triggered jump (begin (set! current-pos (assoc-get (cdr this-j-point) jump-points)) (set! chained-jumps (delete this-j-point chained-jumps))) (if (or (null? this-jump-instruction) (not (car this-jump-instruction))) ;; no active jump-mark was found (if (or (null? next-el) (eq? current-pos (assoc-get current-fine jump-points))) ;; no jump and no more music or at fine (break) (set! current-pos next-el)) ;; set to next element (let* ((now-jump (car this-jump-instruction)) ;; found am active jump mark, perform jump (first-jump (first now-jump)) (following-jumps (second now-jump)) (this-fine (if (> (length now-jump) 2) (third now-jump) #f))) (set! current-pos (assoc-get first-jump jump-points)) (set! chained-jumps (append following-jumps chained-jumps)) (if this-fine (set! current-fine this-fine) (if (not (null? this-jump-instruction)) (set! jump-marks (assq-set! jump-marks mem-pos (cdr this-jump-instruction (walk-search-music music) (build-music) (ly:music-set-property! music 'elements (reverse result-music)) music)) jumpPoint = #(define-music-function (mark music) (symbol? ly:music?) (ly:music-set-property! music 'jump-points (cons mark (ly:music-property music 'jump-points))) music) jumpMark =
Re: learning (names of) markup commands in scheme: documentation
Good morning, Jean, thank you very much for your detailed explanation! This helps me to understands things a bit better. Jean Abou Samra schrieb am 21.01.22 um 19:30: Le 21/01/2022 à 08:57, Bernhard Fisseni a écrit : - There is a point in processing when one has to convert every "line" (in my example) to markup, although the interpretation happens automatically in other places (see interpret-markup-list in apply-last-strut). I'm not sure what you mean here. Can you clarify? What I meant was that while in the Lilypond source, one can have a top \markup, which makes more or less all its argument a markup, when writing the markup commands, one occasionally has to apply (interpret-markup) or (interpret-markup-list) to inner arguments to return the right type, e.g. in the recursive function I wrote. If I understand correctly, one is doing piecewise evaluation "by hand". It feels rather natural if one understands the general system, I suppose, as there are these different explicit and implicit conversions of syntax into markup. (If that is too cryptic, I am sorry; it is probably not such an important point.) I would agree that the explanations regarding markups vs. markup lists, markup vs. stencils, markup in scheme etc. in the Documentation might be improved. For what it's worth, a step has been made just a few weeks ago with https://gitlab.com/lilypond/lilypond/-/merge_requests/1089 That merge request revised the Notation Reference material about markups (though not the Extending Manual material) so that the interplay between markups and markup lists would be clearer. Part of my motivation for doing this is that it took myself ages even as a developer to discover the way applying a markup command taking a markup as last argument to a markup list as last arguments "maps" it as in your examples. Thank you, very much, I will have a look at it! Regarding the problem at hand, I believe it can be solved by defining a slightly tweaked version of \column that allows turning off the behavior that avoids overlap between lines: [...] Thank you, that is also an interesting approach, and feels as if the problem is resolved is "at a better place" in the command. Again, thank you for your patience, best regards, Bernhard
Re: learning (names of) markup commands in scheme: documentation
Hi Lukas, Lukas-Fabian Moser schrieb am 21.01.22 um 17:15: Also note [...] The standard use case for make-XXX-markup is explained in: http://lilypond.org/doc/v2.23/Documentation/extending/markup-construction-in-scheme.html under "Known issues and warnings". I had read that, and it seemed easier to use the "full version", and more consistent, too. But I understand that the data version using #:keywords is a little more easy to read once you are used to it I would agree that the explanations regarding markups vs. markup lists, markup vs. stencils, markup in scheme etc. in the Documentation might be improved. We always welcome contributions! Thank you – I'll see if I understand enough to help ;-). (And, your probably noticed this: The German documentation is in an effectively unmaintained state at the moment. But it seems there's hope this might change soonish. Actually, the lilypond.org web server was very insistent that even when I googled English, I should read German whenever it was available; therefore I assumed the versions were on par. I will think about configuring one browser / profile without language preferences so that I can access the English version directly. (For documentation with a specialised audience, I always wonder if such divergence between versions would be better avoided with linguistic monoculture, but I really appreciate the effort! [And I hope this does not sound deprecating – it's not meant to be!, it's just a difficult issue.]). Thanks, best regards, Bernhard
