> On 10 Mar 2015, at 02:14, Flaming Hakama by Elaine <ela...@flaminghakama.com>
> wrote:
>
>
> > BTW, I also tend to prepare lead sheets in F and A. Of course, you may not
> > need this. But if you are preparing a template, it might be helpful to
> > include other common transpositions.
>
> OK. The choice there is either to compile the file three times, adjusting
> \PieceTranspose in the sequence c c then c f then c a, or to make two more
> copies of the book-generating section, with (e.g.) \PieceTransposeFourth and
> \PieceTransposeSixth in between.
>
> This would make it all a bit unwieldy, and as I want to be able to share this
> with novice LilyPond users, I don?t want the make the file too long or too
> clever!
>
> Sorry if I was not clear. I wasn't suggesting that you transpose every piece
> to the keys of F and A, but rather to be able to produce lead sheets in those
> common keys as well:
>
> HornTranspose =
> #(define-music-function (parser location m)
> (ly:music?)
> #{ \transpose f, c $m #})
>
> AClarinetTranspose =
> #(define-music-function (parser location m)
> (ly:music?)
> #{ \transpose a, c $m #})
OK, I get you now.
I think such transpositions are sufficiently rare that they could safely be
“left as an exercise for the reader”; putting them all in would generate a lot
of unwanted parts.
If there were a conditional-compilation feature (as in “C”), like...
#DEFINE ALTOSAXPART
…
#IFDEF ALTOSAXPART
(do the alto part here)
#ENDIF
…then the user could suppress (for example) then French Horn part using…
#UNDEF FRENCHHORNPART
…but I think that overcomplicates what is intended to be a quick and easy way
for Lilypond novices to produce the standard set of leadsheets (for Concert, Bb
and Eb instruments).
>
>
> Granted, A clarinet isn't too common for Jazz, but it can't hurt. And as a
> clarinettist, I couldn't avoid the suggestion!
>
>
> > But below, instead of using \PieceTranspose everywhere (which kind of
> > defeats the purpose of doing something globally) I would suggest
> > transposing \TheChords and \TheHead and then using \TransposedChords and
> > \TransposedHead in the template:
>
> This comes to the same thing, but uses two extra variables.
>
> But I can see the advantage in doing this in terms of clarity if it comes
> immediately after the definition of the PieceTranspose function.
>
> Besides that, I think that variables help if they clarify things. In this
> case, it provides an explicit name for the result of "\PieceTranspose {
> \TheHead } “
Agreed, as do function calls - which I sometimes use knowing that only one call
is planned, not just to modularise the code and make it easier to debug at the
time, and also to understand what is going on when I come across the code some
years later!
>
> This introduce twos additional variables, but results in six fewer function
> calls.
It’s a matter of opinion which is clearer - we’re not talking about conserving
every last byte of memory and squeezing out every unnecessary CPU cycle from
the code.
>
> Also, if I understand your intentions here, users of this template will never
> have to modify the score blocks, or these variables. So, I don't see the
> down side of introducing them. If anything, they separate boilerplate code
> (that doesn't have to be modified) from the piece-specific code (which does).
>
> If part of your point is to make use of \transpose less fraught, I think you
> still have an issue, since
> users of this template still have to modify "\transpose c c" within that
> function. Something that might be more friendly:
>
> originalKey = c
> newKey = f
>
> PieceTranspose =
> #(define-music-function (parser location m)
> (ly:music?)
> #{ \transpose \originalKey \newKey $m #})
> That way, your users won't have to figure out which "c" in "\transpose c c
> $m" to adjust.
Excellent.
But further on, I prefer...
\TrumpetTranspose \PieceTranspose \TheHead
…to…
\TrumpetTranspose \TransposedHead
…because it is clear that \TheHead as originally defined is being transposed
twice.
No matter - whichever choice is made it will be in the “don’t touch if you
don’t know what you’re doing” section.
I’ll do some road-testing on some of my jam-session colleagues, and get
feedback.
Michael_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
