Kieren MacMillan <kieren_macmil...@sympatico.ca> writes:
> Hi David (et al.),
>
>>> No one picked up this one. Perhaps a way to tackle this problem would
>>> be to define specific contexts for the instruments that automatically
>>> have the right properties. It's worth reading through all the context
>>> properties to see which you should set.
>>
>> Huh, this sounds like a case for what \addInstrumentDefinition was for
>> (it's been undocumented because there really is no point in not just
>> defining a music expression doing the same).
>
> This is essentially the same problem that has been discussed many
> times before on this list (e.g. the long thread at
> https://lists.gnu.org/archive/html/lilypond-user/2014-05/msg00067.html). There
> is a need for a well-implemented instrument-definition and -switching
> mechanism which would automatically change all relevant context
> properties, handle transpositions and clef issues, etc.
>
>> \new Staff \with \bassclarinet { ... }
>> instead and put all the respective definitions in \bassclarinet .
>
> That sounds like it wouldn’t be applicable mid-score.
> Am I missing something in what you’re suggesting?
Uh, { ... \bassclarinet ... } ?
With something like
bassclarinet = {
\clef F
\transposition c,
\set Staff.midiInstrument = "clarinet"
\set Staff.instrumentCueName = \markup \bf "cl. B"
\set Staff.instrumentName = "bass clarinet"
\set Staff.shortInstrumentName = "bc"
}
you should fare reasonably well both per-Staff as well as in-Staff .
instrumentCueName would trigger a spurious cue name however I think: the
instrument cue engraver could be changed to ignore cue names set before
the first call of process-music.
--
David Kastrup
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
