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