Re: Simplify the NullVoice context (issue 117050043 by address@hidden)

[dak]

https://codereview.appspot.com/117050043/diff/40001/ly/engraver-init.ly
File ly/engraver-init.ly (right):

https://codereview.appspot.com/117050043/diff/40001/ly/engraver-init.ly#newcode787
ly/engraver-init.ly:787: \override NoteHead.meta.interfaces = #(delete
'rhythmic-head-interface
On 2014/07/27 11:25:41, janek wrote:
> What about making NullVoice \accepted not by \Staff, but by \Score
(like
> Devnull)?  From my test it seems that it would work and we wouldn't
have to care
> about Rhythmic_column_engraver.

Ugh.  This looks incredibly ugly.  No code elsewhere messes with the
basic underlying grob properties, and overriding a nested property to
boot is a recipe for trouble.

We really, really should not be doing something like that.  It would
make more sense to make rhythmic-head-interface get along without
Rhythmic_column_engraver or otherwise fix things to work properly when a
number of engravers are being removed.

If we really, really cannot make do otherwise, we could design
substitute engravers that mostly do the same job but without producing
output.  I mean, Midi has to produce the same timing for Lyrics and
manages with a vastly simplified set of performers.

It's even conceivable to tie the lyrics and other stuff together with
translators that are basically decoupled from the engravers/performers
doing the actual grobs or sobs (or what we call the sound equivalent of
a grob).  We could use those for every output then.  For example, if we
have some separate translator producing artificial tie STOP events (and
catering for tieWaitForNote and similar), we'd run less of a danger that
Midi and PDF get out of synch.  And custom engravers making use of that
info would become simpler.

That way we don't need to reimplement the synhronization yet another
time if we add, say, MusicXML output.

https://codereview.appspot.com/117050043/