[Top][All Lists]

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

Re: Edition Engraver bug?

From: Jan-Peter Voigt
Subject: Re: Edition Engraver bug?
Date: Mon, 5 Mar 2018 09:10:04 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

Hi Stefano,

thanks again for bringing up this issue! Now I identified it an EE-bug and I was able to reproduce the failure with:
\version "2.19.80"
\include "oll-core/package.ily"
\loadPackage edition-engraver
\consistToContexts #edition-engraver Voice

\addEdition test

\editionMod test 1 0/4 Voice.A \once \tieDown

  \relative { a'4~ a~ a~ a } \\
  \relative { e'~ e~ e~ e }

If \tieDown is is set to moment 1/4 it is applied as expected - so the affected \editionMod at moment 0/4 is scheduled to happen at the moment \voiceOne is applied. This issue produces some kind of a race condition where Tie.direction is modified by \voiceOne after \editionMod comes into action. The EE does a \revert for all \overrides when the timestep is finished, but the top of the override stack is the override introduced by \voiceOne, so that is reverted to the \tieDown state. (Btw. \tieDown is just an equivalent shortcut for \override Tie.direction = #DOWN) Using ly:grob-property is not affected here, because there are no overrides to Tie.after-linebreak inside the music expression and ly:grob-property is applied late.

This is a failure that can happen whenever there are (implicit) overrides in the music. I'll try to track/fetch overrides generated outside the EE to avoid this issue.


Am 26.02.2018 um 15:26 schrieb Stefano Troncaro:
Hi everyone! I tried to isolate the issue with Tie directions that I posted earlier and I'm fairly confident I've stumbled upon a bug.

Look at the output of this snippet (Sorry for the length, I made it as short as I could)

    \version  "2.19.80" \language  "english" \include  "oll-core/package.ily" 
\loadPackage  edition-engraver
    \addEdition  test
    \consistToContexts  #edition-engraver Voice

    \layout  { \context  { \Score \time  6/4
         \omit  TimeSignature \omit  Clef } } forceRebelTie =
    #(define-music-function  (dir) (ly:dir?)
          \override  Tie.before-line-breaking  =
          #(lambda  (grob)
             (ly:grob-set-property!  grob 'direction dir)) #} )

ovA =\once \tieDown ovB =\once \override Tie.direction = #DOWN ovC =\once \forceRebelTie #DOWN formA =\new Staff \with { instrumentName ="All V1" } << \new Voice \relative c''{ \voiceOne b~ 4 4~ 4 4~ 4} >> formB =\new Staff \with { instrumentName ="1V V1" } << \new Voice \relative c''{ b~ \voiceOne 4 \oneVoice 4~ \voiceOne 4 \oneVoice 4~ \voiceOne 4 } >> controlA =\new Staff \with { instrumentName ="No EE" } << \new Voice \relative c''{ \voiceOne \ovA b~ 4 4~ 4 4~ 4 } >> controlB =\new Staff \with { instrumentName ="No EE" } << \new Voice \relative c''{ \voiceOne \ovB b~ 4 4~ 4 4~ 4 } >> controlC =\new Staff \with { instrumentName ="No EE" } << \new Voice \relative c''{ \voiceOne \ovC b~ 4 4~ 4 4~ 4 } >> \markup "Results with \\tieDown" \editionMod test1 0 Voice.A\ovA \editionMod test1 0 Voice.B\ovA \score { \new StaffGroup << \formA \formB \controlA >> } \markup "Results with \\override Tie.direction" \editionMod test1 0 Voice.D\ovB \editionMod test1 0 Voice.E\ovB \score { \new StaffGroup << \formA \formB \controlB >> } \markup "Results with ly:grob-set-property!" \editionMod test1 0 Voice.G\ovC \editionMod test1 0 Voice.H\ovC \score { \new StaffGroup << \formA \formB \controlC >> } \markup "No overrides (default behavior for comparison)" \score { \new StaffGroup << \formA \formB >> }

When \voiceOne is in full effect, both \once \tieDown and\once \override Tie.direction seem to have a permanent effect that kicks in after the moment they are used, which is exactly the opposite to what they should do (take effect only in the moment they are called and revert to the previous behavior after). This is very clear when you compare the All V1 Staff with the No EE Staff: the All V1 behaves in the exact opposite way.

I have absolutely no idea about why this may be happening, but I'm certain that one should expect the EE to achieve the same results that manually writing the code in the desired place and moment would.

Hopefully Jan-Peter or someone more knowledgeable than I can look into it!

I hope this "research" can be useful!

lilypond-user mailing list

reply via email to

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