Re: The fate of override/revert/applyOutput

[Erik Sandberg]

On Monday 12 June 2006 16:28, Han-Wen Nienhuys wrote:
> 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?

Currently, override manipulates grob properties. Until that's generalised to 
cover the Performer equivalent, the command belongs to Engraver IMHO. It can 
easily be moved to Translator later, if needed.

If you plan to do the change soon, I could use translators directly though.

> Is there any practical advantage of changing the current situation to
> (1) or (2) ?

Not computationally (though changing to 2 should be a tiny bit faster than the 
current situation, in some situations). The issue is more about music 
representation policy; I want music streams to be a consistent music 
representation format, so question is whether there should be a convention 
that stream events targeted at translators _may_ be sent to non-bottom 
contexts.

-- 
Erik