lilypond-user
[Top][All Lists]
Advanced

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

Re: Possible bug with TrillSpanner.to-barline?


From: David Kastrup
Subject: Re: Possible bug with TrillSpanner.to-barline?
Date: Fri, 27 Dec 2013 10:40:27 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Daniel Rosen <address@hidden> writes:

>> -----Original Message-----
>> From: Eluze [mailto:address@hidden
>>
>> try it in the Staff context:
>> 
>> \override Staff.TrillSpanner.to-barline = ##t
>> 
>> Eluze
>
> Well, that did the trick. A couple things about this are interesting
> to me, though.
>
> First of all, working through the IR, I see the following:
>
> TrillSpanner: "TrillSpanner objects are created by: Trill_spanner_engraver."
> Trill_spanner_engraver: "Trill_spanner_engraver is part of the
> following context(s): CueVoice, DrumVoice,
> GregorianTranscriptionVoice, KievanVoice, MensuralVoice,
> PetrucciVoice, TabVoice, VaticanaVoice and Voice."
>
> So it's unclear to me why typing \override Staff.TrillSpanner.anything
> should have any effect at all. Whenever I get the context wrong when I
> try to \override any other grob property, nothing happens.

There is no such thing as "too far up in the context hierarchy"
regarding grob descriptions and general context properties: as long as
there is no setting in a lower context, any setting in a higher context
will be visible below.

> Second of all, even passing over the first issue, why does it have
> THIS effect (i.e. making the "tr" fail to appear)?

> I'm not a programmer, but it still seems to me like there's some kind of bug 
> here.

Well, the first bug is that you do

\override TrillSpanner.bound-details.left.text but then do
\revert TrillSpanner.bound-details

which is not a matched pair.  The second bug is that you don't use
\temporary \override
so any previous setting is clobbered.

Then LilyPond throws in a longstanding bug of its own which means that

\revert TrillSpanner.bound-details.left.text

will not necessarily only revert the left text.

At any rate, reverting a subproperty in any manner is a recipe for
disaster when other overrides come into play, and \override
TrillSpanner.to-barline is another override.  You get the same problem
if you do \override TrillSpanner.direction = #UP in that place.

\override Staff.TrillSpanner... will tamper with a _different_ property
list (namely the Staff-level one) and thus will not mess with the
subproperty override.  While it is indeed the Staff-level barline
engraver that will ultimately look at the to-barline setting of the
TrillSpanner grob, that's irrelevant since the setting is indeed
established when the grob is _created_, namely at the level of the
Trill_span_engraver.

The best solution is not to use overrides here, but rather tweaks as
their action is definitely temporary.  That keeps you out of the bugs.

\version "2.17.97"

trillSharpMarkup = \markup {
   \concat { \musicglyph #"scripts.trill" \hspace #0.4 \raise #1.9
\teeny \sharp } }

startTrillSpanSharp = \tweak bound-details.left.text \trillSharpMarkup
                    \startTrillSpan

\relative c' {
   %% Uncomment next line
   \override TrillSpanner.to-barline = ##t
   c1\startTrillSpanSharp |
   c1\stopTrillSpan\startTrillSpan | }


-- 
David Kastrup



reply via email to

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