lilypond-user
[Top][All Lists]
Advanced

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

Re: instrumentSwitch and addInstrumentDefinition use


From: Flaming Hakama by Elaine
Subject: Re: instrumentSwitch and addInstrumentDefinition use
Date: Tue, 13 Jan 2015 22:28:04 -0800


From: Kieren MacMillan <address@hidden>
To: Keith OHara <address@hidden>
Cc: Lilypond-User Mailing List <address@hidden>
Subject: Re: instrumentSwitch and addInstrumentDefinition use


Hi Keith,

> I understand that in realistic cases you probably have the notes in one variable and options for arrangements in another parallel sequence
>  flute_notes = {c'2 c'' .... }
>  arrangementB = {s1*4 \prep_alto_flute s1*4 \switch_alto_flute s1*8 }
> and it is not so convenient to break flute_notes into segments for the individual \transpose{}s.

Correct on both counts.
(n.b. I *do* break flute_notes up when absolutely necessary? but I definitely wouldn?t call it ?convenient?.)


On the one hand, I applaud your efforts to write for multi-instrumentalists!

However, I would call this desire (for artificial convenience) somewhat unfounded:  You want to write music as if it is for a single voice, yet have it be rendered by two separate instruments.  You are essentially writing polyphonic material (albeit, one voice is playing rests at any one time.)  Would you expect to be able to that with polyphony within a single music variable?  Not without extra << { } \\ { } >> constructs, anyway.  And yet you not only want to do that, but you want these voices transposed differently!

Furthermore, do you expect the MIDI regions to work for these parts?  If so, you will need different MIDI channels, different midi instruments.  Where does it end, by trying to pretend one staff can satisfy the needs of more than one instrument?

So, I think that it is reasonable to ask that different voices be encapsulated in separate variables.


Through various iterations of hacks, Lilypond gets somewhat close to what you want.  But, rather than going down the rabbit hole of competing and nested engravers, looking up contexts that may or may not have what we need to pull this off, etc. why not just model it logically from the beginning?

Which is to say, set up a music variable for each instrument and then use partcombine (several times if necessary).  See below for an example.


I guess I don't have enough sympathy for your desired shortcut whereby (if I understand correctly) you compose without thought for what instrument is going to be played, then pick and choose in after the fact.  (Incidentally, how do you choose what notes to write, if you are unsure what instrument will play them?  Don't you have to fiddle with octave transpositions and adjusting dynamics when you take this approach anyway?  Why is that less arduous than simply writing or copying/pasting the material from one variable to another?)

As a multi-instrumentalist, I've seen way too many arrangements where the composer has not put in enough thought into providing suitable rest to actually switch instruments (most recently in das trunke lied).   Or, not indicating at the top of the part all the instruments that will be needed.  Or, omitting clefs or key signatures when there is a change, etc. 

When an instrumentalist has to switch, especially to an instrument in a different transposition, they will necessarily have to think about what the new key is.  It seems that, at the minimum, the composer should be required to also think for a few seconds and supply the current key signature, as well.

By the way, I'm not suggesting that you pay insufficient attention to these things in your work.  Only that a design that doesn't require any considerations leads to people never making those considerations. 


As such, I suggest an approach by modeling separate, well-defined variables for each instrument, then use partcombine for the part.

Below is a (contrived) example of what I would suggest.  This is probably nothing new to you, yet it seems to do a majority of what someone would want, out of the box.

I realize this does not fit your desired workflow, because you would have to:
    Create separate variables for each distinct instrument
    Fill up the parts with spacer rests besides the sections each instrument is being played 
    Supply instrument change marks and key signatures at the point of switching

This suggestion also doesn't do everything I would want, either.  But it requires zero lilypond development and I think it covers everything a composer would need, in terms of output.  I think that the overhead is pretty modest, although I realize that it may not suit all compositional workflows.


Besides these workflow issues, what things are not suitable with this approach using partcombine and/or staff groups to model a multi-instrument part?



\version "2.18.0"

flute = \relative c'' {
    \compressFullBarRests
    \mark "Flute"
    \key d \major
    a4 a a a |
    R1*7 |
    s1 |
    s1*7 |
    s1 |   
}

clarinet = \relative c'' {
    \compressFullBarRests
    \key d \major
    s1 |
    s1*7 |
    \mark "Clarinet in A"
    \key d \major
    a4 a a a |
    R1*7 |
    s1 |   
}

tenorSax = \relative c'' {
    \compressFullBarRests
    \key d \major
    s1 |
    s1*7 |
    s1 |   
    s1*7 |
    \mark "Tenor Sax"
    \key d \major
    a4 a a a |
}

tubaLick = \relative c {
    d2 d | fis, fis | g g | a r  \break
}
tuba = \relative c {
    \clef bass
    \key d \major
    \tubaLick
    \tubaLick
    \tubaLick
    \tubaLick
    d d |
}

transposedFluteClarinet = \relative c {
    \partcombine
       \transpose c c { \flute }
       \transpose a, c { \clarinet }
}

transposedReedTwo = \relative c {
    \partcombine
       \transposedFluteClarinet
       \transpose bes,, c { \tenorSax }
}

\layout {
  \context {
    \Staff \RemoveEmptyStaves
  }
}

#(define output-suffix "Score-concert")
\book {
  \score { <<

    \new StaffGroup = "Reed 2" <<
        \new Staff {
            \set Staff.instrumentName = #"Flute"
            \set Staff.shortInstrumentName = #"Fl."
            \transpose c c { \flute }
        }
        \new Staff {
            \set Staff.instrumentName = #"Clarinet"
            \set Staff.shortInstrumentName = #"Cl."
            \transpose c c { \clarinet }
        } 
        \new Staff {
            \set Staff.instrumentName = #"Tenor Sax"
            \set Staff.shortInstrumentName = #"Ten."
            \transpose c c { \tenorSax }
        }
    >>

    \new StaffGroup = "Brass" <<
        \new Staff {
            \set Staff.instrumentName = #"Tuba"
            \set Staff.shortInstrumentName = #"Tba."
            \transpose c c { \tuba }
        }
    >>

  >> }
}

#(define output-suffix "Score-transposed")
\book {
  \score { <<

    \new StaffGroup = "Reed 2" <<
        \new Staff {
            \set Staff.instrumentName = #"Flute"
            \set Staff.shortInstrumentName = #"Fl."
            \transpose c c { \flute }
        }
        \new Staff {
            \set Staff.instrumentName = #"A Clarinet"
            \set Staff.shortInstrumentName = #"A Cl."
            \transpose a, c { \clarinet }
        } 
        \new Staff {
            \set Staff.instrumentName = #"Bb Tenor Sax"
            \set Staff.shortInstrumentName = #"Bb Ten."
            \transpose bes,, c { \tenorSax }
        }
    >>

    \new StaffGroup = "Brass" <<
        \new Staff {
            \set Staff.instrumentName = #"Tuba"
            \set Staff.shortInstrumentName = #"Tba."
            \transpose c c { \tuba }
        }
    >>
  >> }
}


#(define output-suffix "Part-Reed-2")
\book {
  \score {
    \new StaffGroup <<
      \set StaffGroup.instrumentName = #"Reed 2"
      \new Staff {
        \set Staff.printPartCombineTexts = ##f
        \transposedReedTwo
      }
    >>
  }
}


HTH,

David Elaine Alt
415 . 341 .4954                                           "Confusion is highly underrated"
address@hidden
self-immolation.info
skype: flaming_hakama
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

reply via email to

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