Re: Incipits

[Han-Wen Nienhuys]

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 <address@hidden>:
> > 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 - address@hidden - http://www.xs4all.nl/~hanwen