Oh I see.
For that reason I moved away from using the << ... \\ ... >> construct and
now I use \voices which by the way I find way more suited for my use case
of engraving piano music and then editing it with the edition engraver. I
use only one Voice per Staff, called "main", and spontaneous voices are
called "sub", "subb" for the second simultaneous extra voice, etc., so I
can always reach the main voice with \musicPath PNO.right.Voice.main and
all the other voices with PNO.right.Voice.sub. This way I don't have to
worry about counting them or giving them IDs, it can get confusing in long
scores if you have 20 or more total voices in a staff all named Voice.A,
Voice.B, etc, even when some of them are only active on one or two bars.
And the input files are really easy to read and mentally parse when written
in this way.
Now that I wrote this I think it would be interesting to find out how other
users use the tools to fit their needs and workflows. Lilypond is so open
in this regard.
What I meant to say with this is that this limitation of the Edition
Engraver can be worked around. In fact this could be an interesting
addendum to the guide in the wiki.
El dom., 5 may. 2019 a las 6:31, Jan-Peter Voigt (<jp.vo...@gmx.de>)
escribió:
> 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>) 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>)
>> 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>)
>>> 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
>>>> > https://lists.gnu.org/mailman/listinfo/lilypond-user
>>>>
>>>>
>>>> _______________________________________________
>>>> lilypond-user mailing list
>>>> 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
