lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: incomplete tuplets in non-standard time signatures


From: Lukas-Fabian Moser
Subject: Re: incomplete tuplets in non-standard time signatures
Date: Mon, 30 Nov 2020 08:29:57 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

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 <lilypond@maltemeyn.de>
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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]