Re: Edition Engraver master vs refactor override branch: changing bound-details

[Stefano Troncaro]

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 (<address@hidden>) 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 (<address@hidden>) 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 (<address@hidden>) 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 (<address@hidden>) 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user


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