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

[Keith OHara]

On Sun, 27 Jul 2014 23:07:58 -0700, <address@hidden> wrote:

> The ugliness is with messing up the whole grob definition of a NoteHead
> (which is fixed to the degree of being documented in the Internals
> Reference) inside of a particular context.
I thought that was pretty, as well.
We override the defaults of grobs all the time to suit particular contexts (\omit 
NoteHead for example).  And this seemed a clear way of saying "all the default 
interfaces of a NoteHead except rhythmic-head".

I see that we usually don't change interfaces, though.

> > It is easy to make the rest of the code accept an object with
> > rhythmic-head-interface that is unattached to any Rhythmic_Column
> > (just removing a test and warning in rest-collision.cc as I recall).
> >  The thing I didn't like
> > about that was changing completely unrelated code to accommodate the
> > weirdness of NullVoice.
>
> I don't see anything wrong with letting code work in more combinations
> than originally envisioned.  Where is the point in having separate
> building blocks if you can only assemble them in a single way?
Well, the code worked, but gave a warning.  We might want to warn that someone 
is assembling blocks in a dangerous way.   Looking at the history, this warning 
does not seem helpful.

I can remove that warning, and restore the \omit Accidental*
so that someone can have Staff accept NullVoice

> The point would be to stop the Tie_engraver from bothering about
> melismaBusy at all.
Splitting the melismaBusy function from Tie_engraver, etc., and putting it in a 
new engraver does seem sensible.

> But isn't NullVoice for faking lyrics to a synthetic voice that is _not_
> actually being printed?  That would imply that we want to rather align
> to the existing NoteHeads/NoteColumns rather than the NullVoice one.
> And even if there are no actual notes (like in a chant situation), we'd
> rather align on a well-spaced pattern rather than one based on imaginary
> noteheads, optical stem adjustments and what not.

(We don't get stem-corrections without stems.)
My first inclination was to produce no NoteHead grobs.  LyricExtenders and I 
think LyricHyphens needed work to help them find the NoteColums within their 
parent PaperColumns (like Janek made happen for LyricText).

With all that, NullVoice can be just Devnull plus a melisma_signal_engraver.