|
From: | Han-Wen Nienhuys |
Subject: | Re: The fate of override/revert/applyOutput |
Date: | Mon, 12 Jun 2006 16:28:30 +0200 |
User-agent: | Thunderbird 1.5.0.2 (X11/20060501) |
Erik Sandberg schreef:
With music streams, \set and \override are today similar: Both send a stream event directly to the affected context, and the actual override is carried out by a hard-coded listener.There is however one important difference: \override is back-end specific, and carried out by an engraver group, while \set is handled by the context itself. \override thereby has more in common with applyOutput than with \set, so I feel that the implementations of \override and \applyOutput should be more similar as well.
>
I can see two ways to go:1. Make \override use an \applyOutput-like implementation: Generate music events for override/revert, and create a grob-property-engraver, which hears override/revert events and applies them. 2. Make \applyOutput send the event directly to a non-bottom context, without using report_event. A new ContextSpeccedEvent music type could be created for this, and the output-property-engraver would possibly be hard-coded into engraver-group.cc.I like (2) better, because I don't like how applyOutput events bounce on bottom context, and because in (1), new context will be created implicitly sometimes (e.g., an unwanted extra staff will be created in \new Score <<\override Score.Foo #'bar = #baz \new Staff {...} >>)
I agree with (2) being better than (1), but I don't see where engravers come into play. Hypothetically, it could be possible that a future MIDI backend also supports \override and \revert. Shouldn't this happen in the Translator class rather than Engraver?
Is there any practical advantage of changing the current situation to (1) or (2) ?
-- Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com
[Prev in Thread] | Current Thread | [Next in Thread] |