lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch] first-clef property


From: Nicolas Sceaux
Subject: Re: [patch] first-clef property
Date: Sat, 2 Feb 2008 11:29:21 +0100


Le 2 févr. 08 à 01:48, Juergen Reuter a écrit :

Hmmh, maybe I do not understand correctly, but wouldn't it be possible to get equivalent behavior with tagged music? I mean, put both \clef commands ('\clef "soprano"' and '\clef "treble"') into the code, put different tags on each of them, and then "turn" them "on/off" or switch between the two editions by filtering the music for the proper tags.

\tag does not solve the first-clef detection problem, but the two editions
problem, about which the proposed patch is not about. I know about \tag,
and also that in the end one have to use \removeFromTag or \keepWithTag.
After years experimenting with that, I don't find it very practical when
applied to clef, because of its verbosity. Less LilyPond instructions
==> more maintainable. And I have many thousands of LilyPond loc to
maintain.

Anyway, wouldn't it be nicer to have some kind of scheme macro that expands to code that prints an incipit? Your "first clef" could then be just part of the incipit that the macro creates. And maybe the clef's name either could passed as argument to the scheme macro. Or, alternatively, you set an, say, "original-clef" property that the macro recognizes and accordingly acts upon.

As I understand it, incipits are hackingly achieved using the
instrument name. I want instrument names to be defined separately
from incipit (they are not the same thing, there is no serious
reason to bind them, beside purely technical ones):

\new Staff <<
  \global
  \set Staff . instrumentName = \markup { The instrument name }
  \clef "xyz" %% automagically set the incipit clef
  { ... the notes ... }
>>

How could you make the mix of the two?

Now, seeing the incipt examples, I realize that my patch is a hack
too, for it would be nice to have also the time and key signatures,
not only the ancient clef.

Maybe creating an incipit engraver, reading new context properties,
like incipitKeySignature, incipitTimeSignature, etc, and creating a
grob of the same nature as the instrument name.

nicolas





reply via email to

[Prev in Thread] Current Thread [Next in Thread]