On Sun, 27 Jul 2014 23:07:58 -0700, <[email protected]> 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.


_______________________________________________
lilypond-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Reply via email to