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 <jp.vo...@gmx.de>:

> Am 13.03.2018 um 11:37 schrieb David Kastrup:
>> Jan-Peter Voigt <jp.vo...@gmx.de> 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
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
lilypond-user mailing list

Reply via email to