lilypond-devel
[Top][All Lists]
Advanced

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

Re: Issue with deep-copy/map-some-music a tuplet


From: Paolo Prete
Subject: Re: Issue with deep-copy/map-some-music a tuplet
Date: Sun, 25 Dec 2022 20:48:35 +0100

Well,
I reordered what I consider erroneous behaviors in the GitLab issue page

On Sun, Dec 25, 2022 at 7:55 PM Jean Abou Samra <jean@abou-samra.fr> wrote:

>
>
> Le 25 déc. 2022 à 19:44, Paolo Prete <paolopr976@gmail.com> a écrit :
>
> 
>
>
> On Sun, Dec 25, 2022 at 7:22 PM Jean Abou Samra <jean@abou-samra.fr>
> wrote:
>
>>
>>
>> > Le 25 déc. 2022 à 19:10, Paolo Prete <paolopr976@gmail.com> a écrit :
>> >
>> > 
>> > BTW:
>> >
>> > {
>> >   \override TupletBracket.bracket-visibility = ##f
>> >   \tuplet 3/2 { s8 s8 s8 }
>> > }
>> >
>> > In 2.24.0 and previous versions this raises the "omitting tuplet
>> bracket with neither left nor right bound" warning, even if the
>> bracket-visibility is explicitly set to false.
>>
>>
>> Why would that change anything? With bracket-visibility = #f, the tuplet
>> bracket is still there, just not visible. The tuplet number is still there
>> and can be visible.
>>
>>
> You're right, but what about:
>
> {
>    \override TupletBracket.stencil = ##f
>    \tuplet 3/2 { s8 s8 s8 }
> }
>
> ..? Same warning
>
>
>
> Same remark here about the tuplet bracket being present, although
> invisible, in this case.
>
>
> I don’t understand why you think this necessitates an issue separate from
>> the one that has already been created.
>>
>>
>>
> Consider this:
>
> {
>    \override TupletBracket.stencil = ##t
>    \tuplet 3/2 { s8 c' s8 }
> }
>
> This is a tuplet without proper bounds, and the bracket doesn't appear,
> therefore. But it compiles on 2.25 too and it doesn't raise the "omitting
> tuplet bracket" warning. Therefore I think that a new issue that includes
> this case should be created.
>
>
> I am not in front of a computer right now, but '##t' is not a stencil
> value and I expect that LilyPond warns you about that.
>
>
> Alternatively, you could rename the previous GitLab issue with "Issues
> with tuplet without proper bounds", removing "no longer compile", so that
> it includes both cases that compile and cases that don't compile.
>
>
>
> Meta: understanding what the problem is precisely is half of the work to
> fix it, and I’m not willing to do it this evening.
>
>


reply via email to

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