Re:Strange behaviour (bug?) with multiple overlapping

[Jan Rosseel]

From: David Kastrup <address@hidden>
"Jan Rosseel" <address@hidden> writes:

Thanks David, 

> > The code below results in having four stacked dynamic texts under
the 
> > third note. Maybe not exactly what is expected (I'd expect Lilypond
to 
> > detect the overlapping dynamics), but I can live with that.

> The overlapping dynamics would be detected if they were in the same
voice.

> You are getting a new implicit Voice started for each skip parallelly
in a Staff, while the override is established in an existing voice which
is then continued to be used.

That's the thing that surprised me. I was under the assumption that <<
>> without the \\ was not starting implicit voices. If Lilypond is doing
this anyway, then of course one gets weird effects. 

Surrounding the << >> construct inside a \new Voice { } fixed the main
issue. Only one dynamic left (instead of three or four) and the
fingerings no longer overlapped the bow marks. And it is predictable
which one of the dynamic texts will actually be printed (the first
one...). Cool. But: there's a new (small) problem. 

The \new Voice {} neatly pushes everything inside one voice. This of
course means I can no longer have a global \override DynamicText #'color
= #red/green/blue in the different edit tracks. 
So I switched to \once\override. And that shows another interesting
effect. 

Try the following:

\version "2.16.1"

melody = \relative c'' {
  \time 4.4
c4 d e\p f }

editOne = { s4 s4 \once\override DynamicText #'color = #blue s4\mp s4 }

editTwo = { s4\upbow s4\downbow \once\override DynamicText #'color =
#green s4\mf s4 }

editThree = { \override Fingering #'color = #red s4-1  s4-2
\once\override DynamicText #'color = #red s4\f s4 }

\score {
  <<
    \new Staff { 
      \new Voice {
        <<
          \editThree
          \editTwo
          \editOne
          \melody 
        >>
      }
    }
  >>
}

The \f of the editThree music construct "wins". However, the dynamic
mark is not red, but blue. So while Lilypond takes the \f construct from
editThree, it takes the color override from editOne. Moving editOne
around in the file doesn't help. Moving the inclusion of the edit blocks
around inside the << >> construct changes the color though. 

So what it comes down to in this case: 
* the "first" dynamic mark at a certain position is printed
* the "last" color override is retained 

So I can either get the color or the mark correct (or better: "as
expected"), but not both. 

I'm sure there will be a reason for this, and it certainly falls in the
area of cosmetic problems, but I'd be grateful if someone could give me
a clue on how I can take control of the coloring of the dynamic mark. 

Regards, 


--
JanR