lilypond-user
[Top][All Lists]
Advanced

[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 | }
>>>>
>>  }
>>
>>
>



reply via email to

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