[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