Sorry for looking at this so late.
General comments:
- you're adding an enormous bunch of code to the instrument name
engraver. That's a bad idea. If this idea merits an engraver, it
should be a separate one.
- the rootSystem stuff should not be necessary; if they're nowhere
else, grobs are always added to the root system.
- it is unusual and unlogical to have a music-valued context property.
Does incipitMusic ever change over the course of the music?
- If I'm reading this correctly, this is all a grand hack to add a
little staff to an instrument name. I don't see the essential
difference between this and
\set instrumentName = \markup { \score { .. } the-real-name }
except that this is longer, more error prone and less flexible. Again,
what problem are you trying to solve?
2008/2/9, Nicolas Sceaux <[EMAIL PROTECTED]>:
> > Here is draft patch: the Instrument_name engraver is used to create an
> > Incipit grob before the first line when an incipit has been specified.
> > There are several problems in it:
> >
> > - how can I access the paper object from the engraver? I need a scaled
> > output definition to format the incipit score. There are paper_
> > slots in
> > Book and Paper_book classes, but I don't see how to get there from an
> > engraver. As a workaround, I used a context property to pass the
> > $defaultpaper object to the engraver, but that sucks.
> >
> > - there is a garbage problem:
> > programming error: Parsed object should be dead: static
> > scm_unused_struct* Prob::mark_smob(scm_unused_struct*)
> > How do people usually track this kind of issue? (I tried to
> > unprotect some
> > objects, but this last one is still missing).
>
> Both these problems are solved in the following patch.
> Do core developpers see a problem with it?
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
_______________________________________________
lilypond-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
