[Top][All Lists]

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

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

From: Stefano Troncaro
Subject: Re: Edition Engraver master vs refactor override branch: changing bound-details
Date: Sun, 5 May 2019 01:12:00 -0300

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,

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.


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.


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

lilypond-user mailing list

reply via email to

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