Re: can a Scheme engraver "solve" Issue #34 (grace note bug)? [cross-posted]

[Lukas-Fabian Moser]

Am 08.02.20 um 21:44 schrieb Han-Wen Nienhuys:

I think the right solution would be to kill grace timing altogether, and
initiate some sort special "embedded" engraving pass that creates the Grace
grobs all at once.

That would have another downside: if we construct the grace note grobs in a
special pass, there is nothing to synchronize them across staves. You could
have two-handed piano music where the left and right hand do grace notes in
a synchronized way. I don't if that exists in practice, but it is one of
the reasons for the current approach.


I would expect that synchronized grace notes do exist. But more often 
than not, at least one solitary grace note is meant to happen "some 
infinitesimal amount of time before the main note", without a need to 
keep track of (so-to-say) different lengths of infinitesimal moments 
across voices/staves.


Hence, in combination with accidentals, the current approach leads to 
ugly things like


\version "2.19.82"

<<
  \new Staff { \grace a'8 gis'2 }
  \new Staff { \grace dis'8 e'2 }
>>

(which I encountered quite a lot when engraving, for instance, examples 
from Mozart chamber music).


My standard workaround is to allow LilyPond to use two different points 
in grace time:


\version "2.19.82"

<<
  \new Staff { \grace a'8 gis'2 }
  \new Staff { \grace dis'8*1/2 e'2 }
>>

But that's also not ideal, firstly from a semantic point of view, 
secondly because the visual outcome depends on the chosen factor, while 
I basically want Lily to put the grace not "as close as 
possible/graphically sensible" to the main note.


Best
Lukas

German translation

[Lukas-Fabian Moser]

Folks,

[tl;dr: Whom should I contact for improvement suggestions for the German 
PO file?]


The German PO file contains some translations that seem to suffer from 
the "false friend"-syndrome, for instance


#: convertrules.py:549
msgid "point-and-click argument changed to procedure."
msgstr "point-and-click-Argument zu Ablauf verändert"

("Ablauf" being a literal translation of 'procedure' that is wrong in a 
software context) and the famous


#: lexer.ll:947
#, c-format
msgid "unknown escaped string: `\\%s'"
msgstr "Ungültige Fluchtsequenz: »\\%s«"

that you see quite often when using Lilypond on a German system - I 
think no-one knows what a "Fluchtsequenz" is supposed to be - maybe a 
sequence of successful prison escapes? (The usual German word would be, 
perhaps surprisingly, "Escape-Sequenz", but I think as a user-level 
error message, something like "Unbekanntes Kommando" might even be more 
helpful.)


What's the right place to send such suggestions to? If there's going to 
be a new stable release soon, maybe it would be nice to get some of the 
more amusing translation gaffes fixed in time.


Best
Lukas

Re: Staging broken.

[Lukas-Fabian Moser]

The build log talks about

autogen.sh --noconfigure

can you confirm that with "   ./autogen.sh && make -j4" it also fails?


Fwiw, I had the same compile error as David yesterday. (It had been 
quite a while since I last pulled & compiled, so I was not very much 
surprised when make didn't succeed - I was halfway into trying to bisect 
to find out just when in the last few months it stopped working on my 
system when David's staging-broken alert arrived.)


My system is a down-to-earth Mint 19.3.

Lukas

Re: Staging broken.

[Lukas-Fabian Moser]

Le mer. 19 févr. 2020 à 09:08, David Kastrup  a écrit :

Color me curious: why would you try building staging?  The whole point
> of the staging system was to avoid breakage for developers.  Only patchy
> processes are supposed to care about staging.
>

Master didn't compile, and I tried staging next. But I see now that this
doesn't make much sense as staging is more likely to break.

I don't remember what exactly kept Master from compiling yesterday - when I
tried later it worked. But anyway, my stupid procedure enabled me to
confirm that Staging broke with the same error that you encountered.

By the way: does it make sense to compile and use the stable/2.20 branch
for my everyday work (beta testing, so to speak)?

Lukas

>

Re: Accidentals' font

[Lukas-Fabian Moser]

Hi Han-Wen,


6) Look at the glyph of forcing: it forms a single word, and not the union
of three different characters (which is very distracting, in my opinion)

what is 'forcing' ?
I assumed it meant sfz, coming from an Italian native speaker - Paolo, 
please correct me if I'm wrong.

7) Look at the trill glyph: it's simpler, cleaner and less "baroque",

Maybe Jan can comment. The comment says it's based on a Saint Saens
Cello concerto, which I can't recall ever having seen.


Seems plausible: Everybody (tm) plays the 1st concerto, and at least 
15-20 years ago, everybody (tm) used the Durand edition. There you find:


Not really identical to LilyPond's current

but certainly related.

Lukas

Re: GSoC 2020 update, July 18

[Lukas-Fabian Moser]

Hi Pál,


in ancient (ars subtilior) notation there actually are noteheads with
two stems (which may also be flagged differently), called "dragma".
a picture search for "dragma ars subtilior" returned poor images; one
not entirely useless is
https://www.last.fm/music/Philippus+de+Caserta/+images/f82a66af9573ba3cf431b0b1986f07e8
(staff three, the black block between two red block in the first half
of the staff); or see the youtube video
https://www.youtube.com/watch?v=wd3ouxA9p-o


See also the examples given in Apel, the first of which being

https://archive.org/details/notationofpolyph1953apel/page/392/mode/2up

Best
Lukas

2.21.7: dead download links

[Lukas-Fabian Moser]

Folks,

I'm sorry if this is already being discussed and I just missed it: Right 
now, http://lilypond.org/development.html lists 2.21.7 as the current 
version, but the download links are dead (e.g. 
https://lilypond.org/download/binaries/linux-64/lilypond-2.21.7-1.linux-64.sh).


Lukas

Re: 2.21.7: dead download links

[Lukas-Fabian Moser]

Folks,

I'm sorry if this is already being discussed and I just missed it: Right
now, http://lilypond.org/development.html lists 2.21.7 as the current
version, but the download links are dead (e.g.
https://lilypond.org/download/binaries/linux-64/lilypond-2.21.7-1.linux-64.sh).

Yes, there was a problem with VERSION_DEVEL that Phil fixed earlier
today, the right version would have been 2.21.6. I've triggered a
rebuild of the website, should on lilypond.org later this evening.


Thanks much, everything seems to be fine now again!

Lukas

Re: tie over clef change

[Lukas-Fabian Moser]

I seem to remember that even in Bach's B minor mass (where E12 was not
yet a thing) there is an enharmonic tie (or at least tonal repetition?)
in the transition from "Confiteor" to "Et expecto".  I mean, that
transition is a tonal center nightmare anyway.


In bar 138:

Basically that is an example of enharmonic equivalence of diminished 7th 
chords: The tonal centre in the preceding bars is clearly d (d major 
with hints of d minor), so the diminished chord in bar 138 is most 
probably first heard as f♯-a-c-e♭ (with expected resolution to g minor), 
but is then being re-interpreted (and written) as f♯-a-b♯-d♯, resolving 
to c♯ major functioning as a dominant to f♯ minor.


My point is: Even without E12 tuning, this is clearly an example of 
fully exploited enharmonic equivalence used as a "wormhole" in an 
otherwise purely diatonic tonal system. There can be no question that 
this is semantically a tie.


(One might raise the objection that, maybe, when performing the piece, a 
slight adjustment in intonation might be needed in the transition from c 
to b♯. But this can also happen for bona fide ties in purely diatonic 
music, so that does not yield an argument against the tie being a tie.)


Lukas

Re: tie over clef change

[Lukas-Fabian Moser]

However, this gets *never* notated as such.

I gave the example of augment sixth chords, that seem to never be notated as 
diminished sevenths.
https://en.wikipedia.org/wiki/Augmented_sixth_chord


I assume you meant "dominant sevenths"? (Augmented sixth chords, at 
least "Italian" and "German" augmented sixths, are identical to dominant 
sevenths without or with fifth on a modern keyboard, e.g. c-e-[g]-a♯ vs. 
c-e-[g]-b♭, but none of them yield diminished sevenths.)


But anyway, I'm not sure that your statement holds true invariably: I'm 
pretty sure that in late 19th century composers like Bruckner, the 
difference between both chords becomes blurry. I will see if I can find 
an example, maybe even older than Bruckner.


On a related but different note, I always found it funny how certain 
editors of Mozart's Requiem, of all things, tried to "improve" Mozart's 
chromatic/enharmonic spelling. See the old Peters vocal scores on IMSLP 
at the end of the "Confutatis maledictis"


vs. the original Mozart spelling (which Süßmayr preserved faithfully):

I would not claim that this change generates any measurable difference 
in what the musicians actually play and sing, but I imagine it changes 
the way they _think_ their lines. In particular, I like Mozart's 
notation for the clarity with which he expresses that he uses the 
diminished seventh as a triple-leading tone neighbour to the ensuing 
dominant seventh - not to mention the fact that this exact device is all 
over the place in the second half of the Confutatis, and it's frankly 
silly to change it just once, only to avoid a double flat...


Lukas

Re: tie over clef change

[Lukas-Fabian Moser]

The tonal center collapse is done purely vocally in an a cappella
passage and when the instruments come back in, it's in a resurrection
key and instrument groups (like brass) that are typical for it.

[...]

Here is a link  to a
Herreweghe version.  The piano extract displayed in parallel would
suggest that there is, after all, an instrumental part even in the 2:30
and finally 3:00 (or so) locations which is a bit surprising to me since
I remember how we fought keeping the intonation in line so that the
resurrection trumpets could fall right in.  I cannot hear instruments
there right now but I have only builtin speakers at low volume right now
so I may be wrong about that.


It's a cappella plus (un-figured) Continuo essentially doubling the 
choir bass:


The presence of the Continuo should mean "let the continuo band play 
along"; while there is no explicit indication as to which instrument(s) 
should be used (at least in the Bärenreiter score), the repeated 
crochets-with-slurs clearly indicate that Bach expects a bowed instrument.


In Herreweghe's rendering, I hear cello (original continuo line) plus 
organ (playing the complete chords).


Lukas

Re: incomplete tuplets in non-standard time signatures

[Lukas-Fabian Moser]

Hi Harm,


I just filed a bug report
http://lilypond.1069038.n5.nabble.com/Wrongly-read-property-with-MetronomeMark-td237659.html

2c2908c905ba822ef656b06b1cc4f0ca33960c9c is the first bad commit
commit 2c2908c905ba822ef656b06b1cc4f0ca33960c9c
Author: Malte Meyn 
Date:   Sun Sep 29 10:10:35 2019 +0200

    Issue 5563: make edges of brackets dashable

    The new boolean grob property dashed-edge controls whether the edges of
    a dashed bracket are solid or dashed.

Lukas

Re: incomplete tuplets in non-standard time signatures

[Lukas-Fabian Moser]

Hi Michael,


I just filed a bug report
http://lilypond.1069038.n5.nabble.com/Wrongly-read-property-with-MetronomeMark-td237659.html 




2c2908c905ba822ef656b06b1cc4f0ca33960c9c is the first bad commit
commit 2c2908c905ba822ef656b06b1cc4f0ca33960c9c
Author: Malte Meyn 
Date:   Sun Sep 29 10:10:35 2019 +0200

That does not make sense to me. 2.20.0 was released on March 1, 2020 and
Harm reported that 2.20.0 is fine. I think bisecting must start with 
2.20.0., then.


It's well possible that I got this all wrong, but I was under the 
impression that, as not all changes added during the 2.19.xx cycle were 
cherry-picked into 2.20, it's quite possible for a commit that was added 
to master before the release of 2.20.0 to only end up in 2.21.xx.


Also, Malte's commit contains the following change in lily/bracket.cc:

index bc7ad67680..63ab1fcafa 100644
@@ -77,8 +77,9 @@ Bracket::make_bracket (Grob *me, // for line properties.
 m.add_stencil (Line_interface::line (me, straight_corners[LEFT],
straight_corners[RIGHT]));

-  if (scm_is_number (me->get_property ("dash-fraction")))
-    me->set_property ("dash-fraction", scm_from_double (1.0));
+  if (scm_is_eq (me->get_property ("style"), ly_symbol2scm ("dashed-line"))
+  && !to_boolean (me->get_property ("dashed-edge")))
+    me->set_property ("style", ly_symbol2scm ("line"));
   for (LEFT_and_RIGHT (d))
 m.add_stencil (Line_interface::line (me, straight_corners[d],
flare_corners[d]));

I haven't even tried to understand the scope and logic of Malte's 
changes, but to me it seems very plausible that this change could lead 
to a behaviour as discovered by Harm.


(And actually, my bisect started as follows:

git bisect start
# good: [b39b2e652fc4bcf282bb8b826e81070a77bc93db] Release: bump Welcome 
versions.

git bisect good b39b2e652fc4bcf282bb8b826e81070a77bc93db
# bad: [65932b8fde202a95b7fbf9f400c01c75fa53519f] Add version to 
Japanese snippet

git bisect bad 65932b8fde202a95b7fbf9f400c01c75fa53519f

b39b2e is release/2.20.0-1, 65932b8 is release/2.21.0-1.)

Lukas

Re: How to shift trill to below phrasing slur?

[Lukas-Fabian Moser]

Hi Harm,


avoid-slur is the correct method:

%#(ly:set-option 'debug-skylines #t)

\score {
   {
 \time 12/8
 \relative c' {
   a8 b\( c a b c d e f d e f
   g a b g a b c2.
   \once \override Script.avoid-slur = #'inside
   d2.\trill \grace { c16 d }
   e2.\)
 }
   }
}

Though, for unrelated reasons I had enabled 'debug-skylines and
noticed the last part of the PhrasingSlur is not recognized from
skylines. See attached image (done with current master).
A bug?

Thus, cc-ing -devel.


That happened with:

6d76be6462d3595851b0fe3c13ba238b5cdbbddf is the first bad commit
commit 6d76be6462d3595851b0fe3c13ba238b5cdbbddf
Author: Han-Wen Nienhuys 
Date:   Fri May 1 09:09:24 2020 +0200

    Build slur skyline out of segments rather than boxes.

    This provides more precise skylines. The regtest shows 11 images that
    changed, with tighter formatting for files involving slurs.

    https://sourceforge.net/p/testlilyissues/issues/5936
    http://codereview.appspot.com/577820043

Lukas

Re: Proposal: Automatically adjusting indents for instrument names

[Lukas-Fabian Moser]

Hi Johannes,

I 'd like to propose the enhancement below to LilyPond. It will 
increase the indent and short-indent of a score to fit all of its 
instrument names and instrument short names.


This is a great idea (and a feature I've been missing for quite some time).

In the current version, subsequent systems get a positive short-indent 
even if there is no shortInstrumentName given. Is that on purpose? I 
would have expected a minimal


\version "2.22.0"

\new Staff { \repeat unfold 64 c'4 }

to yield the same result before and after your patch.

Lukas

Re: [PoC] EXPERIMENTAL binaries of LilyPond 2.22.1

[Lukas-Fabian Moser]

Hi Jonas,

Am 13.05.21 um 22:46 schrieb Jonas Hahnfeld via Discussions on LilyPond 
development:

Before starting: These builds are not official, highly experimental,
and not meant for "production" installations. They use Guile 2.2 and
are slower, might not compile all scores or break some advanced feature
that you might use. The binaries might eat your files or do other bad
things to your computer - you've been warned!


It works great out-of-the box on my machine (Mint 20.1) and (after one 
pass with GUILE_AUTO_COMPILE=1) seems to be as fast as before.


I'd love to use this on a daily basis (and report possible trouble), 
but: At the moment, it fails when invoked from Frescobaldi (3.2) for 
files containing Umlaute in their path. I'm not quite sure why, because 
the problem does not occur when I invoked Lilypond manually on the 
command line:


Command line:

lukas@Aquarium:~$ 
~/lilypond-versions/2.22.1-guile22/lilypond/bin/lilypond 
~/Dokumente/Gehörbildungsunterricht/Wagner\ Walküre\ 
Schlafmotiv/Schlafmotiv.ly GNU LilyPond 2.22.1 
»/home/lukas/Dokumente/Gehörbildungsunterricht/Wagner Walküre 
Schlafmotiv/Schlafmotiv.ly« wird verarbeitet Analysieren... 
Interpretation der Musik...[8] Vorverarbeitung der grafischen 
Elemente... Ideale Seitenanzahl wird gefunden... Musik wird auf eine 
Seite angepasst... Systeme erstellen... Konvertierung nach 
»Schlafmotiv.pdf«... Kompilation erfolgreich beendet


Frescobaldi log with \version "2.22.0":

Starte lilypond 2.22.0 [Schlafmotiv.ly]...

Processing `/home/lukas/Dokumente/Gehörbildungsunterricht/Wagner Walküre 
Schlafmotiv/Schlafmotiv.ly'


Parsing...

Interpreting music...[8]

Preprocessing graphical objects...

Finding the ideal number of pages...

Fitting music on 1 page...

Drawing systems...

Converting to `Schlafmotiv.pdf'...

Success: compilation successfully completed

Erfolgreich abgeschlossen in 0.7".

Frescobaldi log with \version "2.22.1":

Starte lilypond 2.22.1 [Schlafmotiv.ly]...

warning: cannot find file: 
`/home/lukas/Dokumente/Geh??rbildungsunterricht/Wagner Walk??re 
Schlafmotiv/Schlafmotiv.ly'


fatal error: failed files: 
"/home/lukas/Dokumente/Geh??rbildungsunterricht/Wagner Walk??re 
Schlafmotiv/Schlafmotiv.ly"


Wurde mit dem Return-Code 1 beendet.

Obviously some encoding/unicode problem, but I'm not sure if the culprit 
is LilyPond or Frescobaldi?


Lukas

Re: [PoC] EXPERIMENTAL binaries of LilyPond 2.22.1

[Lukas-Fabian Moser]

Hi Jonas,


Obviously some encoding/unicode problem, but I'm not sure if the
culprit is LilyPond or Frescobaldi?


Umm, so if it works from the command line but not from Frescobaldi, it
could be that the invocation from there doesn't pass the filename as
UTF-8 and Guile 1.8 works by chance due to magical conversions going on
somewhere? That would need to be fixed in Frescobaldi, I suppose...


Not as far as I can make out.

Frescobaldi passes a python3 string into QProcess.start() (so everything 
should be UTF-8).


If I let Frescobaldi use not a Lilypond binary but a shell script that 
dumps its command line parameters into a file, I get a UTF-8 encoded 
file with the "correct" file name. But if that script also does 
/.../lilypond "$@", then guile1.8-Lilypond succeeds while 
guile2.2-LilyPond fails.


Of course it's always possible that some implicit conversion is going on 
at some point in the chain, but I'm at a loss to pinpoint it.


Do you have any suggestion which route I could try to find out?

Lukas

Re: [PoC] EXPERIMENTAL binaries of LilyPond 2.22.1

[Lukas-Fabian Moser]

Hi Jonas,


Do you have any suggestion which route I could try to find out?

Not really, other than maybe writing a small C program that dumps the
arguments as binary in hex code?


I did:

#include "stdio.h" void dump_char(char c) { printf("%02hhX(%c)", c, c); 
} void dump_string(char *c) { printf("\"%s\":\n", c); while (*c) 
dump_char(*c++); printf("\n\n"); } int main(int argc, char **argv) { for 
(int i = 0; i < argc; i++) dump_string(argv[i]); return 0; }


If I use this instead of LilyPond in Frescobaldi, the output is:

Starte dumpargs 0.1 [Schlafmotiv.ly]...

"/home/lukas/Dokumente/dumpargs":

2F(/)68(h)6F(o)6D(m)65(e)2F(/)6C(l)75(u)6B(k)61(a)73(s)2F(/)44(D)6F(o)6B(k)75(u)6D(m)65(e)6E(n)74(t)65(e)2F(/)64(d)75(u)6D(m)70(p)61(a)72(r)67(g)73(s)

"-ddelete-intermediate-files":

2D(-)64(d)64(d)65(e)6C(l)65(e)74(t)65(e)2D(-)69(i)6E(n)74(t)65(e)72(r)6D(m)65(e)64(d)69(i)61(a)74(t)65(e)2D(-)66(f)69(i)6C(l)65(e)73(s)

"-dno-point-and-click":

2D(-)64(d)6E(n)6F(o)2D(-)70(p)6F(o)69(i)6E(n)74(t)2D(-)61(a)6E(n)64(d)2D(-)63(c)6C(l)69(i)63(c)6B(k)

"-I/home/lukas/oll-lib/":

2D(-)49(I)2F(/)68(h)6F(o)6D(m)65(e)2F(/)6C(l)75(u)6B(k)61(a)73(s)2F(/)6F(o)6C(l)6C(l)2D(-)6C(l)69(i)62(b)2F(/)

"--pdf":

2D(-)2D(-)70(p)64(d)66(f)

"/home/lukas/Dokumente/Gehörbildungsunterricht/Wagner Walküre 
Schlafmotiv/Schlafmotiv.ly":


2F(/)68(h)6F(o)6D(m)65(e)2F(/)6C(l)75(u)6B(k)61(a)73(s)2F(/)44(D)6F(o)6B(k)75(u)6D(m)65(e)6E(n)74(t)65(e)2F(/)47(G)65(e)68(h)C3(�)B6(�)72(r)62(b)69(i)6C(l)64(d)75(u)6E(n)67(g)73(s)75(u)6E(n)74(t)65(e)72(r)72(r)69(i)63(c)68(h)74(t)2F(/)57(W)61(a)67(g)6E(n)65(e)72(r)20( 
)57(W)61(a)6C(l)6B(k)C3(�)BC(�)72(r)65(e)20( 
)53(S)63(c)68(h)6C(l)61(a)66(f)6D(m)6F(o)74(t)69(i)76(v)2F(/)53(S)63(c)68(h)6C(l)61(a)66(f)6D(m)6F(o)74(t)69(i)76(v)2E(.)6C(l)79(y)


Erfolgreich abgeschlossen in 0.0".

Looks like Unicode alright, but frankly I'm surprised that plain gcc's 
char type and printf seem to be able to deal with multi-byte characters. 
But this probably has to do with the fact that this was my first 
#include "stdio.h" since (I think) 1998, and the world has moved on...



  However, I just tested on my system
with Frescobaldi 3.1.3 and it can compile both a file with special
characters in the filename as well as in a directory with special
characters. Are you sure that all of your filesystem is UTF-8 and that
Frescobaldi is started in an UTF-8 locale?


Not at all. It's just I never knowlingly tampered with encodings since I 
first installated the system (Mint), which displays German messages most 
of the time. I have to do some research before I can answer your questions.


(Just to be sure: Are you sure you let Frescobaldi compile the actual 
file and not Frescobaldi's temporary copy?)


Lukas

Re: [PoC] EXPERIMENTAL binaries of LilyPond 2.22.1

[Lukas-Fabian Moser]

but frankly I'm surprised that plain gcc's char type and printf seem
to be able to deal with multi-byte characters. But this probably has
to do with the fact that this was my first #include "stdio.h" since
(I think) 1998, and the world has moved on...

I don't think "char *" and printf care, they just pass on the binary
data as-is. The glyph rendering is what has to deal with the encoding
in the end...


Ah, sorry. My statement was an artifact of a preliminary version where I 
messed up hex-char output and got 8-digit hex numbers because the 
unicode bytes were being interpreted as signed numbers. Now I see what 
you mean (and am less surprised about "modern C magic").



(Just to be sure: Are you sure you let Frescobaldi compile the actual
file and not Frescobaldi's temporary copy?)

Quite: I created the files outside of Frescobaldi and only opened and
compiled them from there. As far as I understand, Frescobaldi compiles
a temporary copy if I have unsaved modifications? At least then I get a
path in/tmp/, but the filename still has the special characters...
Your're right. (I had thought Frescobaldi also garbles the filename, but 
I was wrong.)


I just remembered that I have another encoding problem with LilyPond, 
namely special characters in \bootOutputSuffix lead to replacement 
characters __ in the name of the generated file. Which means I should 
investigate the encoding used in my file system after all.


Thanks for your help!
Lukas

Re: [PoC] EXPERIMENTAL binaries of LilyPond 2.22.1

[Lukas-Fabian Moser]

Hi Jonas,

Am 14.05.21 um 21:59 schrieb Jonas Hahnfeld:

Am Freitag, dem 14.05.2021 um 20:35 +0200 schrieb Lukas-Fabian Moser:

I just remembered that I have another encoding problem with LilyPond,
namely special characters in \bootOutputSuffix lead to replacement
characters __ in the name of the generated file. Which means I should
investigate the encoding used in my file system after all.

Is that with all LilyPond versions, including the "old" Guile 1.8?
You may also try a shell script calling "locale" to see what
environment you actually get when compiling a score from Frescobaldi...


That was the crucial idea. Thanks!

Found it now: If you enable "Run LilyPond with English messages" in 
Frescobaldi ("LilyPond mit Englischen Meldungen starten") - which I had, 
although I don't remember why -, it does (cf. 
frescobaldi_app/job/lilypond.py:121):


    self.environment['LANG'] = 'C'
    self.environment['LC_ALL'] = 'C'

This doesn't disturb Guile1.8-LilyPond:

lukas@Aquarium:/tmp$ ~/lilypond-versions/2.22.0/bin/lilypond tröt.ly
GNU LilyPond 2.22.0
»tröt.ly« wird verarbeitet
Analysieren...
Interpretation der Musik...
Vorverarbeitung der grafischen Elemente...
Ideale Seitenanzahl wird gefunden...
Musik wird auf eine Seite angepasst...
Systeme erstellen...
Konvertierung nach »tröt-tröt.pdf«...
Kompilation erfolgreich beendet

lukas@Aquarium:/tmp$ LANG=C ~/lilypond-versions/2.22.0/bin/lilypond tröt.ly
GNU LilyPond 2.22.0
Processing `tröt.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Converting to `tröt-tr__t.pdf'...
Success: compilation successfully completed

So LilyPond still finds the file, but we see my \bootOutputSuffix 
problem (tröt.ly contains such a command).


Now with Guile2-LilyPond:

lukas@Aquarium:/tmp$ 
~/lilypond-versions/2.22.1-guile22/lilypond/bin/lilypond tröt.ly

GNU LilyPond 2.22.1
»tröt.ly« wird verarbeitet
Analysieren...
Interpretation der Musik...
Vorverarbeitung der grafischen Elemente...
Ideale Seitenanzahl wird gefunden...
Musik wird auf eine Seite angepasst...
Systeme erstellen...
Konvertierung nach »tröt-tröt.pdf«...
Kompilation erfolgreich beendet

lukas@Aquarium:/tmp$ LANG=C 
~/lilypond-versions/2.22.1-guile22/lilypond/bin/lilypond tröt.ly

GNU LilyPond 2.22.1
warning: cannot find file: `tr??t.ly'
fatal error: failed files: "tr??t.ly"

So I guess Frescobaldi's way of forcing LilyPond to display English 
messages (just force LANG and LC_ALL to C) has unintended side-effects 
for pathnames that somehow were partly masked before by some conversion 
magic that no longer happens with Guile2-LilyPond.


Thanks much for your help!
Lukas

\numericTimeSignature works on Staff level?

[Lukas-Fabian Moser]

Hi,

\numericTimeSignature works on Staff level - it has been this way since 
its first introduction by Graham Percival in 2008 
(929abcd11cf5305b0929e5ca75b12ffee9f57785). As a consequence,


\version "2.22.1"

<<
  \new Staff {
    \numericTimeSignature
    \time 2/2
    s1
  }
  \new Staff {
    s1
  }
>>

generates

What's the rationale for this behaviour (rather than making 
\numericTimeSignature act on Score level)?


By default, setting \time command affects all simultaneous staves, and I 
can't think of a reason why one should want "4/4" in one staff and "c" 
in another.


Of course there are polymetric situations where simultaneous numeric and 
non-numeric time signatures might be desired, but that's a comparatively 
rare use case, and if am moving around the Timing_translator anyway in 
\layout {}, I can also set Staff.TimeSignature.style manually.


Lukas

Re: Cairo

[Lukas-Fabian Moser]

Hi Knut,

Am 25.06.21 um 01:35 schrieb Knut Petersen:
For those who are interested: here is an updated version of my cairo 
patch.


This time around, I could get it to compile. :-)

After testing it against a bunch of my recent everyday LilyPond 
documents: For most of the files, it seems to work perfectly. (In 
Okular, I seem to notice very subtle differences in line widths, but 
those may be rendering artifacts.)


Also, in most cases, the Cairo-generated pdf is much smaller than the 
original. This seems most promising and not far from production quality!


Noticable defects:

- There's no support for colors yet, right?
- \markup \scale ... is ignored. Is this a fundamental limitation, or is 
this "just not done yet"?


Lukas

Re: Cairo based backend

[Lukas-Fabian Moser]

Hi Knut,

Am 05.07.21 um 00:10 schrieb Knut Petersen:

The attached patch implements a new backend based on Cairo.
To test select the desired output formats by any combination of the 
'--pdf', '--ps' and '--svg' command line options and  add 
'-dbackend=cairo'. The '--svg' option must precede the 
'-dbackend=cairo' option.


How hard would it be to also add support for -dpreview and -dcrop in the 
Cairo backend?


I'm experimenting with a workflow involving LilyPond-generated cropped 
SVGs, and I find that the SVGs generated via Cairo cause much less 
trouble than those made with the old SVG backend. (Of course, I can work 
with manually-cropped SVGs for the time being.)


Thanks so much for working on the Cairo implementation!

Lukas

Re: Cairo based backend

[Lukas-Fabian Moser]

How hard would it be to also add support for -dpreview and -dcrop in 
the Cairo backend?
... and same question for output-attributes as demonstrated in 
input/regression/output-attributes.ly ?


Lukas

Re: Reading files as byte array

[Lukas-Fabian Moser]

Would it be considered okay if we included a scheme function to read a
binary file to a byte array?

GUILE already supports this out of the box. Have you seen

https://www.gnu.org/software/guile/manual/html_node/Binary-I_002fO.html

?

Yes, of course GUILE supports this. But the problem is that this does not go
through Lilypond’s path handling. So I really do not think this would be a
good thing to use (of course one can use that internally, but I’m talking
about a Lilypond friendly interface).


Just from comparing those statements: Would it be reasonable (and maybe 
generally useful) to make global_path.find (used in gulp_file_to_string, 
lily-guile.cc) available at scheme level?


Lukas

Re: Reading files as byte array

[Lukas-Fabian Moser]

Just from comparing those statements: Would it be reasonable (and maybe
generally useful) to make global_path.find (used in gulp_file_to_string,
lily-guile.cc) available at scheme level?

see ly:find-file.


Aah, thanks much (sorry I didn't see it).

So then, Valentin, want you asked for seems to me to be just #(open-file 
(ly:find-file "[some-path]") "rb") ?


Lukas

Re-building Appendix A of notation.pdf

[Lukas-Fabian Moser]

Hi,

I'm probably missing something very obvious:

After changing a docstring in ly/music-functions-init.ly, what steps are 
necessary to re-build notation.pdf in order to check the result in "A.19 
Available music functions"? If I only delete notation.pdf and re-build 
it using


make -C Documentation out=www out-www/en/notation.pdf

I get the old docstring.

Lukas

PS. Speaking of that appendix: I don't know much about typography, but 
the kerning of "Av" in


doesn't seem right to me. Is that as it should be? (The image is from 
the pdf in the official 2.22/2.23 build.)

Re: Re-building Appendix A of notation.pdf

[Lukas-Fabian Moser]

but the kerning of "Av" in

doesn't seem right to me. Is that as it should be? (The image is
from the pdf in the official 2.22/2.23 build.)

... no image...


Sorry, shouldn't use inline images. See attached.

Lukas

Re: Re-building Appendix A of notation.pdf

[Lukas-Fabian Moser]

Hi James,



See: 
https://lilypond.org/doc/v2.21/Documentation/contributor-big-page.html#building-a-single-document


Did you do the 'touch' command?


Now I did :-) (thanks!), but touch'ing notation.tely doesn't do the trick.

If I'm not wrong, my question is how to force a re-build of 
out-www/en/identifiers.tely.


Lukas

Re: Re-building Appendix A of notation.pdf

[Lukas-Fabian Moser]

Hi Jonas,


If I'm not wrong, my question is how to force a re-build of
out-www/en/identifiers.tely.

I think you need to delete out{,-www}/en/internals.texi. This will
retrigger the rule to dump the internal documentation, which is partly
included into the Notation Reference.


That did it. Thanks!

For the record, in Documentation/ I did:

rm out-www/en/internals.texi
touch ../../Documentation/en/notation.tely
make out=www out-www/en/notation.pdf

@James: Yes, I realize that it says *.texi in the documentation 
(contributor.texi), but for Notation, there is no .texi file, so I 
thought the .tely file might be the correct candidate.


Lukas

Re: Shortcut for \repeat unfold

[Lukas-Fabian Moser]

Hi,


In short, I propose to make the first argument to
\repeat optional, making \repeat n music equivalent to
\repeat unfold n music.


Thanks for working on that!

The issue I have with your idea is that to me, \repeat unfold and 
\repeta volta/tremolo have slightly different semantics:


\repeat volta and \repeat tremolo create "time-honored" visual 
indicators for repeated music, so they are commands that correspond to 
special music layouts.

\repeat unfold saves typing while inputting music.

Of course, the distinction is not very strict, in particular since 
there's \unfoldRepeats. But still I'm not sure it's ideal syntax-wise if 
users have to use the same command for "saving typing" and for "creating 
musical repeat signs / tremolo notation". And this, I think, is 
exacerbated with your suggestion, because if \repeat alone is the 
keystroke-saving command, then \repeat volta and \repeat tremolo look 
like variants of that: Adding a qualifier turns the command into 
something completely different.



My experience is that every time I want to repeat a note
four times, I have a half-a-second wonder about whether
typing "\repeat unfold" will be shorter than cut-and-paste.
Absolutely. Of course it depends on which type of music you engrave, but 
in my "common practice"-heavy everyday work, \repeat unfold 16 d8 comes 
up _very_ often.

Other possibilities:

- "\rep n music", not as self-telling (and I think Lukas
  only calls his shortcut \rep because redefining \repeat
  is not syntactically valid);

... 'n 'cause it's even shrtr. :-)

- "music * n", attractive but the difference between c1*5
  and { c1 } * 5 would be confusing; also, for longer passages
  one would rather state the number of repetitions from the
  start than having to remember to put it at the end;
Yes, that is confusing to a degree I'm very skeptical if it's possible 
at all. You've already given the main example.

- "\* n music", very short but doesn't read as nicely I think,
  and I don't view repeats as special enough to warrant
  this kind of syntax with many special characters.


I think I disagree. After David suggested it in the gitlab thread, I 
used it in some scores and found it to be very convenient. (Maybe I'm 
biased because on german keybaord layout, \* can be entered in a single 
movement with a quite enjoyable thumb-midde-finger-pinkie-ring-finger 
flourish :-).) Also, brevity is key for keystroke-saving commands.


But your special-character argument made me think: Maybe it would be 
possible to get rid of the * sign? Maybe I'm missing something, but 
isn't \{unsigned int} still "available" so one could do \16 d8 instead 
of \*16 d8 ? Of course, probably only David K. can say for sure what 
implications that would have for parasing/lexing.


Aaron:


If the asterisk feels overloaded, you could use the multiplication sign:


\version "2.22.0"

× = % U+00D7 
I'd advise against introducing non-ASCII commands. Users won't be happy 
if they can't find on their keyboards what the documentation instructs 
them to type.


Lukas

Re: Shortcut for \repeat unfold

[Lukas-Fabian Moser]

Just as a counter-point, while I'm a light user / copyist, I don't 
think I've EVER used repeat unfold, while repeat percent happens a lot.


I actually quite like the "\x16 d8" idea as a shortcut, but what I'm 
saying is don't think it's a good idea, just because YOU do it a lot. 
Other people may have completely different work patterns ...


Yes of course, and LilyPond is a great tool for all different kinds of 
work patterns. But it's not a question of making one job easier for the 
price of making others harder, in which case your argument would be more 
relevant.


To give an example: The fact that I never (so far) needed/used guitar 
tabulature isn't an argument against improving work experience for 
people who do. As long as no-one proposes syntax changes that make 
guitar tabulature easier and figured bass harder, I'm very happy if the 
support for guitar tabulature improves.


Lukas

Re: Shortcut for \repeat unfold

[Lukas-Fabian Moser]

But your special-character argument made me think: Maybe it would be
possible to get rid of the * sign? Maybe I'm missing something, but
isn't \{unsigned int} still "available" so one could do \16 d8 instead
of \*16 d8 ? Of course, probably only David K. can say for sure what
implications that would have for parasing/lexing.

Guitarists (among other string instrument players) would likely object
to losing string number specifications.


I _knew_ I was missing something. Thanks.

(I stupidly only tried { \4 c' }. Even { \4 c' \4 d' } would have been 
enough to remind me of string numbers.)


Lukas

Re: Shortcut for \repeat unfold

[Lukas-Fabian Moser]

IS unfold the best candidate? Just because the OP makes extensive use 
of it, doesn't mean everyone else does. I'd rather it was percent, but 
I suspect I genuinely am a minority.


One of the reasons I argue against making \repeat $n \music equivalent 
to some \repeat X $n \music.


An implementation that doesn't require changes in the lexer/parser would 
have the advantage of allowing you to re-define it according to your 
needs. LilyPond is so great it even allows you to do:


\version "2.22"

repeat-shorthand = unfold

"\*" =
#(define-music-function (n mus) (index? ly:music?)
   #{ \repeat $repeat-shorthand $n { #mus } #})

{
  \*8 c'4

  #(set! repeat-shorthand "percent")
  \*8 d'4

  #(set! repeat-shorthand "tremolo")
  \*8 e'16
  e'2

  #(set! repeat-shorthand "volta")
  \*2 { f'4 e' d' c' }
}

But I expect also Jean's way of re-defining \repeat would allow for such 
a configurable option.


But what if more people would benefit if that tweak were applied to 
figured bass, rather than tablature?


Then we should find a way to make both happen (or let the user select 
according to their needs). :-)


Lukas

Re: Shortcut for \repeat unfold

[Lukas-Fabian Moser]

"\*" =
#(define-music-function (n mus) (index? ly:music?)
#{ \repeat $repeat-shorthand $n { #mus } #})

Instead of debating a default repeat type and function, why not provide access 
to repetition as a music function with a clear name like

 \repeatFunction type n music

And let the user decide how to abbreviate it?

 x = \repeatFunction unfold \etc


Maybe it helps to give some context: The discussion started with the 
problem of skipping notes in lyrics (using \addlyrics {} / \lyricsto {}) 
in the documentation. In order to skip multiple notes, the documentation 
currently suggests ugly things like


\repeat unfold 2 { \skip 1 }

that
a) are very cumbersome,
b) contain a mandatory-yet-unused duration argument.

I think b) can be remedied by using "" instead of the skip (I'm not sure 
yet if it's really equivalent), which leads to


\repeat unfold 2 ""

And I think it would be nice to have an even more natural variant for 
that; I think it's reasonable to provide & show/recommend convenient 
solutions for standard tasks (rather than say "you can define your own 
abbreviation here if you know how to do so") - for example,


\*2 ""    or    \x2 ""

which would be my favourite.

Lukas

Re: Shortcut for \repeat unfold

[Lukas-Fabian Moser]

Hi Jean,

I think it's a trap to see \repeat unfold as syntactic
sugar for repeating a sequence of characters n times
in the input. For instance,

\relative { \repeat unfold 4 c'1 }

is not the same as

\relative { c'1 c'1 c'1 c'1 }


Yes, of course. But I'd be very surprised if a large percentage of 
relative mode users would really expect "f4., g8 an then four times c,8" 
really to produce \relative { c, c, c, c, }. (Maybe those with a 
background in computer science would :-).)


So, when I talked about "syntactic sugar" I didn't mean the literal 
character-copy-and-paste sense.



Keyboards may be an important factor. Part of my
dislike for \* comes from the fact that on French
keyboards, the backslash is farther to the left,
on the same key as 8, making it less convenient
than what you describe.

They are not the only factor though. Let's see how
it looks visually:

{ c'1 \repeat 5 dis'8-_ c'1 }

{ c'1 \x 5 dis'8-_ c'1 }

{ c'1 \* 8 dis'8-_ c'1 }

{ c'1 dis'8-_**8 c'1 }

With \x or \*, I find it harder to discern the structure.
They are so small that they seem sprinkled over the input
without grouping other elements -- the third one in
particular looks like \* is some shortcut and 8 is
a duration repeating the previous pitch as in { c'1 8 }.


I think you're making it harder to read than necessary: Why the space 
after \* / \x ?



I like Werner's suggestion with ** better already.
What worries me a bit is the difference with the
existing use of *, which might be confusing. R1*5
will be (most of the time) equivalent to R1**5,
whereas c'1*5 will not be the same as c'1**5.
Something like c'1\p**5 will be valid, contrary to
c'1\p*5; c'1*4/5 will work but not c'1**4/5; …

I have to think about it a bit more.
My gut feeling is that postfix ** might be dangerous/difficult to 
implement robustly. But feel free to ignore this uneducated guess. :-)

I wouldn't push it so far -- it's easy enough to write
a music function for the repeat style you use most
often, just like you can shorten a lot of things
with variables and music functions, even more
conveniently now that we have \etc (let's hope the
latter would start working with \repeat someday).


By now, I know a handful of "normal" musicians among my friends who use 
LilyPond for their occasional engraving tasks. From what they show me 
when they have questions, I think there is still a significant number of 
users that stay in the mode of "never defining anything new except music 
variables" (and are still able to produce impressive scores). Of course, 
the advent of \etc has made it extremely easy to create simple music 
functions without even realising it; but I still think a sentence like 
"it's easy enough to write a music function" makes a possible feature 
practically invisible/unattainable for a large percentage of users: The 
idea of defining parameterised short-hands is not familiar to many 
people without a maths/computer science background.


Lukas

Re: Shortcut for \repeat unfold

[Lukas-Fabian Moser]

Maybe it helps to give some context: The discussion started with the 
problem of skipping notes in lyrics (using \addlyrics {} / \lyricsto 
{}) in the documentation. In order to skip multiple notes, the 
documentation currently suggests ugly things like


\repeat unfold 2 { \skip 1 }

that
a) are very cumbersome,
b) contain a mandatory-yet-unused duration argument.

I think b) can be remedied by using "" instead of the skip (I'm not 
sure yet if it's really equivalent), which leads to


\repeat unfold 2 ""

And I think it would be nice to have an even more natural variant for 
that; I think it's reasonable to provide & show/recommend convenient 
solutions for standard tasks (rather than say "you can define your 
own abbreviation here if you know how to do so") - for example,


\*2 ""    or    \x2 ""

which would be my favourite.


Well, \repeat unfold has become sort of an independent
issue from my point of view since what I would rather
see in lyrics is some way to make explicit durations
override the synchronization between lyrics and melody,
either as

\lyricmode {
  lyrics following notes
  lyrics8 with4. \skip 1 own2. rhythm1*3/4
  follow notes again
}

or (if the compatibility breakage were too high)

\lyricmode {
  lyrics following notes
  \noSync { lyrics8 with4. \skip 1 own2. rhythm1*3/4 }
  follow notes again
}


I'm still not sure if it's possible to give this a well-defined meaning 
at the boundaries between sync'ed and non-sync'ed lyrics.


Anyway: As I now know, "" is not a suitable replacement for a lyric skip 
(it stops lyric extenders). So, regarding my initial merge request: I 
still think that "\skip 1" in lyrics (the necessary-but-discarded 
duration argument) is sufficiently ugly to warrant hiding it behind 
special syntax, e.g. \lyricSkip as I proposed (or \skipNote). I agree 
that the multi-notes variant in that said merge request might be 
overkill, and I'd be absolutely fine with trashing that.



\*… well I can't say I'm a huge fan of it, but it looks reasonable enough.


[...]


We have a lot of syntax to remember already. While I advocate
an addition here for something that I consider sufficiently
generally useful (notably for presentation contexts where custom
shorthands are not wanted), I think we should be parcimonious
when adding new syntax, because more of it also means looking
up the documentation more frequently when you are not
an intensive user.
(Please forgive me for re-arranging your mail, I hope I didn't distort 
your intended meaning.)


Yes, absolutely. I think for \repeat unfold ... it might be warranted, 
though: That is sufficiently clumsy (if used for repeating single notes, 
for example) and at the same time ubiquitous that a shorthand might be a 
worthwhile addition. Of course it's true that everybody may define 
shorthands for whatever constructions they use the most, but if an 
addition makes it possible to give examples in the NR in a way that is 
succinct and easy to write and read, that might be a good idea. After 
all, the NR should show how elegant and convenient entering music in 
LilyPond can be - not demonstrate a cumbersome way of expressing things 
that "insiders" might know how to simplify.

Do note, however, that:

One of the reasons I argue against making \repeat $n \music 
equivalent to some \repeat X $n \music.


An implementation that doesn't require changes in the lexer/parser 
would have the advantage of allowing you to re-define it according to 
your needs. LilyPond is so great it even allows you to do:


is not entirely true: once a function is defined, it can be
relied on internally. Imagine my embarrassment when I had to
explain on -user-fr the cause of the error occurring with
the code (minimized here):

cons = \markup \tiny "conséquent"

{
  \stemDown
  c'2^\cons
  \undo \stemDown
  c'2
}
Agreed: The possibility to redefine things ends where redefinitions 
render the whole system unusable. But I'm really glad that your example 
does not crash anymore, as that shows that it's become quite less easy 
to disrupt LilyPond in such a way.

I like Werner's suggestion with ** better already.
What worries me a bit is the difference with the
existing use of *, which might be confusing. R1*5
will be (most of the time) equivalent to R1**5,
whereas c'1*5 will not be the same as c'1**5.
Something like c'1\p**5 will be valid, contrary to
c'1\p*5; c'1*4/5 will work but not c'1**4/5; …

I have to think about it a bit more.


If ** could be make to work, it might be a good idea to demonstrate its 
use in the manuals only with spaces. Of course they don't 
(shouldn't/mustn't) make a difference to LilyPond, but to the human 
reader, "c4 ** 5" is much less likely to be mistaken for "c4*5" than 
"c4**5". There's a reason we write


\relative {
  c'4 d8 e f4 d
  e4 d c2
}

and not

\relative { c' 4d 8e f 4d e 4d c 2 }


By now, I know a handful of "normal" musicians among my friends

Oh, my notion of my own normality totters somewhat… ;-)

I took care o

Re: Shortcut for \repeat unfold

[Lukas-Fabian Moser]

I answer somewhat orthogonally to your question: I think that for many
people it's a lot easier to digest the information

"\* creates unfolded repeats; this behaviour may be changed using
\defaultRepeatType percent"

That is one step forward, one step back: one advantage of a fixed
shorthand is that documents written in colloboration can depend on it.
"this behavior may be changed" negates that again.


Yes, undoubtedly (although it's not uncommon to have default behaviour 
that may be customized, and every collaborative effort is going to need 
some conventions regarding coding style etc. anyway).


But in the context you quoted, I was not advocating a concrete solution 
involving some fixed-but-configurable shorthand, but instead trying to 
weigh "didactical" aspects. In short: I agree with Jean that, since it's 
not useful to have an abundance of dedicated solutions, it might be 
better to think about documentation (good exposition and enlightening 
examples) that enable as many people as possible to put universal tools 
to good concrete use.



  One reason \etc is so great is that you
can use it in many different cases without thinking too much
or writing a single line in an esoteric, err, not very
commonly spoken programming language.

Absolutely. It's an incredibly elegant tool.




I'm not sure what your point is (but that thread's an enlightening read, 
anyway). It seems to show that - considering the importance of 
suggestive names - Dan deserves a fair share of credit for the ingenuity 
of \etc as well.


Lukas

Re: Shortcut for \repeat unfold

[Lukas-Fabian Moser]

28x { d a b fs | g d g a }

https://gitlab.com/lilypond/lilypond/-/merge_requests/937


That is a clever proposal. I am already fond of it.
Thank you.


This looks so "natural" (in the non-computer science-way of the meaning) 
one is surprised it works. :-)



What this means is that if you create a custom note
name language (with the undocumented not-yet-having-interface
#(set! language-pitch-names (acons 'mylang my-pitch-alist
language-pitch-names))), you won't be able to call a
note 'x', because

{ c4 x4 }

will be understood as

{ c 4x 4 }

I don't see that as a big deal. Using 'r' or 'R' or 'q'
as a note name is already not supported. To me, the
addition of this shorthand is worth a new element on
this list.


I agree with regard to pitch names; but what about Lyricmode (and also 
Figuremode etc.)?


Lukas

Lyric extenders in/out of alternatives

[Lukas-Fabian Moser]

Folks,

in my quest to maybe get rid of the recommendations of "\skip 1" for 
lyrics in the NR I stumbled upon the following example in 
http://lilypond.org/doc/v2.23/Documentation/notation/techniques-specific-to-lyrics.html:


% If you wish to show extenders and hyphens into and out
% of alternative sections these must be inserted manually.

\version "2.23.4"

\relative {
  \time 2/4
  \repeat volta 2 { b'4 b ~}
  \alternative {
    \volta 1 { b b }
    \volta 2 { b \repeatTie c }
  }
  c4 c
}
\addlyrics {
  Here's a __ verse.
  \repeat unfold 2 { \skip 1 } % btw: why this line?
}
\addlyrics {
  Here's "a_"
  \skip 1
  "_" sec -- ond one.
}

(I simplified the input code a bit - which I actually also would like to 
propose for the NR -, but the gist of the original example remains 
unchanged.)


Now this looks kind-of decent in the NR, but once you issue ragged-last 
= ##f, the limits of that hack show clearly (see attached image). And 
there should be a difference between a LyricExtender and an underscore 
as part of literal lyrics.


Of course the problem is exacerbated if the second alternative extends 
the melisma with multiple notes.


The best I could come up with is:

\relative {
  \time 2/4
  \repeat volta 2 { b'4 b ~}
  \alternative {
    \volta 1 { b b }
    \volta 2 { b \repeatTie c }
  }
  c4 c
}
\addlyrics {
  Here's a __ verse.
}
\addlyrics {
  Here's \set ignoreMelismata = ##t a __
  "" "" \set ignoreMelismata = ##f
  \markup\null __  sec -- ond one.
  % \markup\null doesn't kill melismata,
  % in contrast to ""
}

This has the advantage of being more-or-less semantically correct input, 
and it works with longer melismata:


\relative {
  \time 2/4
  \repeat volta 2 { b'4 b( | c8 b a g | }
  \alternative {
    \volta 1 { b4) b }
    \volta 2 {
  \shape #'((-3 . 0) (-2 . 0) (-1 . 0) (0 . 0)) Slur
  a8( b c b) | }
  }
  a8 g g4
}
\addlyrics {
  Here's a __ verse.
}
\addlyrics {
  Here's \set ignoreMelismata = ##t a __ _ _ _ _
  "" ""
  \set ignoreMelismata = ##f \markup\null __  sec -- ond one.
}

Does anybody see a better solution that might be good enough for the NR?

Of course, the ideal solution would be a possibility to tell the Lyrics 
context that it should "take" the second alternative and make it skip 
the first alternative automatically (and suspend the LyricExtender along 
the way). But my feeling is that this would be not so easy to implement.


Lukas

Re: Lyric extenders in/out of alternatives

[Lukas-Fabian Moser]

Does anybody see a better solution that might be good enough for the NR?


Well-invented. I don't see anything better.


Thanks (also for looking at this in the first place).

My feeling is that this should replace the "_something" example in the 
NR, but because of its complexity, it should perhaps rather be a 
"selected snippet" than a regular NR example. Would that be reasonable?


Of course, the ideal solution would be a possibility to tell the 
Lyrics context that it should "take" the second alternative and make 
it skip the first alternative automatically (and suspend the 
LyricExtender along the way). But my feeling is that this would be 
not so easy to implement.


Probably doable, and probably a fair bit of work.


I'd basically be interested in trying to understand the mechanics 
involved, but seeing as term started today at our university, I'm 
sceptical I can spend serious time on this before Christmas break. (And 
there's a fair chance it would be above my head anyway.)


Lukas

Re: Lyric extenders in/out of alternatives

[Lukas-Fabian Moser]

Am 05.10.21 um 01:41 schrieb Dan Eble:


I'd basically be interested in trying to understand the mechanics involved, but 
seeing as term started today at our university, I'm sceptical I can spend 
serious time on this before Christmas break. (And there's a fair chance it 
would be above my head anyway.)

Volta_specced_music_iterator emits VoltaSpanEvents carrying i,j,k at the start 
and end of \volta i,j,k {}.  I expect that Lyric_combine_music_iterator could 
register for these events and use them to ignore notes that do not apply to the 
volta of interest.
Thanks for that explanation, which goes on the heap of things I have to 
try to wrap my head around. :-)

You would want a way to indicate in the ly code that a span of lyrics should be 
set to a specific volta of the music.  The existing stanza number feature seems 
obvious, but it would be limiting.  (Examples: a partly through-composed 
arrangement with 2 stanzas per volta; a transcription of stanzas 1, 5, and 9 of 
a source in a situation where renumbering is undesirable)


Yes, I agree that StanzaNumber is not the right tool for this: This is 
presentation layer, and as I abuse this every day with (the German 
version of) stuff like \set Stanza = "C major:" - music theory teacher 
here :-) -, I'd be vary of adding any semantic meaning to the contents 
of the Stanza markup.



I am asking myself, "Why not use \volta for that?" and I don't have an answer 
yet.


If I understand correctly, this would require writing \volta i,j,k { } 
in \lyricmode at precisely the "right" places in sync with the 
repeats/alternatives in the music. Is that right?


My gut feeling is that stanza-behaviour might be more of a persistent 
(changeable) property of a line of Lyrics: If unset, Lyrics ignore any 
\volta's they encounter in the associated voice. If set (to a volta 
number or a list of such), any voltas they encounter along the way would 
be skipped if the numbers don't match.


Feel free to ignore this if this obvious nonsense with respect to the 
inner workings.


Lukas

Re: Lilypond is now on Homebrew for macOS Mojave or higher (Intel or M1)

[Lukas-Fabian Moser]

Folks,

Am 05.10.21 um 14:39 schrieb Jefferson Felix:
No problem, I was just pointing out the reasons why Guile 1.8.8 was 
not approved by the homebrew core. I even believe this will help 
advance Guile 2 compatibility, and certainly the Lilypond development 
community will pick up on any bugs.


> To follow up on Jeans remarks: Maybe (if it's not already the case) 
it would be a good idea if your LilyPond version would show a message 
regarding Guile 2 on startup


We did something similar when we build TeXLive for homebrew, showing a 
message that it's a Homebrew distribution (something like TeXLive 
2021/Homebrew). But TeXLive has a way to do this without touching the 
source code. I'm going to check Lilypond's build documentation if it's 
possible to do something like this.


Would it be considered reasonable to hard-wire a special startup message 
in LilyPond proper if it is being built with Guile2 (or rather: detects 
guile-2 on startup)?


The new Homebrew build uses guile2, and I suggested they turn the 
startup message


GNU LilyPond 2.22.0

into something like

GNU LilyPond 2.22.0 (Guile 2 build)

to aid debugging, and if I understand Jefferson correctly, they do not 
want to touch the source code themselves.


Lukas

Re: Lilypond is now on Homebrew for macOS Mojave or higher (Intel or M1)

[Lukas-Fabian Moser]

[Jean]

What kind of next version, next minor of
current stable, i.e. 2.22.2, or next
stable release, 2.24?

Which leads me to ask:

@Jefferson: Would it be conceivable to do Homebrew builds also for 
(odd-numbered) development versions of LilyPond? LilyPond tends to have 
a conservative policy regarding stable releases (although the six year 
hiatus between 2.18.2 in March 2014 and 2.20.0 in March 2020 might be 
considered extreme even by LilyPond's standards). But at the same time, 
LilyPond development procedures make sure that today, Master never 
really breaks: Every patch in master gets a thorough review and, equally 
important, is tested against an extensive suite of regression tests. 
Because of this, LilyPond master is kept always in a working condition, 
and the development releases (which are cut from git master from time to 
time) can be expected to (although they are not guaranteed to) allow 
production-quality work. In fact, many LilyPond users routinely use the 
development versions, as they are the only option (short of 
do-it-yourself building) to make use of new features in the often long 
time between stable releases. So if it would be possible to do not only 
a "lilypond" package but also a (more frequently updated) 
"lilypond-devel" package, this would match the use practice of many 
LilyPond users even better.


As for the underlying question, I think a modified version message if 
LilyPond is running Guile2 (or Guile3, for that matter) would be enough. 
(And I agree with J.F. that this message should only mention Guile, not 
Homebrew.) If I understand Jonas's remark correctly, it should make no 
difference if this is done at compile time via C++ #ifdef GUILEV2 (as in 
Jean's proposal) or at runtime via Scheme cond-expand, right?


Lukas

Re: Proposing commit access for Lukas-Fabian Moser

[Lukas-Fabian Moser]

Am 06.10.21 um 21:21 schrieb Jean Abou Samra:

Hi all,

Rebasing and merging Lukas' \after patch this
morning, I had a wonder moment — wait, he still
doesn't have commit access? Seeing his recent patches,
which all required substantial discussion and
refinement as well as documentation and regression
tests (bracketed bass figure alterations, \after,
\numericTimeSignature, the closed \lyricSkip), as
well as his participation on lilypond-devel, and
of course on lilypond-user for quite some time, I
believe Developer role on GitLab is long overdue.
As a reminder, this means the ability to merge
one's patches as well as change merge request
labels (which is useful often). Thoughts?


Of course that's very flattering, thanks.

Not really having any serious software development experience, I'm 
really impressed by the way LilyPond development is structured nowadays: 
You manage to, at the same time, keep the threshold for new contributors 
very low (a Gitlab account is enough), make sure that a rookie 
contributor can't break anything, and, by a huge amount of generosity 
and helpfulness of you guys, help polish and improve amateur 
contributions enough that they can actually be merged eventually.


Thanks much, and maybe that's a good opportunity to reiterate that my 
everyday work (as a theory teacher at a music university) wouldn't be 
possible the way it is without LilyPond. It's an incredible piece of 
software, and I would have to think very hard to find even a day over 
last few years that I didn't use it.


As for the question of commit access, for me it's a trade-off between my 
fear of accidentally breaking something and my wish not to burden others 
too often with eventual rebasing/merging chores the way Jean generously 
did for me a couple of times.


Lukas

Re: Proposing commit access for Lukas-Fabian Moser

[Lukas-Fabian Moser]

Don't worry about breaking something!  In almost all cases this gets
caught by the CI infrastructure.  I think we all agree that it would
be very beneficial if you have commit rights.


Thanks! So I clicked the "Request access" button yesterday. Should I do 
anything else?


Lukas

Re: Proposing commit access for Lukas-Fabian Moser

[Lukas-Fabian Moser]

No, that was the only required step after writing to the mailing list
(as documented in the CG), afterwards somebody with Owner permissions
(currently Han-Wen and me) have to press the button to accept, which I
just did. The complication here is that GitLab doesn't send email
notifications that there is a new access request, so I have to check
manually 😞 sorry for the delay.


No problem - thank you very much!

It's quite surprising, actually, that there is something for which 
Gitlab _doesn't_ send notifications. :-)


Lukas

Re: markup-command rounded-box is broken

[Lukas-Fabian Moser]

Hi Harm,


I noticed a bug with recent master:

\markup \rounded-box "foo"

prints completely black.

First bad commit is:
commit 0772e38398972d6c2b4ba9e6f42e7725d973e08b
Author: Han-Wen Nienhuys 
Date:   Sun Aug 1 11:15:02 2021 +0200

 Stop passing color names to output backends


Well, comparing that version pre- and post-change

 (define-public (rounded-box-stencil stencil thickness padding blot)
   "Add a rounded box around @var{stencil}, producing a new stencil."

   (let* ((xext (interval-widen (ly:stencil-extent stencil 0) padding))
  (yext (interval-widen (ly:stencil-extent stencil 1) padding))
  (min-ext (min (-(cdr xext) (car xext)) (-(cdr yext) (car yext
  (ideal-blot (min blot (/ min-ext 2)))
  (ideal-thickness (min thickness (/ min-ext 2)))
  (outer (ly:round-filled-box
  (interval-widen xext ideal-thickness)
  (interval-widen yext ideal-thickness)
  ideal-blot))
- (inner (ly:make-stencil (list 'color (x11-color 'white)
-   (ly:stencil-expr 
(ly:round-filled-box
- xext yext (- 
ideal-blot ideal-thickness)))

+ (inner (ly:make-stencil (ly:stencil-in-color
+  (ly:round-filled-box
+   xext yext (- ideal-blot 
ideal-thickness))

+   "white"
 (set! stencil (ly:stencil-add outer inner))
 stencil))

it seems to me that before Han-Wen's change, ly:make-stencil was 
necessary since the code manipulated the stencil expression of the 
round-filled-box directly, thus returning a stencil expression. Now, 
with the use of ly:stencil-in-color, we get an actual stencil 
immediately, so the call ly:make-stencil (which expects a stencil 
expression) is superfluous and (I think) wrong.


But to be honest, rounded-box-stencil seems to me to be broken anyway:

If you compare it with ellipse-stencil directly above (and looking at 
the docstrings), one should expect to get the original stencil with an 
added rounded box. But rounded-box-stencil

a) doesn't use the original stencil in stencil-add,
b) overwrites the original stencil with set!

Hence, the markup command \rounded-box has to take care to add the 
original markup:


  (let ((th (* (ly:output-def-lookup layout 'line-thickness)
   thickness))
    (pad (* (magstep font-size) box-padding))
    (m (interpret-markup layout props arg)))
    (ly:stencil-add (rounded-box-stencil m th pad corner-radius)
    m)))

So in my impression, rounded-box-stencil might deserve a refactoring anyway?

Lukas

Re: markup-command rounded-box is broken

[Lukas-Fabian Moser]

So in my impression, rounded-box-stencil might deserve a refactoring 
anyway?


I would propose:

lukas@Aquarium:~/git/lilypond/scm(dev/lfm/rounded-box)$ git diff master
diff --git a/scm/define-markup-commands.scm b/scm/define-markup-commands.scm
index cb99a960fe..8b54fd048a 100644
--- a/scm/define-markup-commands.scm
+++ b/scm/define-markup-commands.scm
@@ -960,8 +960,7 @@ c,8. c16 c4 r
    thickness))
 (pad (* (magstep font-size) box-padding))
 (m (interpret-markup layout props arg)))
-    (ly:stencil-add (rounded-box-stencil m th pad corner-radius)
-    m)))
+    (rounded-box-stencil m th pad corner-radius)))

 (define-markup-command (rotate layout props ang arg)
   (number? markup?)
diff --git a/scm/stencil.scm b/scm/stencil.scm
index 0409242a05..e1df561fa6 100644
--- a/scm/stencil.scm
+++ b/scm/stencil.scm
@@ -708,12 +708,11 @@ producing a new stencil."
  (interval-widen xext ideal-thickness)
  (interval-widen yext ideal-thickness)
  ideal-blot))
- (inner (ly:make-stencil (ly:stencil-in-color
-  (ly:round-filled-box
-   xext yext (- ideal-blot 
ideal-thickness))

-   "white"
-    (set! stencil (ly:stencil-add outer inner))
-    stencil))
+ (inner (ly:stencil-in-color
+ (ly:round-filled-box
+ xext yext (- ideal-blot ideal-thickness))
+ "white")))
+    (ly:stencil-add outer inner stencil)))

 (define-public (flip-stencil axis stil)
   "Flip stencil @var{stil} in the direction of @var{axis}.

Lukas

Re: markup-command rounded-box is broken

[Lukas-Fabian Moser]

this would have the advantage to be inline with the doc-string and
solve the issue at hand.

Should I prepare a MR?

Though, speaking of refactoring rounded-box-stencil.
It always bugs me to see some stencil overlaying to get a simple line.


Yes, that's an obvious and unpleasant limitation: Something that should 
behave as transparent (cut-out of another object) is mimicked by a 
hardcoded white area.


I'm not sure this can be remedied easily. I don't understand much of the 
output code, but my impression is that filled-rounded-boxes are created 
by using corresponding features of the respective output engine (PS 
interpreters, SVG standard, Cairo). I may be wrong, but this would seem 
to indicate that, for an actual solution, one would either need actual 
nonfilled-rounded-box support in all these engines, or instead a way to 
remove parts of an already drawn stencil.


But I'm happy to be corrected by those who understand the workings of 
the output engines.


Lukas

Engraver_group with parent context type?

[Lukas-Fabian Moser]

Folks,

while trying to tidy up ly/engraver-init.ly a bit (which seems to have 
experienced some rank growth over the years) I stumbled upon:


\context {
  \Staff
  \type "Engraver_group"
  \name "DrumStaff"
  \alias "Staff"

  % (etc.)

}

That's the only instance of a context definition that contains _both_ a 
parent context type (\Staff) _and_ \type "Engraver_group".


Is that correct? I don't know enough about the inner workings to judge 
reliably.


Lukas

Re: Engraver_group with parent context type?

[Lukas-Fabian Moser]

Am 01.11.21 um 21:40 schrieb Jean Abou Samra:


In short: useless but not problematic.


Am 01.11.21 um 21:08 schrieb David Kastrup:
It's redundant. Not incorrect, at worst slightly inconsistent/ugly. 


Thanks much to both of you (and also for the very enlightening code 
snippets that make the reasoning completely clear).


So, while I'm cleaning up engraver-init.ly anyway, I'll just throw out 
the useless extra \type.


Lukas

Re: Manipulating instrument names and staff group names

[Lukas-Fabian Moser]

Hi Kieren,


A blatant counter-example is in the person of Harm.

So C++ and Scheme *are* [as I first suggested] separable?


There's lots of stuff one can do in Scheme alone. But it seems to me to 
be a non-trivial task in general to decide a priori whether, given a 
feature request or bug report, there is a feasible Scheme-only solution 
for that particular question.


Also, certain C++ parts of LilyPond can in principle be ported to 
Scheme, so even if some feature that you want to extend is currently 
implemented in C++, it might still be possible to re-implement it in Scheme.


Lukas

Re: TimeSignature with note in denominator

[Lukas-Fabian Moser]

Hi,


BTW, Gould gives the following example in her book (also noting that
it would be better to use 15/16 together with a '2+3 sempre' remark
instead).

 3
   --
   8 ~ 8.

(the tilde denotes a tie).


Sorry if I miss the point completely (I only skimmed part of the e-mail 
thread).


This reminds me of the \rhythm markup function that David K. once 
suggested (if I recall it correctly); the version I'm currently using is:


\version "2.23.4"

#(define-markup-command (rhythm layout props content) (ly:music?)
   #:properties ((time #f))
   (interpret-markup layout props #{
 \markup {
   \score {
 \new RhythmicStaff \with {
   \override StaffSymbol.line-count = 0
   \override Rest.staff-position = 2
   \override BarLine.bar-extent = #'(-0.5 . 2)
   \override TimeSignature.Y-offset = 0.5
   #(if (not time)
    #{ \with {
  \remove Time_signature_engraver
    } #})

 }
 {
   #(if time #{ \time $time #})
   #content
 }
 \layout {
   indent = 0
   #(layout-set-staff-size 12)
 }
   }
 } #}))

\markup \rhythm { 8 ~ 8. }

This could be used for a \time variant:


wernerTime =
#(define-music-function (num den) (positive? ly:music?)
   #{
 \override Timing.TimeSignature.stencil =
 #(lambda (grob)
    (grob-interpret-markup
 grob
 #{
   \markup \override #'(baseline-skip . 0) \center-column {
 \number #(number->string num)
 \rhythm { \voiceTwo #den }
   }
 #}))
 \time 4/4 % of course that's crazy
 \set Timing.measureLength =
 #(ly:moment-mul
   (ly:music-length den)
   (ly:make-moment num))

   #})

{
  \wernerTime 3 { 8 ~ 8. }
  \repeat unfold 15 c'16
  \wernerTime 1 { 8. }
  \repeat unfold 9 c'16
}

Of course there's a lot of work undone - in particular, constructing a 
beat structure out of the given rhythm.


Lukas

Re: TimeSignature with note in denominator

[Lukas-Fabian Moser]

Hi Elaine,

The first is, how is the usage of \time different in lyrics than anywhere
else?

Frankly, I was not aware that using \time inside lyrics was a thing.
What is the reason to use \time inside lyrics?
It is a suggested practice, is it the only way of doing certain things?


I'm not claiming it's a _common_ thing, but it's not hard to think of 
situations in which I would definitely consider it useful:


\version "2.22"

\layout {
  \context {
    \Lyrics
    \consists Time_signature_engraver
    \consists Bar_engraver
    \override BarLine.bar-extent = #'(-2 . 2)
    \override BarLine.extra-spacing-width = #'(-1 . 1)
    \override LyricText.Y-offset = -0.5
  }
}

\new Lyrics \lyricmode {
  \time #'(3 3 3 2) 11/8
  Sun4. sun sun here8 it
  \time 4/4
  comes1
  \time #'(2 2 3) 7/8
  \skip 2 \skip 4.
  \time #'(3 3 3 2) 11/8
  Sun4. sun sun here8 it
  \time 4/4
  comes1

}

Lukas

Re: TimeSignature with note in denominator

[Lukas-Fabian Moser]

Hi Kieren,


You’re not extrapolating the concept, as I have been asking people to, so I’ll 
once again make it more explicit for you:

I want the user to be able to say

 \tweak style #'note-denom \time 3/4.
or
 \tweak style #'note-denom \time #'(3 . "4.")
or
 \tweak style #'note-denom \time #'(3 . {4.})

or basically any other intuitive input that would allow a dotted duration for 
the denominator, which would pass through the parser to the TimeSignature 
formatting function(s) without “loss” (as per Aaron described it).


It's probable that I'm missing a point (since I only skimmed the 
discussion so far), but:


Currently, \time is defined (in ly/music-functions-init.ly) with the 
signature


#(define-music-function (beat-structure fraction)
   ((number-list? '()) fraction?)

Now the predicate fraction? is defined (in scm/c++.scm) as

(define-public (fraction? x)
  (and (pair? x)
   (index? (car x)) (index? (cdr x

to wit, a pair of non-negative exact integers.

Now the lexer turns 3/4 into such a pair: See lily/lexer.ll, by virtue 
of the lines


N        [0-9]
FRACTION    {N}+\/{N}+

which translate as "a fraction consists of one or more digits, followed 
by /, followed by one or more digits"; and the call to the procedure 
scan_fraction; just search for it in lexer.ll. (I'm deliberately giving 
you more information than you probably need, to help you navigate the 
source and see how everything fits together.)


So, \time 3/4 is converted to \time #'(3 . 4) already while lexing, 
which is very early and very "basic". It's no problem at all to make 
\time accept more general pairs: Just replace fraction? by (e.g.) pair? 
in the definition of \time, or define a suitable predicate of your own 
accepting only the "right" kind of pairs.


So, of your three examples, only the first one (\time 3/4.) definitely 
would require changes to the lexer/parser. The others are not hard to 
implement (provided I don't miss something). But: I think it would be 
desirable to be able to enter durations in LilyPond syntax, in order to, 
for example, be able to enter complicated constructs like "8.~8" from 
Werner's example. But if you want to include LilyPond syntax in an 
explicit pair argument, you need #{ #} which certainly works but makes 
for horrible syntax:


test =
#(define-void-function (test) (pair?)
   (display-scheme-music test))

\test #`(3 . ,#{ 8~8. #})
% or not much better:
\test #(cons 3 #{ 8~8. #})

Wouldn't it be easier to define an independent \kierenTime function that 
expects an integer (index?) numerator and a music (ly:music?) 
denominator? Then we could just write


\version "2.22"

kierenTime =
#(define-void-function (num den) (index? ly:music?)
   (format #t "~a\n" num)
   (display-lily-music den))

\kierenTime 3 { 8~8. }
\kierenTime 3 4.  % the dot is important :-)

I provided a very silly simple example along these lines in my mail 
replying to Werner's example. I'm not sure if you saw this, as you 
reported that only part of the discussion came through to your end.


Lukas

Re: TimeSignature with note in denominator

[Lukas-Fabian Moser]

Wouldn't it be easier to define an independent \kierenTime function 
that expects an integer (index?) numerator and a music (ly:music?) 
denominator? Then we could just write


\version "2.22"

kierenTime =
#(define-void-function (num den) (index? ly:music?)
   (format #t "~a\n" num)
   (display-lily-music den))

\kierenTime 3 { 8~8. }
\kierenTime 3 4.  % the dot is important :-)


... or, of course, a helper function that can be used after \time, like 
Aaron proposed.


\version "2.22"

time =
#(define-music-function (beat-structure fraction)
   ((number-list? '()) pair?)  ; note that pair? is way too general.
   (_i "Set @var{fraction} as time signature, with optional
number list @var{beat-structure} before it.")
   (if (fraction? fraction)
 (make-music 'TimeSignatureMusic
  'numerator (car fraction)
  'denominator (cdr fraction)
  'beat-structure beat-structure)
 (begin
   (ly:warning "Non-fraction time signature not yet implemented.")
   (format #t "Given denominator:\n")
   (display-lily-music (cdr fraction))
   (empty-music

kieren =
#(define-scheme-function (num den) (exact? ly:music?)
   (cons num den))

{
  \time 4/4
  c'1
  \time \kieren 5 { 8~8.} c'4
}

Lukas

Re: TimeSignature with note in denominator

[Lukas-Fabian Moser]

Hi Kieren,


See my “stylesheet” comment earlier in the thread: in a perfect world, a user 
should be able to take any existing score and simply add

\override Score.TimeSignature.style = #'note-denom

and the output would be “as expected” — with a new function, a 
search-and-replace (with possible “fancy” manipulation of the arguments) is 
required every time the user wants to switch between styles. I personally 
consider that inelegant, or at the very least suboptimal, especially when 
Lilypond offers such a generous “global” context modification mechanism.

All that being said: The tide of resistance to finding the optimal 
implementation is evident, so I think I’ll just give up and add a new function 
in order to move the patch/feature forward.


Oh, please don't give up just yet! :-)

You can very well have both: A TimeSignature style that turns 
old-fashioned \time 3/4 into "3 over a crotchet", and a vast 
generalization of the \time machinery that also accepts durations, tied 
combinations of durations etc. (and which, for simple durations like 
4,8,16 etc., falls back to standard \time 3/4 behaviour).


Question: What should happen if TimeSignature.style = #'note-denom is 
_not_ set, but the user does \time 4 { 8.~8 } ? Should this emit a 
warning "can't display this in current style", or ... ?


Lukas

Re: TimeSignature with note in denominator

[Lukas-Fabian Moser]

Hi Kieren,

Am 13.11.21 um 16:19 schrieb Kieren MacMillan:

1. Is there any objection to me adding a TimeSignature style which would 
immediately apply to all already-accepted time signatures?

2. If not, does anyone have opinions on what that style name should be? (Ones 
that seem like obvious candidates to me include 'note-denom, 'notehead, and 
'glyph… but I’m happy to hear suggested alternatives.)


I think that would be a great first contribution for you.

As for the name: Probably "denominator" and "note" should be a part of 
the name. "notehead" is wrong (you want to be able to distinguish 
crotchets and quavers and whatever English names I can come up with to 
annoy you ;-).) And if note-denominator is too long, note-denom might 
actually be a reasonable candidate.



Question: What should happen if TimeSignature.style = #'note-denom is _not_ set, but the 
user does \time 4 { 8.~8 } ? Should this emit a warning "can't display this in 
current style", or ...


For this longer-term project (\time \musicDenom 3 { 8.~8 }), there would 
be significant design choices involved: Which part of a music expression 
should be honoured, and what effect should they have especially on the 
beat structure of the created time signature?


Lukas

Re: TimeSignature with note in denominator

[Lukas-Fabian Moser]

Hi Carl,


Although the time signature looks like a fraction, it is not.  A fraction has numbers in the 
denominator and the numerator (and strictly speaking, a fraction properly has integers in the 
numerator and denominator -- if they are not integers, it's a quotient, not a fraction, IIUC).  And 
the time signature has an integer in the "numerator" and a duration in the 
"denominator".

I'm not sure it is worth the work to get semantically correct, but 
semantically, \time 4/4 should not be a fraction of two integers; it should be 
a pair of a count and a duration.


I think you are right that the notion of time signatures being 
represented by formal fractions ("formal" meaning that 4/4 is not 
identical to 2/2) is wrong and that one should talk about a count and a 
duration. But it's an error with a huge tradition, not just in LilyPond, 
but in talking about music in general. Everybody talks and writes of 
"3/4 time" (and some people even write their time signatures with a 
fraction line), and I'd be very surprised to hear someone say - very 
correctly, admittedly - "what time signature? Ah, right, three crotchets 
per bar". (I'm using the English names, because in the American and 
German nomenclature, the difference is much more subtle: "Three 
quarters" vs. "Three quarter notes".)


So, I very much think that LilyPond should continue to support formal 
fractions of positive integers for time signature declarations. But your 
argument provides additional incentive to also support time signature 
declarations of the form (index? ly:duration?) and more generally 
(index? ly:music?). Although it would be nice, from a user's 
perspective, to do both using just the one \time command, I still doubt 
that this would be feasible.



And if we had semantically correct time signature entry, Kieren's wish for a different display for 
the duration would be relatively straightforward, although we would potentially have an 
"isoduration" problem that is analogous to the "chord name semantics" problem 
-- there is no difference in duration between 4~4 and 2, so we couldn't preserve 4~4.  Similarly, 
we could not tell the difference between 8.~8 and 8~8., although I can't imagine how the difference 
between these two representations would be important; both represent a duration of 5 eighth-notes.


I think you mean 5 16ths? The difference might, for example, be in the 
beat structure. I could imagine differences like 16[ 16] 16[ 16 16] vs. 
16[ 16 16] 16[ 16], and also that beam subdivision might enter the 
scene: There should be a difference between \time \kieren 1 { 8.~8 } and 
\time \kieren 1 { 8. 8 } that I could imagine might just be 
"disconnected groups" vs. "two groups with a single connecting beam", etc.


Lukas

Re: TimeSignature with note in denominator

[Lukas-Fabian Moser]

Yes.  The numerical representation of traditional time signatures is a pair of integers.  But the 
"numerator" can be any integer.  While the "denominator" can also be any 
integer, it doesn't really represent an integer.  It represents a duration; a fraction of a whole 
note.


To make matters worse, there actually are composers who write something 
like "4/5 time". Thomas Adès would be an example.


Lukas

Re: TimeSignature with note in denominator

[Lukas-Fabian Moser]

Hi Kieren,

Am 14.11.21 um 15:00 schrieb Kieren MacMillan:

There just is no uniquely identified print form using a note in the
denominator for that time signature representation.

As I’ve explained several times, there is.


I don't think you're right.

It's well possible that I'm missing the point completely, but here's my 
take:


When Thomas Adès switches from 4/4 to 4/5, there is no way of knowing 
which "graphical" note length (combination of notehead style and flag 
count) is supposed to be used for the basic unit (of which 4 make up a 
bar, and of which five equal the duration of a semibreve).


In written scores, that's not a problem: You can just count in a printed 
bar to find out what X is in "four X's make up a bar", and in the Adès 
scores I have seen, it was usually X = crotchet. But there's no way of 
knowing that beforehand.


That problem always bugged me with this style of notation.

Lukas

Re: TimeSignature with note in denominator

[Lukas-Fabian Moser]

When Thomas Adès switches from 4/4 to 4/5, there is no way of knowing 
which "graphical" note length (combination of notehead style and flag 
count) is supposed to be used for the basic unit (of which 4 make up a 
bar, and of which five equal the duration of a semibreve).


Example:

\version "2.22"

\relative {
  \time 4/5
  c'4*4/5 c c c
  \time 4/5
  c'8*8/5 c c c
}

Which one of those bars is more natural than the other, and why?

If you're tempted to answer "the first one, since 1/5 is very close to 
1/4 and should therefore be represented by crotchets", then what about 
the following?


\version "2.22"

\relative {
  \time 4/6
  c'4*4/6 c c c
  \time 4/6
  c'8*8/6 c c c
}

(BTW, there's a "strange time signature" warning, but only for the 
second \time in each of the examples. This seems to be a bug.)


Lukas

Re: TimeSignature with note in denominator

[Lukas-Fabian Moser]

It's great that you show so much patience with rank beginners in
LilyPond.


Gentlemen, please.

It's obvious and well-known that few people know LilyPond's design and 
inner workings as well as David, so if he raises concerns about a design 
question, it's a pretty safe bet that there's a bona fide issue at hand. 
But it's also obvious that LilyPond can only benefit from motivated 
development newcomers, especially in this case where the "newcomer" is 
actually a veteran power-user who knows the strengths and current 
limitations of LilyPond very well.


So can we please try to avoid sarcasm and try to assume best intent on 
the respective other's side? Having met both of you, I am sure this 
assumption is actually quite reasonable.


Lukas

Re: TimeSignature with note in denominator

[Lukas-Fabian Moser]

So can we please try to avoid sarcasm and try to assume best intent on 
the respective other's side? Having met both of you, I am sure this 
assumption is actually quite reasonable.
Sorry for hitting the limits of my English language skills: I wanted to 
say that I'm sure that the assumption of good intent is actually correct.

Re: Fwd: Binaries of LilyPond 2.23.5 with Guile 2.2

[Lukas-Fabian Moser]

For a data point, about 1 Windows machine in 8
is running Windows these days.


... while the remaining 7 are not running.

(Sorry, not sure if the German pun works in English.)

Re: RFC: Adding syntax highlighting to the official documentation

[Lukas-Fabian Moser]

Hi Jean,


Feedback is appreciated.


For what it's worth: I like that design (only having looked at the 
style-test.zip file) a lot. It's unobtrusive, yet makes it easier to 
parse the structure of a code sample at first glance.


Of course, that doesn't help at all with the issues raised by John 
(about which I cannot provide any helpful insights).


Lukas

Re: balloonText and DoublePercentEngraver

[Lukas-Fabian Moser]

Hi Werner,

Am 21.12.21 um 23:07 schrieb Werner LEMBERG:

Please have a look at the following example.

```
\new Score \with {
   \consists "Balloon_engraver"
} \new Staff {
   \repeat "percent" 2 {
 e'4 e' e' e' |
 \balloonGrobText #'PercentRepeat #'(0 . 1) \markup "Repeat"
   }

   \repeat "percent" 2 {
 e'2 e' | e' e' |
 \balloonGrobText #'DoublePercentRepeat #'(0 . 1) \markup "DoubleRepeat"
   }
}
```

This shows a balloon help for `PercentRepeat` but not for
`DoublePercentRepeat`.  What am I doing wrong?


It seems that the correct time offset for the DoublePercentRepeat is at 
the beginning of the _second_ of the two bars.


This can be conventiently handled with \after - and also note that some 
of your # and ' and " characters are not necessary anymore:


\version "2.23"

\new Score \with {
  \consists "Balloon_engraver"
} \new Staff {
  \repeat percent 2 {
    e'4 e' e' e' |
    \balloonGrobText PercentRepeat #'(0 . 1) Repeat
  }

  \after 1*3 \balloonGrobText DoublePercentRepeat #'(0 . 1) DoubleRepeat
  \repeat percent 2 {
    e'2 e' | e' e' |
  }
}

(One might even write 0/1 instead of #'(0 . 1), but I admit that this is 
a nasty abuse of LilyPond's syntax conventions.)


Lukas

Re: balloonText and DoublePercentEngraver

[Lukas-Fabian Moser]

\new Score \with {
  \consists "Balloon_engraver"
}


Ah, sorry, I forgot one:

\new Score \with {
  \consists Balloon_engraver
}

Lukas

Re: balloonText and DoublePercentEngraver

[Lukas-Fabian Moser]

Hi Dan & Werner,

Am 22.12.21 um 15:41 schrieb Dan Eble:

```
{
   \override DoublePercentRepeat.slope = #.3
   \repeat percent 2 { e'2 e' e' e' }
   \revert DoublePercentRepeat.slope
}
```


I'd recommend using \temporary\override in to mimic \once behaviour more 
closely:


\version "2.23.5"

\layout {
  \override DoublePercentRepeat.slope = 2
}

{
  \repeat percent 2 { e'2 e' e' e' }
  \override DoublePercentRepeat.slope = #.3
  \repeat percent 2 { e'2 e' e' e' }
  \revert DoublePercentRepeat.slope
  \repeat percent 2 { e'2 e' e' e' }
}

{
  \repeat percent 2 { e'2 e' e' e' }
  \temporary\override DoublePercentRepeat.slope = #.3
  \repeat percent 2 { e'2 e' e' e' }
  \revert DoublePercentRepeat.slope
  \repeat percent 2 { e'2 e' e' e' }
}

Lukas

Re: CodaMark and friends not included in skyline

[Lukas-Fabian Moser]

Yes. This overrides the default after-line-breaking
callback, which causes trouble if that callback was
supposed to do something important. Harm's code was
written at a time where the grob-transformer was
not available. It's now possible to write this code
in a way that works for grobs with an after-line-breaking
callback. See the attached file. I've also modified
it so that the URL to the documentation is computed
from the version number of the LilyPond version that
runs the file, and not hardcoded.


That's great :-).

Little nit:

"https://lilypond.org/doc/v~a.~a/Documentation/notation/~a";

instead of

"https://lilypond.org/doc/v~a.~a/Documentation/notation/";

Lukas

Updating alists (was: Tenuto marking too close to note)

[Lukas-Fabian Moser]

Hi Jean, (CCing devel because of the stuff below the asterisks)

Although this approach manipulates internal data structures of 
LilyPond, it has the advantage of dealing with your issue at the root 
and not causing side effects for other scripts. Unfortunately, this 
approach does not work directly for the (still experimental) LilyPond 
builds using Guile2.


Be mindful that assoc-set! is not guaranteed to
mutate its input. You're not the first one tripped
up by this API quirk :-)


It's much worse than that: It's not the first time _I've_ been tripped 
up by this (previously it was with sort!). I'll just have to write 100 
copies of


"The exclamation mark in something! does not mean the function is 
guaranteed to make the desired change in-place."


on my wall.

But more seriously: Thanks! And also for advertising ice-9 match - it's 
really a different coding style from the more commonly seen (if pair? 
...) constructs.


* * *

Another question: With the (hopefully) upcoming changes in the 
script-alist structure (using symbols instead of strings as keys), we're 
quite close to being able to simply do


\version "2.23.6"

myScripts = \default-script-alist
myScripts.tenuto.padding = 5

\layout {
  \context {
    \Score
    scriptDefinitions = #myScripts
  }
}

{
  a--
}

(One might also skip defining a new variable and instead change 
default-script-alist directly, but it has to be re-read in a \layout 
block anyway.)


But at the moment, this does not work because the changed key is not 
being replaced in the alist but added at the beginning. If I see things 
correctly, this is the remark about "not coalescing multiple overrides 
of the same property" in nested_property_alist(...) in 
ily/nested-property.cc.


Re-enabling the outcommented branch in that function (taking care to use 
assoc_tail instead of assq_tail and correcting the order of arguments to 
that call) basically works, but there's trouble ahead in the case where 
one does


variable.entry = 15
variable.entry.first = #'i-ve-decided-i-want-a-sublist-after-all

which unfortunately is what happens if one \override's a nested property 
given by a callback (e.g. VerticalAxisGroup.staff-staff-spacing), or worse


variable.entry = #'(some . pair)
variable.entry.first = #'i-ve-decided-i-want-a-sublist-after-all

since an entry that is a pair looks like the beginning of a sublist.

On the other hand, I would expect people who are using

Violin.I = { \someMusic }
Violin.I = { \someNewMusic }

would indeed like to be their first definition to actually be replaced 
(even if using \Violin.I in a score happens to produce only the most 
recent entry).


Thoughts?

Lukas

Re: Updating alists

[Lukas-Fabian Moser]

\version "2.23.6"

myScripts = \default-script-alist
myScripts.tenuto.padding = 5

\layout {
   \context {
     \Score
     scriptDefinitions = #myScripts
   }
}

{
   a--
}

(One might also skip defining a new variable and instead change
default-script-alist directly, but it has to be re-read in a \layout
block anyway.)

But at the moment, this does not work because the changed key is not
being replaced in the alist but added at the beginning.

Why would that not work?

Because I tested it wrongly. Sorry for the noise.

I'm still unsure if the result of

violin.I = { a }
violin.I = { gis }

\void \displayScheme \violin

is "what it should be" (i.e. if one wouldn't rather expect the second 
assignment overwriting the first one), but I see that changing this has 
problematic implications.


Lukas

Re: point-and-click default

[Lukas-Fabian Moser]

Hi David,

I've been using Lilypond for a few years, and only yesterday learned
about the point-and-click feature in pdf output.  In particular, I had
no idea that by default Lilypond includes absolute pathnames to local
source files on my system as metadata in the pdf output files.  So when
I uploaded a couple of files to IMSLP recently, that metadata was
available for all to see.


The Notation Reference states 
(https://lilypond.org/doc/v2.23/Documentation/usage/configuring-the-system-for-point-and-click):


"Point and click functionality is enabled by default when creating PDF 
or SVG files."


"Note: You should always turn off point and click in any LilyPond files 
to be distributed to avoid including path information about your 
computer in the PDF file, which can pose a security risk."


I agree that these statements make for a gloomy combination by today's 
standards of increased awareness for computer security issues.


Wouldn't it be more reasonable to switch point-and-click off by default? 
My argument would be that in Frescobaldi, it's trivial to accommodate 
such a change, and non-Frescobaldi users who are able to set up a 
point-and-click-ready system of their own should also be perfectly able 
to make point-and-click the default on their system if they want to. 
Even more so since there's \pointAndClickOn, making it trivial to enable 
the feature for individual files without having to mess with command 
line parameters.


Lukas

Re: Updating alists (was: Tenuto marking too close to note)

[Lukas-Fabian Moser]

Hi Jean,



Both of these cases seem to work the same as in
current versions if I do

[...]

 SCM
 assq_tail (SCM key, SCM alist, SCM based_on = SCM_EOL)
 {
-  for (SCM p = alist; !scm_is_eq (p, based_on); p = scm_cdr (p))
+  for (SCM p = alist; scm_is_pair (p) && scm_is_pair (scm_car (p)) && 
!scm_is_eq (p, based_on); p = scm_cdr (p))

 {
   if (scm_is_eq (scm_caar (p), key))
 return p;


Thanks! This seems to be a sensible precaution anyway, as it only 
changes a certain crash into returning #f. So it might be sensible to 
make this change anyway?



But I really don't have deep enough an insight on this code
to judge, sorry.


I'm a bit surprised about the remark in the code stating that the choice 
not to coalesce multiple override's was made to save the cost of 
detecting them, as it does not seem to be a code path used heavily at all.


Lukas

Re: Centering bass figures on whole notes and longer (issue 325070043 by pkx1...@gmail.com)

[Lukas-Fabian Moser]

dak wrote
> I think it quite unusual to have a figure without a note.

Quite to the contrary: Both for voice-leading indications (e.g. quick
resolution of suspensions) and point d'orgue situations, it's very common to
have multiple figures to the same note. For example, see the last two bars
of the Introitus to Mozart's Requiem.

There might even be cases where there a figure is the first thing happening
in a bass line:

<<
  { r8 c16 d e8 e }
  \figures { <2 4 7>4 <6> }
>>

I don't know a "real" example of this kind off the top of my head, but it
would definitely be a meaningful continuo setting.

- Lukas



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Centering-bass-figures-on-whole-notes-and-longer-issue-325070043-by-pkx166h-gmail-com-tp204428p204668.html
Sent from the Dev mailing list archive at Nabble.com.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Terminology of baseMoment, beats, groups

[Lukas-Fabian Moser]

Am 11.11.2017 um 13:25 schrieb Simon Albrecht:

> On 11.11.2017 12:30, David Kastrup wrote:
>
>> I have a hard time seeing a "beat" as something that can have different
>> lengths.
>>
>
> Musical notation isn’t well-defined in a mathematical or programming
> sense, so there are no such strict rules as all beats of a measure having
> to be the same length.
> If nobody would refer to the last quarter note of 3+3+2/8 as “the third
> beat” then that’s because it would tend to be confusing.
>

I disagree. There are two different musical situations where this can
occur: 3+3+2 is a pretty common idiom of a three-part *rhythm* against a
2-part *metre*, and here it would in fact be confusing to refer to the "2"
as the third beat.
Other music may well treat this as beats in their own right, and then
everybody would talk about it as three "beats".


Maybe "beat" has too diverse a field of semantics depending on context and
style.

So would it be better not to talk about "beats" but, eg., a "pulse" which
then is subjected to grouping?

Lukas


It is probably clearer when shown with a less idiomatic example. Consider a
9/8 time signature with a 2,2,2,3 beatStructure. Here it is clear that
you'd refer to the groups as four "beats".

Urs



> Best, Simon
>


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: -dcrop not included in 2.20?

[Lukas-Fabian Moser]

>
> Not including it would be a pity. I am only one user and of course the
> developers know better why or why not they would accept this -dcrop change.
>
> But from a user’s perspective: this change is the only way (to my
> knowledge) to create vector graphics snippets for inclusion in other
> documents like the open document format (via ooolilypond) and html. So
> for me it is a big step forward for which I was waiting for years.
>

+1 here!

Best
Lukas
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Release schedule for 2.20

[Lukas-Fabian Moser]

But an increasing number of questions asked in forums or on the lists 
can be answered by “compile current master or wait for 2.21.0”. And a 
huge number of answers requires at least 2.19.xx but people 
understandably don’t want to install an “unstable” version.


IIUC, the situation used to be: i) Rare-to-very-rare stable releases for 
"normal" users, ii) frequent instable releases for those who wanted to 
use the latest features. This seems to have changed due to the 
preparations for the next stable release in that the instable releases 
stopped appearing as well for the time being. Since at the same time, 
development of new features goes on, people who want the latest features 
now have to compile for themselves.


(I, for example, just recently switched to self-compiled Lilypond 
because of Malte's amazing work on the \haydnTurn which was prompted by 
my question. To my surprise, compiling turned out to be quite easy, but 
of course there /were /some slight dependency issues, /and /I'm running 
on Linux which simplifies matters.)


Question: How difficult/costly/... would it be to prepare a "daily build 
from current master" for download? While this certainly would be 
overkill during times when there's a new unstable release every few 
weeks or so, it would I think, by way of contrast, highlight the status 
of the unstable releases more clearly: "The stable releases are 
rock-solid; the unstable releases usually work flawlessly but are 
subject to change; the daily build is something for the reckless and 
impatient." (Whereas now, the latter is the way people tend to think 
about the /unstable /releases which underestimates their quality.)


Best
Lukas
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Release schedule for 2.20

[Lukas-Fabian Moser]

Am 09.05.2018 um 17:23 schrieb Phil Holmes:

Question: How difficult/costly/... would it be to prepare a "daily
build from current master" for download?


Very.  We are talking about 6 hours of build time on a pretty solidly
powered 8-processor machine.  Actually, we _were_ talking about that
before adding the Catalan translation to the docs and further
complicating the Documentation build process in order to get more
compact PDFs.


On my GUB build machine (4 core hyperthreaded i7, 8 Gigs, SSD) an 
incremental build (i.e. with a stable version of GUB with the toolset 
all up to date) takes around one to one and a half hours. If GUB needs 
updating, it can, as you say, take over 6 hours even on that machine.  
The upload is then a few Gigs and on my old broadband this took around 
6 hours to upload. My shiny VDSL connection does it in about 5 
minutes.  So a complete GUB rebuild is feasible.  However, I'm not 
sure that was what was requested. A simple Linux binary in a specific 
location of Lilypond.org would be fairly straightforward - about 2 
minutes for the build and very quick upload.


I admit that I thought more of a binary package than of the full 
documentation (which I gather is very involved to build). A possible 
rationale might be that a power-user who wants to have access to the 
latest features is likely to get to know these features by watching the 
-user or -devel lists, issue trackers etc., so it's maybe not terribly 
important to have the very latest documentation. (But I know that this 
argument could be disputed, for instance regarding the Internals manual).


As for the choice of the platform: One could argue that, e.g., binaries 
for Windows etc. might be even more useful than Linux binaries (which 
are comparatively easy to compile for oneself).


So: What I thought of when I asked about the costs of a "daily build" 
would be something like: Binaries for as many platforms as possible, but 
without the documentation. If something like that would be reasonable at 
all.


Best
Lukas

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Extend Whiteout property

[Lukas-Fabian Moser]

Hi Kieren,


Well done. Does it also work with other whiteout styles (e.g., outline)?

Not yet. Of course, "rounded-box" would be nice to have (and probably 
not too hard to implement). I expect "outline" would be more involved; 
tbh, I'm not quite certain what the precise meaning would be for that 
style, anyway.


In any case, I haven't yet taken a look at how "outline" actually works.

Best
Lukas

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Non-quadratic form of whiteout

[Lukas-Fabian Moser]

Dear developers,

following a feature request on -user I tried my hand at implementing a 
feature enabling non-quadratic form for box-whiteouts.


As I never participated in developing before (and only rarely get down 
to coding these days), I'm pretty sure that what I did is substandard. 
Urs Liska was kind enough to point me to the LilyPond repository on 
GitHub (and comment on some aspects of my changes), but I unterstand 
that is not really the right place.


So I just post a patch here in case anyone would be interested in 
helping me bring my small contribution up to scratch.


Basically it adds to the 'whiteout property - which, at the moment, can 
either be a boolean or a number indicating the dimension of a quadratic 
whiteout box - a third possibility, namely a number pair giving x- and 
y-dimension separately. For instance:


\version "2.21"

\new Staff {
  \override NoteHead.whiteout = #'(5 . 40)   % Pair of X-thickness and 
Y-thickness

  g'4
  r2
  \override NoteHead.whiteout = #'(40 . 5)
  g'4
}

Best
Lukas

>From c8f83ad9d480bd8c6ba4ed45c8e167ed32bc52b9 Mon Sep 17 00:00:00 2001
From: Lukas-Fabian Moser 
Date: Thu, 13 Sep 2018 23:41:33 +0200
Subject: [PATCH] Non-quadratic whiteouts

---
 lily/grob.cc   |  1 +
 scm/c++.scm|  3 +++
 scm/define-grob-properties.scm | 20 +++-
 scm/stencil.scm| 30 ++
 4 files changed, 33 insertions(+), 21 deletions(-)

diff --git a/lily/grob.cc b/lily/grob.cc
index fddef87..24494be 100644
--- a/lily/grob.cc
+++ b/lily/grob.cc
@@ -147,6 +147,7 @@ Grob::get_print_stencil () const
   /* A grob has to be visible, otherwise the whiteout property has no effect. */
   /* Calls the scheme procedure stencil-whiteout in scm/stencils.scm */
   if (!transparent && (scm_is_number (get_property ("whiteout"))
+   || is_number_pair (get_property ("whiteout"))
|| to_boolean (get_property ("whiteout"
 {
   Real line_thickness = layout ()->get_dimension (ly_symbol2scm ("line-thickness"));
diff --git a/scm/c++.scm b/scm/c++.scm
index cd2806f..4b2f555 100644
--- a/scm/c++.scm
+++ b/scm/c++.scm
@@ -57,6 +57,9 @@
 (define-public (boolean-or-number? x)
   (or (boolean? x) (number? x)))
 
+(define-public (boolean-or-number-or-number-pair? x)
+ (or (boolean? x) (number? x) (number-pair? x)))
+
 (define-public (boolean-or-symbol? x)
   (or (boolean? x) (symbol? x)))
 
diff --git a/scm/define-grob-properties.scm b/scm/define-grob-properties.scm
index f6952d9..a95cafd 100644
--- a/scm/define-grob-properties.scm
+++ b/scm/define-grob-properties.scm
@@ -1168,15 +1168,17 @@ one below this grob.")
 ;;; w
 ;;;
  (when ,ly:moment? "Global time step associated with this column.")
- (whiteout ,boolean-or-number? "If a number or true, the grob is
-printed over a white background to white-out underlying material, if
-the grob is visible.  A number indicates how far the white background
-extends beyond the bounding box of the grob as a multiple of the
-staff-line thickness.  The @code{LyricHyphen} grob uses a special
-implementation of whiteout:  A positive number indicates how far the
-white background extends beyond the bounding box in multiples of
-@code{line-thickness}.  The shape of the background is determined by
-@code{whiteout-style}.  Usually @code{#f} by default. ")
+ (whiteout ,boolean-or-number-or-number-pair? "If a number,
+number-pair or true, the grob is printed over a white background to
+white-out underlying material, if the grob is visible.  A number
+indicates how far the white background extends beyond the bounding 
+box of the grob as a multiple of the staff-line thickness.  A number
+pair is interpreted as giving X- and Y-extent separately.  The
+@code{LyricHyphen} grob uses a special implementation of whiteout:  
+A positive number indicates how far the white background extends
+beyond the bounding box in multiples of @code{line-thickness}.  
+The shape of the background is determined by @code{whiteout-style}.  
+Usually @code{#f} by default. ")
  (whiteout-style ,symbol? "Determines the shape of the
 @code{whiteout} background.  Available are @code{'outline},
 @code{'rounded-box}, and the default @code{'box}.  There is one
diff --git a/scm/stencil.scm b/scm/stencil.scm
index cc61a13..dcee256 100644
--- a/scm/stencil.scm
+++ b/scm/stencil.scm
@@ -782,13 +782,13 @@ of the white stencil we make between 0 and 2*pi."
 stil)
 
 (define*-public (stencil-whiteout-box stil
- #:optional (thickness 0) (blot 0) (color white))
-  "@var{thickness} is how far, as a multiple of line-thickness,
-the white outline extends past the extents of stencil @var{stil}."
+ #:optional (thickness '(0

Re: Non-quadratic form of whiteout

[Lukas-Fabian Moser]

Addendum: Of course, "quadratic" is not the right word. What I mean by 
it is that the horizontal and vertical protrusions of the whiteout box 
around the actual rectangular hull of the object are equal. For, e.g., 
noteheads, this /does /lead to an (almost) quadratic shape.



Am 13.09.2018 um 23:52 schrieb Lukas-Fabian Moser:

Dear developers,

following a feature request on -user I tried my hand at implementing a 
feature enabling non-quadratic form for box-whiteouts.


As I never participated in developing before (and only rarely get down 
to coding these days), I'm pretty sure that what I did is substandard. 
Urs Liska was kind enough to point me to the LilyPond repository on 
GitHub (and comment on some aspects of my changes), but I unterstand 
that is not really the right place.


So I just post a patch here in case anyone would be interested in 
helping me bring my small contribution up to scratch.


Basically it adds to the 'whiteout property - which, at the moment, 
can either be a boolean or a number indicating the dimension of a 
quadratic whiteout box - a third possibility, namely a number pair 
giving x- and y-dimension separately. For instance:


\version "2.21"

\new Staff {
  \override NoteHead.whiteout = #'(5 . 40)   % Pair of X-thickness and 
Y-thickness

  g'4
  r2
  \override NoteHead.whiteout = #'(40 . 5)
  g'4
}

Best
Lukas



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Non-quadratic form of whiteout

[Lukas-Fabian Moser]

Hi Harm,

thanks much for the ideas and pointers to old discussions!

So my first suggestion would be to drop the boolean argument for 'whiteout.
> Instead let the user decide. Providing a number shouldn't be too hard.
> Dropping the boolean was already disussed here:
> https://codereview.appspot.com/236480043/#msg15
> Though, I don't see much arguments. otoh it's not unlikely I don't
> understand the argument(s) ;)
> A disadvantage would be the neeed to code some convert-rule (which is
> beyond my coding-capabilities).
>

I didn't do this because I didn't want to break existing scores. To me,
removing the boolean variant which provides default values seems like
killing a feature and not gaining much for it. Your statement sounds as if
you dislike the clumsyness of "boolean or number or even something else"?


> Quite often users (including myself) want to customize the
> whiteout-amount even more than currently possible.
> So my second suggestion is to make whiteout accepting a number-or-pair.
> A number would do what's already done with it.
> A simple pair like '(1 . 2) would extent the whiteout-amount for
> x-y-axis differently.
>

This is exactly what I implemented (tried to implement).


> A pair-list like '((1 . 2)(3 . 4)) would extent the whiteout-amount in
> x-axis with the values of the first pair, in y-axis with the values of
> the second pair.
>

Good idea! But wouldn't it be cleaner to use a pair of pairs instead of a
list of pairs?


> Providing a pair or a pair-list will not work for 'outline ofcourse, I
> don't have a good thought how to deal with this style, though.
> Probably printing a message and/or providing some default, which may
> be zero.
>

This already opened a discussion which, I think, goes in an orthogonal
direction - it already showed that 'outline whiteouts are a quinte
different beast from boxes.
@Kieren et al.: Is there really a use-case for 'outline whiteout with
changing thickness dependent on the angle? (But of course I agree that
there are cases where even the 'outline technique we have now produces
less-than-optimal results, as can already be seen in the discussions Harm
pointed us to.)

Best
Lukas
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: New feature: automatically invert chords or drop/rise chord notes (issue 365840043 by v.villen...@gmail.com)

[Lukas-Fabian Moser]

like when using invertChords on a c:11 chord for the fifth inversion.


Oh.  Then this becomes a whole other can of worms; what should be the
correct inversion of an 11th chord?

Should

become
 (as you seem to suggest)
or
 (as the current code produces)?


If I understand correctly, the same problem already arises with c:9, 
that is, as soon as the given chord voicing spans more than an octave.


But the problem is much more general: "inversion", when only applied to 
chords given as stacks of thirds, is as artificial a concept as the 
stacks-of-thirds themselves, for as you know, real chords (sets of 
pitches) have an arbitrary distribution of their pitch classes to actual 
pitches, including doublings of pitch classes (maybe even doublings of 
actual pitches).


You might argue that this is not about real chords but about "idealized" 
chord representations, but then it's not at all obvious *what* the 
precise class of chord representations should be that a chord-inversion 
function should operate on. ({Stacks-of-thirds}, {chords with range < 1 
octave} etc. all do not work.)


Tbh, I'm not quite sure what the useful applications of a function 
\invertChord might be, anyway, but I would expect that the two obvious 
interpretations:


a) raising the lowest sounding pitch by one or more octaves in order to 
become the new highest sounding pitch,

b) raising the lowest sounding pitch by exactly one octave

both might be sensible and should be supported - ideally using two 
different functions (e.g. \invertChord, \invertChordII). (And this still 
does not take into account the possibility  of  which is a 
perfectly valid chord e.g. in a 3-part setting in homophonic notation.)


(Ceterum censeo: The whole concept of chord positions arising by 
"inverting" a chord is not as useful as it is widespread, anyway, 
because it leads to the frequent mis-conception that different chord 
positions can't have the same upper voice. In my theory classes, chord 
positions are always written either in a two-staff-piano system with a 
clearly distinguished bass note, or in an abstract reduction "all pitch 
classes mapped into the octave above the bass pitch" - for want of a 
better term, I call it "compact voicing" with the convention that it 
always be written in bass clef - that lends itself easily to being 
encoded as bass figures[1]. And of course the same philippika might be 
repeated from the point of view of melody notes instead of bass notes...)


Best
Lukas

[1] With the exception of bass figures > 8, of which only "9" is used 
regularly.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: New feature: automatically invert chords or drop/rise chord notes (issue 365840043 by v.villen...@gmail.com)

[Lukas-Fabian Moser]

much like a suspended chord (the whole point of `drop n’ transformations
being to change the bass note).


This statement surprises me. I always thought of 'drop n' (with 'drop 2' 
being the most common one) as a means to transform closed-harmony 
_upper_ voices into open harmony _upper_ voices, without changing the 
bass at all. (Which is consistent with the notion that the 
differentiation between closed vs. open harmony only is concerned with 
the upper voices, so  is a closed harmony voicing with 
drop-2 variant .)


But it might be that it's just different stylistic 'homelands' showing 
up here, in my case, a mostly classical basso continuo-background.


Lukas


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: New feature: automatically invert chords or drop/rise chord notes (issue 365840043 by v.villen...@gmail.com)

[Lukas-Fabian Moser]

This statement surprises me. I always thought of 'drop n' (with 'drop 2'
being the most common one) as a means to transform closed-harmony
_upper_ voices into open harmony _upper_ voices, without changing the
bass at all.

[...]

Much like continued bass, what we’re dealing with here is the "right
hand" positions, which most certainly does not affect the bass line,
except in jazz music it will typically be played by the _left_ hand
(or with both hands) whilst the actual bass line (often heavily
anchored in root notes, much more so than in baroque music) is left to
the bass player. In this regard, what I referred to as "changing the
bass note" would actually be better phrased as "changing the lowest
note played by the guy in charge of chords, regardless of what the
global bass note will be". At least, that’s my understanding of how
jazz music is conceptualized, which YMMV with.


Yep, I think we can absolutely agree on that. (This reminds me of the 
famous virtual sing-post that some teachers like to attach to everything 
below c on the piano: "Keep off here - there's a bass player around!") I 
just wanted to point out that IMO it's not helpful to call the lowest 
sounding pitch played by one specific non-bass instrument (i.e. the 
piano) the "bass" note.



BTW, there’s no proper notion of inversions as such in jazz music
(AFAICT); so the purpose of an \invertChords function here is left to
our appreciation, with the minimal requirement being that the lowest
note of the chord changes each time -- but traditionally, I think the
lowest note of the previous inversion *should* become the highest note
of the next inversion (and reciprocally when proceeding in reverse).
If that means moving said note by two octaves instead of just one,
then so be it (IMO).


Agreed - I just might add that, IMHO, as I tried to point out, the 
concept of chord positions arising "by inversion" is not that helpful in 
a classical context, either.


By this, I do not mean that a 6-chord shouldn't be derived from a 
root-position chord containing the same pitch classes (even if that 
notion came up comparatively late in the history of music theory - 
probably as late as Rameau). Rather, even if one considers  
as being derived from an abstract c major chord, which of course is 
absolutely adequate in most situations[1] at least for everything from 
Baroque and later ages, I do not think that one should think of it as 
having arisen from some actual chord voicing by a procedure like 
"inversion".


Lukas

[1] More specifically, situations where chords do not arise by 
contrapuntal voice-leading patterns.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Lukas-Fabian Moser]

Hi everybody,

For more than 10 years gub/specs/lilypond.py used /usr/bin/python. 
That means that during lilypond-test the system's python interpreter 
is used as the interpreter for the musicxml2ly script, not our own 
python in target/tools.  At some currently unknown point in time 
musicxml2ly became incompatible to our python 2.4. The hidden usage of 
the system's python masked that incompatibility.


With our python 2.4 musicxml2ly does not barf, it simply produces 
garbage that lateron causes lilypond to fail.


@Werner: Didn't you write something about updating python in gub?


I assume you're referring to the situation that (e.g.) 2.19.82's 
musicxml2ly chokes with an error message regarding UTF-8 and producing 
ly files containing garbage bytes in each literal string.


On my system, your description matches: Current Master's musicxml2ly 
python script runs fine using my local python2 (2.7.15rc1) but has the 
error using 2.19.82's python2.4 (2.4.5).


--

5e44fec38f33997109bc85c099472b2736649fde is the first bad commit
commit 5e44fec38f33997109bc85c099472b2736649fde
Author: Frederic Gohier 
Date:   Thu May 10 11:12:44 2018 +0100

    Fix crash when using musicxml2ly

    Issue 5317
    Crash when running musicxml2ly

:04 04 32b11d27366ff7d629f2b6ca4d250a08293d6ece 
750f9ccdbec7fa68babf3f4414aecb70f57c812b M    python


--

So this might be the "currently unknown point in time"?

Best
Lukas


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Lukas-Fabian Moser]

Hi,


-- 



5e44fec38f33997109bc85c099472b2736649fde is the first bad commit
commit 5e44fec38f33997109bc85c099472b2736649fde
Author: Frederic Gohier 
Date:   Thu May 10 11:12:44 2018 +0100

    Fix crash when using musicxml2ly

    Issue 5317
    Crash when running musicxml2ly

:04 04 32b11d27366ff7d629f2b6ca4d250a08293d6ece 
750f9ccdbec7fa68babf3f4414aecb70f57c812b M    python


-- 



So this might be the "currently unknown point in time"?


... I'm sorry, but this does not seem to be correct. It seems Frederic's 
commit fixed a crash that made the UTF-8 problem visible because one 
could not get to that point before.


So it seems one has to apply Frederic's change to older revisions as 
well in order to be able to bisect the UTF-8 problem. Is this possible 
with git?


Lukas


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Lukas-Fabian Moser]

For more than 10 years gub/specs/lilypond.py used /usr/bin/python. 
That means that during lilypond-test the system's python interpreter 
is used as the interpreter for the musicxml2ly script, not our own 
python in target/tools.  At some currently unknown point in time 
musicxml2ly became incompatible to our python 2.4. The hidden usage 
of the system's python masked that incompatibility.


With our python 2.4 musicxml2ly does not barf, it simply produces 
garbage that lateron causes lilypond to fail.


The error was introduced when John Gourlay copied changes made by 
Philomelos into the LilyPond git tree in commits


2ab5d80245dcab194daea64ec83ded3ec8252e51
dc90b895668826a09e06ad1ef94e5e90569a870c
da6591bef1cd9c684a9fb98f1563ea40c543ecdd

in February 2016. Since these changes were copied as a bunch, one would 
probably have to delve into Philomelos's git tree or analyze the source 
directly.


If you folks think it would be worth the effort, I could try to do this.

Lukas


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test gub

[Lukas-Fabian Moser]

On my system, your description matches: Current Master's musicxml2ly
python script runs fine using my local python2 (2.7.15rc1) but has
the error using 2.19.82's python2.4 (2.4.5).

Given that nobody is really working on musicxml2ly, I strongly suggest
that people start testing and using Jacques Menu's `xml2ly' program
instead:

   https://github.com/grame-cncm/libmusicxml/tree/lilypond

(i.e., the `lilypond' branch of the `libmusicxml' git repository).

AFAIK, the results are far superior to the `musicxml2ly' script.

Well, the situation is that (at least with currently shipped 2.19.82) 
there is a tool called musicxml2ly (which is also explicitly supported 
in Frescobaldi, so people might expect it to work) but which fails on 
execution.


I'm not well acquainted with the situation for 2.20 (e.g. which Python 
version might be shipped with it), but it seems to me that to have a 
well-documented tool shipped with LilyPond might be a show-stopper for a 
stable release.


I'm not sure I see the situation correctly, but the only ways forward I 
see would be to


1) make musicxml2ly work again (by changing the Python version used, or 
by fixing the problems with 2.4), or

2) remove musicxml2ly from the distribution bundle, possibly
2a) without replacement,
2b) replaced by xml2ly

Even if 2b) is the most attractive route in the long term, as you 
suggest, it seems to me that only 2a) and maybe 1) can be expected to 
happen soon enough for a stable release of 2.20. And I'm not sure 
whether 2a) would be a good idea.


I'm willing to try and help, but I'm not at all convinced that my very 
limited coding skills can be of much use here.


Lukas


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Strange space between beam and slur

[Lukas-Fabian Moser]

Folks,

while engraving a Bach chorale, I stumbled over an overlarge space 
between a slur and a beam. After a happy hour of trying to boil the 
problem down to a minimal example, I arrived at:


\version "2.19.39"

\new Staff
<<
  {
    R1
    a''8( b'' b'' a'')
  } \\ {
    r4
  }
>>

This leads to the attached image.

The bug (I venture to call it such) first appeared in 2.19.39. (I 
couldn't do a true bisect on the git repository because for older 
versions, "make"ing LilyPond aborted with complaints about illegal 
casts, so I resorted to manually bisecting through the unstable releases 
- another happy half an hour :-).)


Finally, bisecting between release/2.19.38-1 and release/2.19.39-1 yields:


87eb2f9fe1be3a532675fe4b7322bbba5a60ba5c is the first bad commit
commit 87eb2f9fe1be3a532675fe4b7322bbba5a60ba5c
Author: Carl Sorensen 
Date:   Sat Mar 5 21:30:46 2016 -0700

    Use a negative value of overdone_noteheads to shrink the head slightly

:04 04 3cfab39db244953418b511ac3804bc4a3f7e1450 
224010f6fcca97776b8f38c5e33ed1c32be9e8f4 M    input
:04 04 86018b9a41eb153e364f218eb9c2e9693c142d24 
9a7a328516784fe2aefadcbcf344e10af1aefff0 M    mf


That's about as much as I can contribute, I guess. Does anybody have an 
idea what precisely is causing the problem?


Best
Lukas

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Strange space between beam and slur

[Lukas-Fabian Moser]

Hi Carl,

thanks for trying this (and forgive me for explicitly CC'ng you as the 
author of the commit that, on my system, triggered the problem)!



On 6/22/19, 3:48 PM, "Lukas-Fabian Moser"  wrote:

  
 That's about as much as I can contribute, I guess. Does anybody have an
 idea what precisely is causing the problem?

Hmm, this works for me on 2.19.82 running on OSX under Frescobaldi.  No extra 
space.

What is your system configuration?


Now that's strange. The error can be reproduced on LilyBin, so it's not 
my system (or an installation problem) only, but your experience seems 
to point to a OS dependent issue.


My system runs

Linux Aquarium 4.15.0-52-generic #56-Ubuntu SMP Tue Jun 4 22:49:08 UTC 
2019 x86_64 x86_64 x86_64 GNU/Linux


on Mint 19.1 (MATE 1.20.1) and the error occurs using both the 64 bit 
and (just tried) the 32 bit executables.


Should I provide more information?

Best
Lukas


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Strange space between beam and slur

[Lukas-Fabian Moser]

Hi Andrew,

Am 25.06.19 um 10:56 schrieb Andrew Bernard:
What is it about 19? Is it some magic borderline number in some unit 
system in lilypond? Do we know?


I'd rather suspect there's some kind of "anthropic principle" at work 
here: The bugs (at least the one I reported) should probably occur for 
any staff size in some (staff-size-dependent) situations, but we notice 
them with staff sizes that are used in real-world situations, hence our 
MWEs expose _those_ cases. But of course I lilypond-user Mailinglist 
might be wrong, especially for the 
misplaced-note-head problem which occurs for quite a generic situation.


Anyway: The misplaced-note-head bug 
(https://sourceforge.net/p/testlilyissues/issues/5303/) first appeared 
in 2.19.16 (I just found out that it's convenient as well as quite easy 
to keep arbitrarily many LilyPond versions installed on the same account).


@gcc experts (hence posting to devel also): Unfortunately, I cannot 
build 2.19.15 on my machine because of errors of the type:


/home/lukas/git/lilypond/lily/include/smobs.tcc:98:25: error: invalid 
conversion from 'int' to 'scm_unused_struct* (*)(SCM, SCM) {aka 
scm_unused_struct* (*)(scm_unused_struct*, scm_unused_struct*)}' 
[-fpermissive]

 scm_set_smob_equalp (smob_tag_, Super::equal_p);

I suspect that this is a case of some conversions having become illegal 
for later versions of gcc. Is there a cheap way to make the build 
succeed in order to be able to bisect for the misplaced-note-head bug?


Best
Lukas


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Strange space between beam and slur

[Lukas-Fabian Moser]

Hi David,

> @gcc experts (hence posting to devel also): Unfortunately, I cannot
> > build 2.19.15 on my machine because of errors of the type:
> >
> > /home/lukas/git/lilypond/lily/include/smobs.tcc:98:25: error: invalid
> > conversion from 'int' to 'scm_unused_struct* (*)(SCM, SCM) {aka
> > scm_unused_struct* (*)(scm_unused_struct*, scm_unused_struct*)}'
> > [-fpermissive]
> >  scm_set_smob_equalp (smob_tag_, Super::equal_p);
> >
> > I suspect that this is a case of some conversions having become
> > illegal for later versions of gcc. Is there a cheap way to make the
> > build succeed in order to be able to bisect for the
> > misplaced-note-head bug?
>
> I think I used a few cherry-picks commits for building.  Embarrassingly,
> it doesn't appear like I have them in a branch.  They were a few C++
> commits, a few Texinfo ones, some stuff related to freetype.
>
My knowledge about the interal workings and building procedures is so close
to nil that I don't even understand the relation of your answer to my
question. I'm really sorry since I expect that this is entirely my fault!

Anyway, I now succeded in compiling 2.19.15  by downgrading to GCC 5.5.0
(GCC 4.8.5 didn't pass autogen.sh, and GCC 6.5.0 aborted during compilation
just like my "usual" GCC 7.4.0).

The misplaced-note-head bug (as exposed in the MWE in
https://sourceforge.net/p/testlilyissues/issues/5303/) first appears with:

commit cb6024decee0aafd84baafe34115fc1b2d179df6
Author: David Kastrup 
Date:   Thu Nov 13 21:13:12 2014 +0100

Issue 216: ability to change staff line spacing inside a \layout{} block

This uses the staff-space setting from the \layout block (if set) for
determining staff spacing.

It apparently does not help with horizontal spacing, though.

:04 04 d7f8491fd6749961632b4d85c8b9ab7e0db2bd9f
ba74f06021e49cec6b6702071edc245a0beb70bf Mlily

Best
Lukas
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

misplaced-note-head bug (issue 5303)

[Lukas-Fabian Moser]

Folks,

I think I isolated the rounding (?) issue leading to the misplaced note 
head in https://sourceforge.net/p/testlilyissues/issues/5303/


Please forgive the horrible C/C++ jumble - it's been quite long since I 
did this kind of stuff and usually only ever wrote vanilla C:


#include 

double a = -0x1.7p+1;

int main(void) {
  printf("%a, as float: %f, as int: %d\n", a, a, int (a));
}

Compiled with gcc (4.8.5, 5.5.0, 6.5.0, 7.4.0 on my x86_64) this displays:

-0x1.7p+1, as float: -3.00, as int: -2

I'm not familiar with technicalities involved and thought I'd ask here 
because I'm sure somebody here (David K.?) will be able to explain 
what's happening here much faster than I could ever hope by reading up 
on float representations, rounding issues, etc.


Best
Lukas

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: misplaced-note-head bug (issue 5303)

[Lukas-Fabian Moser]

Folks,


I think I isolated the rounding (?) issue leading to the misplaced 
note head in https://sourceforge.net/p/testlilyissues/issues/5303/


Please forgive the horrible C/C++ jumble - it's been quite long since 
I did this kind of stuff and usually only ever wrote vanilla C:


#include 

double a = -0x1.7p+1;

int main(void) {
  printf("%a, as float: %f, as int: %d\n", a, a, int (a));
}


Aah, I'm sorry - I was not aware that casting to int works by 
/truncating/. Then it's quite obvious what's happening here.


Lukas

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: misplaced-note-head bug (issue 5303)

[Lukas-Fabian Moser]

Hi David,


Aah, I'm sorry - I was not aware that casting to int works by
/truncating/. Then it's quite obvious what's happening here.

Which code do you think has a problem related to your example?


Compile

\version "2.19" \score {   {     4 \clef bass    }   
\layout {     #(layout-set-staff-size 19)     % different magic number 
with layout-set-absolute-staff-size:     % 
#(layout-set-absolute-staff-size 6.011034)   } }


with a LilyPond patched with

diff --git a/lily/stem.cc b/lily/stem.cc index 37aa40c250..57995d8af7 
100644 --- a/lily/stem.cc +++ b/lily/stem.cc @@ -627,6 +627,7 @@ 
Stem::calc_positioning_done (SCM smob)  parity = true;    
lastpos = int (p); +  message (_f ("In Stem::calc_positioning_done: 
lastpos = int (p) truncates %f to %f", p, lastpos));  }    return 
SCM_BOOL_T;


against current master (or in fact any LilyPond version starting from 
your commit cb6024decee0aafd84baafe34115fc1b2d179df6 implementing 
changing the staff line spacing in the \layout block). This exhibits 
issue 5303 (see attached image) and shows where the int () cast causes 
the problem:


Processing `/home/lukas/Musik/lp/Misplaced_note_head_MWE.ly'

Parsing...

Interpreting music...

Preprocessing graphical objects...

In Stem::calc_positioning_done: lastpos = int (p) truncates -3.00 to 
-2.00


In Stem::calc_positioning_done: lastpos = int (p) truncates -1.00 to 
-1.00


In Stem::calc_positioning_done: lastpos = int (p) truncates -3.00 to 
-2.00


In Stem::calc_positioning_done: lastpos = int (p) truncates -1.00 to 
-1.00


Finding the ideal number of pages...

Fitting music on 1 page...

Drawing systems...

Layout output to `/tmp/lilypond-lXcH6C'...

Converting to `Misplaced_note_head_MWE.pdf'...

Deleting `/tmp/lilypond-lXcH6C'...

Success: compilation successfully completed

I'm not sure why the reduction to an integer is done in the first place. 
For the MWE, both keeping it as a float


lastpos = p;

and explicitly rounding 'correctly' to an integer

lastpos = int (round (p) );

solve the problem. I expect one should run both versions through a 
comparison of regression tests, but I never did this before, so I'd 
better leave this for tomorrow. :-)


Best Lukas

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: misplaced-note-head bug (issue 5303)

[Lukas-Fabian Moser]

Folks,

only now was I able to do regression tests regarding my proposed fix(es) 
of the misplaced-note-head-bug (issue 5303):


The bug is caused by the integer-cast

lastpos = int (p);

in lily/stem.cc:629.

Replacing it by either
i) lastpos = p; // use float value
or
ii) lastpos = int (round (p)) // correctly round to integer

resolves the bug. Neither variant introduces regressions (differences 
only in in test-output-distance and rest-dot-position, the latter being, 
I think, unrelated - the seemingly random position changes of dots to 
multi-voice simultaneous rests).


Questions:

a) How to decide which fix is "better"? (My guess that using floats 
might pose the danger of rounding errors adding up until something bad 
happens - probably only for huge chords comprising hundreds of notes, 
but I'd tend to favor the solution with rounding.)


b) Would anybody be willing to shepherd a patch through the review process?

c) Does the situation warrant inclusion of a new regression test? (The 
example in the bug report on 
https://sourceforge.net/p/testlilyissues/issues/5303/ would be suitable 
I think.)


Best
Lukas


diff --git a/lily/stem.cc b/lily/stem.cc
index 37aa40c250..2a0f6fef84 100644
--- a/lily/stem.cc
+++ b/lily/stem.cc
@@ -626,7 +626,7 @@ Stem::calc_positioning_done (SCM smob)
   else
 parity = true;
 
-  lastpos = int (p);
+  lastpos = p;
 }
 
   return SCM_BOOL_T;
diff --git a/lily/stem.cc b/lily/stem.cc
index 37aa40c250..34bf557fca 100644
--- a/lily/stem.cc
+++ b/lily/stem.cc
@@ -626,7 +626,7 @@ Stem::calc_positioning_done (SCM smob)
   else
 parity = true;
 
-  lastpos = int (p);
+  lastpos = int (round (p));
 }
 
   return SCM_BOOL_T;
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: misplaced-note-head bug (issue 5303)

[Lukas-Fabian Moser]

Hi James,


a) How to decide which fix is "better"? (My guess that using floats
might pose the danger of rounding errors adding up until something bad
happens - probably only for huge chords comprising hundreds of notes,
but I'd tend to favor the solution with rounding.)

That question is above my pay-grade


I went with my "feeling" described earlier now, heartened by the 
regtests showing no problems that I could spot.



b) Would anybody be willing to shepherd a patch through the review process?

Sure I can do that for you. 'Git format-patch master' if you would be so kind? 
:)

Thanks much! See attached.

c) Does the situation warrant inclusion of a new regression test? (The
example in the bug report on
https://sourceforge.net/p/testlilyissues/issues/5303/ would be suitable
I think.)

Put one in - it's easier to ask for forgiveness than permission right?


I'm sorry - I didn't realize that this can be done by just adding a file 
to input/regression. Done now.


Lukas

>From 36f2d4e768c1a14c668ab5d132099969796cc5fb Mon Sep 17 00:00:00 2001
From: Lukas-Fabian Moser 
Date: Thu, 4 Jul 2019 16:18:50 +0200
Subject: [PATCH] In loop calculating the attachments of chord node heads to
 stem, calculate last used position by _rounding_ to int rather than by
 truncating to int. This fixes issue 5303 (misplaced note head bug).

Also add regression test.
---
 input/regression/misplaced-note-head-bug.ly | 15 +++
 lily/stem.cc|  2 +-
 2 files changed, 16 insertions(+), 1 deletion(-)
 create mode 100644 input/regression/misplaced-note-head-bug.ly

diff --git a/input/regression/misplaced-note-head-bug.ly b/input/regression/misplaced-note-head-bug.ly
new file mode 100644
index 00..2a645f2a57
--- /dev/null
+++ b/input/regression/misplaced-note-head-bug.ly
@@ -0,0 +1,15 @@
+\version "2.19.16"
+
+\header {
+
+  texidoc = "Misplaced note head bug (issue 5303) should be fixed."
+
+}
+
+\layout {
+  #(layout-set-staff-size 19)
+}
+
+
+{ 2 \clef bass  }
+
diff --git a/lily/stem.cc b/lily/stem.cc
index 37aa40c250..34bf557fca 100644
--- a/lily/stem.cc
+++ b/lily/stem.cc
@@ -626,7 +626,7 @@ Stem::calc_positioning_done (SCM smob)
   else
 parity = true;
 
-  lastpos = int (p);
+  lastpos = int (round (p));
 }
 
   return SCM_BOOL_T;
-- 
2.17.1

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel