[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
The fate of override/revert/applyOutput
From: |
Erik Sandberg |
Subject: |
The fate of override/revert/applyOutput |
Date: |
Sun, 11 Jun 2006 18:53:25 +0200 |
User-agent: |
KMail/1.9.1 |
Hi,
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 {...} >>)
Besides, the only reason I can see for sending all events to bottom contexts,
is that it allows implicit context creation; since context creation really
the job of music iterators, it shouldn't affect the design of music streams.
It will take some time before I'll make this change, but the decision is a
philosophical one that will affect some design decisions on the way.
--
Erik
- The fate of override/revert/applyOutput,
Erik Sandberg <=