Hi Stefano,

Am 05.05.19 um 06:12 schrieb Stefano Troncaro:
> Hi Jan Peter,
>
> I tested the newly merged refactor-override branch a little bit. As
> far as I could tell it seems to be working fine and the problem I
> described in my original post (where there was an error when a
> grob-property-path consisted of a list) is solved.
>
> A minor issue I find is that the Edition Engraver is now printing a
> lot of superfluous warnings of the type "edition-engraver overriden by
> music!". I say superfluous because the overrides are clearly working
> as intended and there is nothing in the music overlapping with the
> overrides I want the EE to make
> However, I've been unable to replicate this problem in small contained
> examples. This happened in projects of some size, and when I try to
> extract the problematic measures to create a self-contained one or two
> bar example, then the warnings are not created anymore. Because of
> this I hesitated a bit about describing the problem, but since the
> same projects create no superfluous warnings when compiled with the
> current master branch I thought it might be useful to tell you about
> it either way.
>
> If I recall correctly this used to happen some time ago? Maybe it
> reappeared because it was still present in the refactor-override branch.
>
> I'll see if tomorrow I manage to narrow it down and create an example.
>
> I hope this was of some use,
o yes, it is of use. It reminds me of making this log message optional
and to narrow it down to really affected cases. The problem is that in
certain cases an override inside the music stream can override an
override injected by the EE. The problem may not obvious on first sight:
Some LilyPond constructs inject overrides into the music stream like for
example simultaneous music (<< .. \\ .. >>). Now when you have such a
section of simultaneous music and you want to affect stem-direction in
Voice "1" the EE-override will be overridden on the first moment the
simultaneous music is introduced.
I introduced this log message to identify possible cases. IIRC this was
the main reason to not merge into master yet.

I'll look into it the next days.

Jan-Peter

> Stéfano
>
> El sáb., 4 may. 2019 a las 14:13, Stefano Troncaro
> (<stefanotronc...@gmail.com <mailto:stefanotronc...@gmail.com>>) escribió:
>
>     Hi Jan Peter, I'll update and let you know if I find any problems
>     with the updated refactor-override branch.
>
>     Thank you for all your work in the Edition Engraver!
>
>     El vie., 3 may. 2019 a las 3:37, Jan-Peter Voigt (<jp.vo...@gmx.de
>     <mailto:jp.vo...@gmx.de>>) escribió:
>
>         Hi Stefano,
>
>         a lot of lilypond-unrelated business prevented me working on
>         the edition-engraver and especially in the
>         refactor-override-branch for quite a while.
>         Meanwhile there where some small issues to fix in master so
>         the two branches diverged.
>         So the old and stale 'refactor-override-branch' is a
>         development branch removing and changing code related to
>         \override, \set et al..
>         Now I merged master into 'refactor-override-branch' so it is
>         up to date with master.
>         For now I suggest using the updated branch. I am going to test
>         it soon so that is fit to be merged into master.
>         And the next development branch is 'absolute-timing' meant to
>         introduce anchors and the correct handling of cadenza sections.
>
>         If there are any problems with the 'refactor-override-branch'
>         please let me know and I am going to fix it asap.
>
>         Jan-Peter
>
>
>         Am 30.04.19 um 17:16 schrieb Stefano Troncaro:
>>         Hi Jan-Peter,
>>
>>         Sure! Please let me know if you manage to solve it so I can
>>         update.
>>
>>         Thank you!
>>
>>         El dom., 28 abr. 2019 a las 16:05, Jan-Peter Voigt
>>         (<jp.vo...@gmx.de <mailto:jp.vo...@gmx.de>>) escribió:
>>
>>             Hi Stefano,
>>
>>             sorry for the delay. I've been away for several days.
>>             I have to look into this deeper ... I guess it is related
>>             to the
>>             grob-property-path 'bound-details.left.text'.
>>             Hopefully I can solve this issue soon.
>>
>>             Best
>>             Jan-Peter
>>
>>             Am 21.04.19 um 20:42 schrieb Stefano Troncaro:
>>             > Hi all, long time since I posted here, hope you all
>>             have been well!
>>             >
>>             > While using the Edition Engraver today I noticed that
>>             the following
>>             > override works in the old refactor override branch,
>>             while on the
>>             > current master it prints a textless spanner and a warning:
>>             >
>>             > \version "2.19.80" \include "oll-core/package.ily"
>>             \loadPackage edition-engraver \consistToContexts
>>             #edition-engraver Voice \addEdition test \editionMod test
>>             1 0 Voice.A { \override
>>             TextSpanner.bound-details.left.text = "span this"
>>             <>\startTextSpan } \editionMod test 2 3/4 Voice.A
>>             \stopTextSpan \new Staff { \new Voice \relative { c' d e
>>             f g a b c } }
>>             >
>>             > Said warning is
>>             >
>>             > warning: type check for `bound-details' failed; value
>>             `"span this"'
>>             > must be of type `list'
>>             >
>>             > In the current master I could set this like this:
>>             > \override TextSpanner.bound-details = #'((left . ((text
>>             . "span this"))))
>>             > but this has the undesirable effect of resetting all
>>             the other
>>             > settings of the bound-details alist
>>             >
>>             > Without having been able to dive down into the code,
>>             this looks like a
>>             > simple issue with type checking, but I realize this may
>>             have been
>>             > implemented this way to circumvent other problems.
>>             >
>>             > So, how can I achieve this with the current master? Or
>>             should I go
>>             > back to using the earlier branch until this is solved?
>>             >
>>             > Thanks for your help,
>>             > Stéfano
>>             >
>>             > _______________________________________________
>>             > lilypond-user mailing list
>>             > lilypond-user@gnu.org <mailto:lilypond-user@gnu.org>
>>             > https://lists.gnu.org/mailman/listinfo/lilypond-user
>>
>>
>>             _______________________________________________
>>             lilypond-user mailing list
>>             lilypond-user@gnu.org <mailto:lilypond-user@gnu.org>
>>             https://lists.gnu.org/mailman/listinfo/lilypond-user
>>
>

_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Reply via email to