David Kastrup wrote
> I am leaning towards redefining
>
> clef =
> #(define-music-function (parser location type) ((string?))
> (_i "Set the current clef to @var{type} if specified,
> or force a repetition of the current clef when @code{\\default}
> is given instead.")
> (if type
> (make-clef-set type)
> #{ \set Staff.forceClef = ##t #}))
>
> which then would allow using \clef \default.
Good idea. Thinking about the wording, what about \clef \current instead?
I see that \default already works here, although I don't know why. (I
couldn't find \default in the manuals.) One reason \current is clearer is
that the "default" clef when a clef is not specified is always the treble
clef. Anyway, just something to consider.
David Kastrup wrote
> I think it would be more consistent if this would _not_ imply a
> full-size-change as well.
I agree, and it would also be more flexible since you could still do:
\once \override Staff.Clef #'full-size-change = ##t
\clef \default
Here's something else to consider. Should the following display the second
bass clef?
{
\clef bass
c1
\clef bass
c1
}
For example, I can see users asking "Why do I have to use \clef \default?
Why can't I just enter \clef bass again? Why doesn't \clef always display a
clef?"
Hmmm... are there any cases where you'd want to enter \clef ... but not
display a clef? (I realize that changing this behavior would entail more
significant code changes than \clef \default.)
Cheers,
-Paul
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/get-and-print-current-clef-tp162925p162928.html
Sent from the User mailing list archive at Nabble.com.
_______________________________________________
lilypond-user mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-user
