lilypond-user
[Top][All Lists]
Advanced

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

Re: Notating same part in two different mixtures of clefs


From: David Kastrup
Subject: Re: Notating same part in two different mixtures of clefs
Date: Wed, 16 May 2012 10:56:07 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

Urs Liska <address@hidden> writes:

> No you don't have to edit the ly-file.
> You can write sth like:
>
> music = { ... }
>
> myClefI = { \clef tenor }
> myClefII = { \clef bass
>
> \score ... % references \music
>
> % and then redefine the variables
> myClefI = { \clef treble }
> myClefII = { \clef bass
>
> \score ... % references \music
>
> If your clef layers are independent (as I assume) you could define
> four variables trebleClef, altoClef, tenorClef, bassClef and leave two
> of them empty.
>
> music = {
>   % contains all four clefs as references.
>   % If you have e.g. alto and bass clef at the same time you write
>   % \altoClef \bassClef
> }
> % define clefs for first score
> trebleClef = {}
> altoClef = {}
> tenorClef = { \clef tenor }
> bassClef = { \clef bass }
>
> \score { \music } % in this score the treble and alto clefs are just
> ignored
>
> %then define the clefs the other way roung
> % ...
>  \score % now the tenor and bass clefs are ignored.
>
> I find this solution looks nicer than with tags, but the functionality
> is nearly identical.

Not quite.  It does not work, which is an important difference.  It will
actually already bomb out when defining "music" because \xxx references
are expanded when encountered.  If you want delayed action, you could
make a music function
music =
#(define-music-function (parser location high low) (string? string?)
  #{  ... ... \clef #high ... ... \clef #low ... ... #})

{ \music tenor bass
  \music alto tenor
}

However, as compared to the tag solution, the music is here indeed being
parsed twice, once for every call of \music.  So the tag solution is
likely to be faster.

> I have come to find the redefinition of variables a _very_ useful
> concept.

Sure, but redefining them after they have already been used is not all
that helpful.

-- 
David Kastrup




reply via email to

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