Re: Deprecation of instrumentCueName and instrument switch stuffs

[Jean Abou Samra]

Le 13/12/2022 à 10:55, Xavier Scheuer a écrit :
> Hello,
>
> 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:

https://gitlab.com/lilypond/lilypond/-/issues/4078#note_339812107

and I found this thread:

https://lists.gnu.org/archive/html/lilypond-user/2011-10/msg00113.html

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
Instrument_switch_engraver.)

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 #})


or


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
https://lists.gnu.org/archive/html/lilypond-user/2010-10/msg00148.html
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.

Best,
Jean

OpenPGP_signature
Description: OpenPGP digital signature