[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tuplet bracket visibility seems to break something
From: |
Paul Hodges |
Subject: |
Re: Tuplet bracket visibility seems to break something |
Date: |
Thu, 2 Sep 2021 11:41:37 +0100 |
User-agent: |
eM_Client/8.2.1473.0 |
Thanks - that sorts out a lot (and exposes another issue I'll write
about separately!).
In my many decades of programming I always had reservations about
"syntactic sugar" - different ways of expressing the same thing. When
the alternatives do not have the same behaviour at all times, they can
be positively misleading. In this case, || appeared to work for some
things, but then broke when something else happened; similarly the other
week I reported an issue with some parameters which mostly worked with
either # or \ introducing them, but one parameter value didn't. In this
case, as it happens, I do normally use \\ correctly, but I had a senior
moment this week and held the shift down when I shouldn't have.
Paul
On 02/09/2021 10:05:31, "Leo Correia de Verdier"
<leo.correia.de.verdier@gmail.com> wrote:
>The reason for it breaking is that in the code you posted there are vertical
>lines ” || " instead of backslashes ” \\ ” separating the voices.
>
>The bracket issue is that the override needs to go in a context where the
>tuples sees it. By default it goes into the Voice context here, and the << …
>\\ … \\ … >> creates new voices that are unaffected by the override. You need
>either write
>\override Staff.TupletBracket.bracket-visibility = ##t
>where it is now to override at staff level or to place the override in the
>voice it is supposed to affect.
>
>HTH
>/Leo
>
>> 2 sep. 2021 kl. 00:38 skrev Paul Hodges <pwh@cassland.org>:
>>
>> In the following code, the first expression does more or less what I
>> want; but I also want tuplet brackets. However, specifying that they
>> are wanted, as in the second expression, seems to break stuff, and I
>> have no idea why.
>>
>> In fact, it is simply the presence of the override which causes the
>> problem, as the effect is the same whether the value is ##t, ##f, or
>> even the default #'if-no-beam.
>>
>> Is there a subtlety here I should learn about, or is there simply a bug?
>>
>> Paul
>>
>>
>> \version "2.23.3"
>>
>> \language english
>>
>> \relative fs {
>> \accidentalStyle dodecaphonic-no-repeat
>> \clef bass
>> \time 2/4
>> << { r16 \voiceTwo fs8.--~\mf \tuplet 3/2 { fs8 f,-- g-- } | } ||
>> { s4 \voiceOne fs'4 | } ||
>> { s4 s4*1/3 f,4*2/3 | }
>>>>
>> }
>>
>> \relative fs {
>> \accidentalStyle dodecaphonic-no-repeat
>> \override TupletBracket.bracket-visibility = ##t
>> \clef bass
>> \time 2/4
>> << { r16 \voiceTwo fs8.--~\mf \tuplet 3/2 { fs8 f,-- g-- } | } ||
>> { s4 \voiceOne fs'4 | } ||
>> { s4 s4*1/3 f,4*2/3 | }
>>>>
>> }
>>
>>
>