[Top][All Lists]

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

Re: Deprecation of instrumentCueName and instrument switch stuffs

From: Jean Abou Samra
Subject: Re: Deprecation of instrumentCueName and instrument switch stuffs
Date: Wed, 14 Dec 2022 14:48:37 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1

Le 13/12/2022 à 10:55, Xavier Scheuer a écrit :

While replying to a query on the French-speaking list I realized that in
the latest versions of LilyPond the instrumentCueName property was
considered deprecated (as well as the engraver
"Instrument_switch_engraver", the grob "InstrumentSwitch" and the music
functions instrumentSwitch and addInstrumentDefinition).
Commit 5df7147b5977b010179bab53c2e077d559ec8ed7

This is a property that I commonly use (see typical example of my use
below) and I don't understand the rationale for removing it. Furthermore I
find promoting simple "catch-all" TextScripts (attached to an empty chord,
cf. NR 1.6.3) to indicate the instrument cue name a bad practice when you
can have a dedicated property and grob.
With a dedicated object it is cleaner, "modular" and future-proof: if you
want to adapt the size or font of all the instrument cue names you just
have to modify the properties of this object. With the approach promoted
now you have to search for all occurrences where you have induced the
instrument cue name with a TextScript and modify them.
So I agree that the old approach wasn't perfect (especially the mix of
instrument cue name and instrument switch, two uses for one
object/property/engraver), but in this case I'd rather have two properties
(instrumentCueName and instrumentSwitchName), objects (InstrumentCueName
and InstrumentSwitch) and engravers ("Instrument_cue_name_engraver" and
"Instrument_switch_engraver"), than remove everything!

Werner's commit merely documented a deprecation that had been
going on for much longer. The rationale is given here:

and I found this thread:

which shows pretty much the same story as what is happening
now, but 11 years ago.

I totally agree that the \instrumentSwitch and \addInstrumentDefinition
functions are useless. Just use variables. (Contrary to what its
name suggests, \instrumentSwitch isn't directly related to

Now, is the InstrumentSwitch grob useful? I don't know. On the
one hand, modern LilyPond provides more semantic grobs printing
text, like SectionLabel. On the other hand, SectionLabel is
special because it interacts well with \repeat segno. InstrumentSwitch
looks like it does nothing special at all compared to TextScript
or TextMark. There's no problem keeping the code future-proof
with generic grobs: define

cueName =
#(define-music-function (text) (markup?)
   #{ <>^\text #})


cueName = \tweak non-musical ##f \textMark \etc

with whatever tweaks you want, and later change the definition
if needed.

So, I don't see a lot of advantage to this grob. The message
sounds like not recommending the use of instrumentCueName
is a good thing. We could provide \instrumentSwitchText "abc"
to create an InstrumentSwitch, but it's not clear to me
that it would add value over the solutions above.


Attachment: OpenPGP_signature
Description: OpenPGP digital signature

reply via email to

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