Edition Engraver bug?

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Edition Engraver bug?

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 test 1 0 Voice.A \ovA
\editionMod test 1 0 Voice.B \ovA
\score {
  \new StaffGroup <<
    \formA
    \formB
    \controlA
  >>
}

\markup "Results with \\override Tie.direction"

\editionMod test 1 0 Voice.D \ovB
\editionMod test 1 0 Voice.E \ovB
\score {
  \new StaffGroup <<
    \formA
    \formB
    \controlB
  >>
}

\markup "Results with ly:grob-set-property!"

\editionMod test 1 0 Voice.G \ovC
\editionMod test 1 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!
Stéfano

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Edition Engraver bug?

Jan-Peter Voigt
Hi Stefano,

thanks a lot for researching this issue! Sometimes I also noticed "rebel
ties", but I didn't identified it as an EE bug. So your research file
looks meaningful.
I hope to have a deeper look into it next week.

Best
Jan-Peter

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!
> Stéfano
>
>
> _______________________________________________
> lilypond-user mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/lilypond-user



_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Edition Engraver bug?

Jan-Peter Voigt
In reply to this post by Stefano Troncaro
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.

Jan-Peter



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!
> Stéfano
>
>
> _______________________________________________
> lilypond-user mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Edition Engraver bug?

David Kastrup
Jan-Peter Voigt <[hidden email]> writes:

> 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.

Any chance to actually use the equivalent of "\once" here?  It's
protected against reverting the wrong override, but this functionality
is not exposed at the Scheme level.

--
David Kastrup

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Edition Engraver bug?

Jan-Peter Voigt
Hi David,

Am 05.03.2018 um 10:42 schrieb David Kastrup:
>> 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.
> Any chance to actually use the equivalent of "\once" here?  It's
> protected against reverting the wrong override, but this functionality
> is not exposed at the Scheme level.

The EE is written entirely in scheme so I don't see a chance. But
probably I just don't see it right now.

*the following is just a brainstorm*

The overrides given by \editionMod are applied early in the
start-translation-timestep slot and therefore before overrides inside
the music are applied (inside process-music ?). If the EE applies
overrides inside process-music it is to late.
The once-overrides managed by the EE are stored in a list until they are
reverted inside stop-translation-timestep. Of course it would be better
to give the once-attribute once and let lilypond revert the right property.
How would it be possible to listen to overrides? They are not caught
when I listen to StreamEvent. Maybe it is to prevent me from
implementing bad patterns.

I will later produce a more concise chart on how and when the EE is
applying overrides.

Jan-Peter


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Edition Engraver bug?

David Kastrup
Jan-Peter Voigt <[hidden email]> writes:

> Hi David,
>
> Am 05.03.2018 um 10:42 schrieb David Kastrup:
>>> 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.
>> Any chance to actually use the equivalent of "\once" here?  It's
>> protected against reverting the wrong override, but this functionality
>> is not exposed at the Scheme level.
>
> The EE is written entirely in scheme so I don't see a chance.

It can still send override events rather than setting properties by
itself.

> How would it be possible to listen to overrides? They are not caught
> when I listen to StreamEvent.

What?  They are definitely sent as events.

--
David Kastrup

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Edition Engraver bug?

Jan-Peter Voigt
Thank you, David! Sometimes I need a pointer to the obvious ...
* I will refactor the EE to also broadcast overrides.
* Of course I can listen to Overrides (and SetProperty) and check if
there are editionMods and music colliding - the reason they didn't show
up when I listened to StreamEvent was that I was looking for
music-cause, but that isn't set.
* The EE might export overrides and such to another file for use with the EE

There first point should clean up and shorten some code. I will need
some days but will deliver an update ASAP.

Jan-Peter


Am 05.03.2018 um 12:18 schrieb David Kastrup:

> Jan-Peter Voigt <[hidden email]> writes:
>
>> Hi David,
>>
>> Am 05.03.2018 um 10:42 schrieb David Kastrup:
>>>> 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.
>>> Any chance to actually use the equivalent of "\once" here?  It's
>>> protected against reverting the wrong override, but this functionality
>>> is not exposed at the Scheme level.
>>
>> The EE is written entirely in scheme so I don't see a chance.
>
> It can still send override events rather than setting properties by
> itself.
>
>> How would it be possible to listen to overrides? They are not caught
>> when I listen to StreamEvent.
>
> What?  They are definitely sent as events.
>


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Edition Engraver bug?

Jan-Peter Voigt
In reply to this post by Stefano Troncaro
Hi Stefano,

I have been looking into the issue and created a branch
'refactor-override' for the edition-engraver.
The following is changed in there:
* Overrides are not applied "by hand" but send as a StreamEvent so that
once is handled by lily and not the EE
* Override (and Revert, Set, Unset) sent by the EE are marked so that
they can be distinguished from other overrides

That means once-overrides are note reverted wrong anymore and the EE
gives a warning if an overrides supersedes/overwrites an EE mod. This is
still not completely satisfactory when the EE shall override all other
settings. But at least it doesn't revert wrong.

If this branch is tested more thoroughly I will merge it into master.
Now I am looking for a way to let the EE be the last broadcaster so that
it will not be overridden by overrides sent from the actual music stream.

Jan-Peter


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!
> Stéfano
>
>
> _______________________________________________
> lilypond-user mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Edition Engraver bug?

David Kastrup
Jan-Peter Voigt <[hidden email]> writes:

> Hi Stefano,
>
> I have been looking into the issue and created a branch
> 'refactor-override' for the edition-engraver.
> The following is changed in there:
> * Overrides are not applied "by hand" but send as a StreamEvent so
> that once is handled by lily and not the EE
> * Override (and Revert, Set, Unset) sent by the EE are marked so that
> they can be distinguished from other overrides
>
> That means once-overrides are note reverted wrong anymore and the EE
> gives a warning if an overrides supersedes/overwrites an EE mod. This
> is still not completely satisfactory when the EE shall override all
> other settings. But at least it doesn't revert wrong.
>
> If this branch is tested more thoroughly I will merge it into master.
> Now I am looking for a way to let the EE be the last broadcaster so
> that it will not be overridden by overrides sent from the actual music
> stream.

How do you trigger the EE?  Overrides from the music stream are sent by
the iterators.  That's after start-translation-timestep and before
process-music.

--
David Kastrup

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Edition Engraver bug?

Jan-Peter Voigt
Am 13.03.2018 um 11:37 schrieb David Kastrup:

> Jan-Peter Voigt <[hidden email]> writes:
>
>> Hi Stefano,
>>
>> I have been looking into the issue and created a branch
>> 'refactor-override' for the edition-engraver.
>> The following is changed in there:
>> * Overrides are not applied "by hand" but send as a StreamEvent so
>> that once is handled by lily and not the EE
>> * Override (and Revert, Set, Unset) sent by the EE are marked so that
>> they can be distinguished from other overrides
>>
>> That means once-overrides are note reverted wrong anymore and the EE
>> gives a warning if an overrides supersedes/overwrites an EE mod. This
>> is still not completely satisfactory when the EE shall override all
>> other settings. But at least it doesn't revert wrong.
>>
>> If this branch is tested more thoroughly I will merge it into master.
>> Now I am looking for a way to let the EE be the last broadcaster so
>> that it will not be overridden by overrides sent from the actual music
>> stream.
>
> How do you trigger the EE?  Overrides from the music stream are sent by
> the iterators.  That's after start-translation-timestep and before
> process-music.

The EE broadcasts overrides (events) inside start-translation-timestep.
I tried to do it in process-music, but then they were applied too late.
The EE is looking in its internal mod-store if there is something to do
for this timestep (for this context). Is there a way to act between
those slots - the latest action before process-music?

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Edition Engraver bug?

Stefano Troncaro
Hi Jan-Peter,

Thank you for your work! I will test the changes later today and let you know how it results.

2018-03-13 7:47 GMT-03:00 Jan-Peter Voigt <[hidden email]>:
Am 13.03.2018 um 11:37 schrieb David Kastrup:
Jan-Peter Voigt <[hidden email]> writes:

Hi Stefano,

I have been looking into the issue and created a branch
'refactor-override' for the edition-engraver.
The following is changed in there:
* Overrides are not applied "by hand" but send as a StreamEvent so
that once is handled by lily and not the EE
* Override (and Revert, Set, Unset) sent by the EE are marked so that
they can be distinguished from other overrides

That means once-overrides are note reverted wrong anymore and the EE
gives a warning if an overrides supersedes/overwrites an EE mod. This
is still not completely satisfactory when the EE shall override all
other settings. But at least it doesn't revert wrong.

If this branch is tested more thoroughly I will merge it into master.
Now I am looking for a way to let the EE be the last broadcaster so
that it will not be overridden by overrides sent from the actual music
stream.

How do you trigger the EE?  Overrides from the music stream are sent by
the iterators.  That's after start-translation-timestep and before
process-music.

The EE broadcasts overrides (events) inside start-translation-timestep. I tried to do it in process-music, but then they were applied too late.
The EE is looking in its internal mod-store if there is something to do for this timestep (for this context). Is there a way to act between those slots - the latest action before process-music?


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Edition Engraver bug?

Stefano Troncaro
I wanted to let you know that I have tried the refactor-override branch and the overrides seem to be working fine! I do get a lot of warnings as you explained, but it does not appear the the EE overrides are getting overwritten, or maybe I'm misunderstanding your explanation?

2018-03-13 13:50 GMT-03:00 Stefano Troncaro <[hidden email]>:
Hi Jan-Peter,

Thank you for your work! I will test the changes later today and let you know how it results.

2018-03-13 7:47 GMT-03:00 Jan-Peter Voigt <[hidden email]>:
Am 13.03.2018 um 11:37 schrieb David Kastrup:
Jan-Peter Voigt <[hidden email]> writes:

Hi Stefano,

I have been looking into the issue and created a branch
'refactor-override' for the edition-engraver.
The following is changed in there:
* Overrides are not applied "by hand" but send as a StreamEvent so
that once is handled by lily and not the EE
* Override (and Revert, Set, Unset) sent by the EE are marked so that
they can be distinguished from other overrides

That means once-overrides are note reverted wrong anymore and the EE
gives a warning if an overrides supersedes/overwrites an EE mod. This
is still not completely satisfactory when the EE shall override all
other settings. But at least it doesn't revert wrong.

If this branch is tested more thoroughly I will merge it into master.
Now I am looking for a way to let the EE be the last broadcaster so
that it will not be overridden by overrides sent from the actual music
stream.

How do you trigger the EE?  Overrides from the music stream are sent by
the iterators.  That's after start-translation-timestep and before
process-music.

The EE broadcasts overrides (events) inside start-translation-timestep. I tried to do it in process-music, but then they were applied too late.
The EE is looking in its internal mod-store if there is something to do for this timestep (for this context). Is there a way to act between those slots - the latest action before process-music?


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user



_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Edition Engraver bug?

Jan-Peter Voigt
Hi Stéfano,

I tested with the force-rebel-tie.ly file you sent earlier in this thread. What I meant was that \tieDown still does have no effect, when there is a \voiceOne statement - maybe hidden via << \\ >>. So the first tie is not changed with the EE-mod in the demo.
Do you think the warnings are too verbose?

Am 14.03.2018 um 21:47 schrieb Stefano Troncaro:
I wanted to let you know that I have tried the refactor-override branch and the overrides seem to be working fine! I do get a lot of warnings as you explained, but it does not appear the the EE overrides are getting overwritten, or maybe I'm misunderstanding your explanation?

2018-03-13 13:50 GMT-03:00 Stefano Troncaro <[hidden email]>:
Hi Jan-Peter,

Thank you for your work! I will test the changes later today and let you know how it results.

2018-03-13 7:47 GMT-03:00 Jan-Peter Voigt <[hidden email]>:
Am 13.03.2018 um 11:37 schrieb David Kastrup:
Jan-Peter Voigt <[hidden email]> writes:

Hi Stefano,

I have been looking into the issue and created a branch
'refactor-override' for the edition-engraver.
The following is changed in there:
* Overrides are not applied "by hand" but send as a StreamEvent so
that once is handled by lily and not the EE
* Override (and Revert, Set, Unset) sent by the EE are marked so that
they can be distinguished from other overrides

That means once-overrides are note reverted wrong anymore and the EE
gives a warning if an overrides supersedes/overwrites an EE mod. This
is still not completely satisfactory when the EE shall override all
other settings. But at least it doesn't revert wrong.

If this branch is tested more thoroughly I will merge it into master.
Now I am looking for a way to let the EE be the last broadcaster so
that it will not be overridden by overrides sent from the actual music
stream.

How do you trigger the EE?  Overrides from the music stream are sent by
the iterators.  That's after start-translation-timestep and before
process-music.

The EE broadcasts overrides (events) inside start-translation-timestep. I tried to do it in process-music, but then they were applied too late.
The EE is looking in its internal mod-store if there is something to do for this timestep (for this context). Is there a way to act between those slots - the latest action before process-music?


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user




_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Edition Engraver bug?

Stefano Troncaro
It's strange, I tested with a project that had some "rebel ties", commented out the previous fix and used \tieDown, and the ties went in the direction I wanted them to... I'll have to look at it in more detail, but it must surely be my fault, I must have missed something.
However in the example above it does work exactly as you mention it does. I think the warnings are ok, they are kind of verbose, but it is telling you "find another way to do this!" so I think the verbosity is useful.

2018-03-15 11:57 GMT-03:00 Jan-Peter Voigt <[hidden email]>:
Hi Stéfano,

I tested with the force-rebel-tie.ly file you sent earlier in this thread. What I meant was that \tieDown still does have no effect, when there is a \voiceOne statement - maybe hidden via << \\ >>. So the first tie is not changed with the EE-mod in the demo.
Do you think the warnings are too verbose?


Am 14.03.2018 um 21:47 schrieb Stefano Troncaro:
I wanted to let you know that I have tried the refactor-override branch and the overrides seem to be working fine! I do get a lot of warnings as you explained, but it does not appear the the EE overrides are getting overwritten, or maybe I'm misunderstanding your explanation?

2018-03-13 13:50 GMT-03:00 Stefano Troncaro <[hidden email]>:
Hi Jan-Peter,

Thank you for your work! I will test the changes later today and let you know how it results.

2018-03-13 7:47 GMT-03:00 Jan-Peter Voigt <[hidden email]>:
Am 13.03.2018 um 11:37 schrieb David Kastrup:
Jan-Peter Voigt <[hidden email]> writes:

Hi Stefano,

I have been looking into the issue and created a branch
'refactor-override' for the edition-engraver.
The following is changed in there:
* Overrides are not applied "by hand" but send as a StreamEvent so
that once is handled by lily and not the EE
* Override (and Revert, Set, Unset) sent by the EE are marked so that
they can be distinguished from other overrides

That means once-overrides are note reverted wrong anymore and the EE
gives a warning if an overrides supersedes/overwrites an EE mod. This
is still not completely satisfactory when the EE shall override all
other settings. But at least it doesn't revert wrong.

If this branch is tested more thoroughly I will merge it into master.
Now I am looking for a way to let the EE be the last broadcaster so
that it will not be overridden by overrides sent from the actual music
stream.

How do you trigger the EE?  Overrides from the music stream are sent by
the iterators.  That's after start-translation-timestep and before
process-music.

The EE broadcasts overrides (events) inside start-translation-timestep. I tried to do it in process-music, but then they were applied too late.
The EE is looking in its internal mod-store if there is something to do for this timestep (for this context). Is there a way to act between those slots - the latest action before process-music?


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user





_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user