Hi David, > You want to write music as if it is for a single voice
A single *player*… > You are essentially writing polyphonic material (albeit, one voice is playing > rests at any one time.) That’s a valid, but non-intuitive, way of looking at it… I like your outside-the-box thinking! =) > do you expect the MIDI regions to work for these parts? I never use MIDI myself… but I would certainly expect (demand!) that any proper instrument-switching mechanism in Lilypond would Do The Right Thing™ viz-a-viz MIDI. > you will need different MIDI channels, different midi instruments. Note that one of the parameters of \addInstrumentDefinition is #’midiInstrument, i.e., the built-in mechanism already handles that. > Where does it end, by trying to pretend one staff can satisfy the needs of > more than one instrument? … as engravers have for hundreds of years!? ;) > I think that it is reasonable to ask that different voices be encapsulated in > separate variables. As discussed in this thread, there are many ways of doing this. Yours is yet another — and particularly clever — but it is no simpler (and in fact more complex in many ways) than others. > why not just model it logically from the beginning? Now *that* I agree with 100%. > you compose without thought for what instrument is going to be played, then > pick and choose in after the fact. No… I compose/arrange knowing *exactly* which instrument is going to be played, and that two or more of them will be played by a single player. (This is a standard technique in just about every musical genre: for example, in band and orchestral music, flute and clarinet players always have multiple instruments at the ready; in the music theatre pit, essentially every player except the strings play multiple instruments; in pop and jazz, the reeds often double, and the guitar almost always does; etc.) > how do you choose what notes to write, if you are unsure what instrument will > play them? As I said, you’ve misunderstood the process: I’m *always* sure ahead of time (i.e., at the moment of composition and/or arrangement) exactly which instrument will play the notes. > 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. You obviously haven’t seen any of my music. ;) > 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. Well, they’ll have to *note* what the new key is… “think” might be stretching it. > at the minimum, the composer should be required to also think for a few > seconds and supply the current key signature, as well. The *engraver* (not *composer*) should be required to do that… which is why Lilypond should do it automagically. > a design that doesn't require any considerations leads to people never making > those considerations. That’s a logical fallacy. > As such, I suggest an approach by modeling separate, well-defined variables > for each instrument, then use partcombine for the part. I think it’s definitely worth considering, despite the [much] greater effort on the part of the engraver. Note that for the *composer* and/or *arranger*, there is no extra effort in (between) any of these methods: the music is always (at least for proper discussion's sake) already created and ready for engraving. > I realize this does not fit your desired workflow, because you would have to: > Create separate variables for each distinct instrument This is a little extra effort, yes… Though I have to do this from time to time anyway. > Fill up the parts with spacer rests besides the sections each instrument > is being played Actually, \pushToTag would solve that. > Supply instrument change marks and key signatures at the point of > switching That’s the part that should be done automagically by Lilypond. > Besides these workflow issues, what things are not suitable with this > approach using partcombine and/or staff groups to model a multi-instrument > part? Staff groups wouldn’t work: if there is a very fast switch, it would force a certain format (i.e., where the breaks lie) onto the score. This would unnecessarily mix content with presentation, which we should avoid (at least, we should avoid the design *forcing* the user to mix C&P). Partcombine, on the other hand, is a very interesting option. I’ve been wanting to sponsor a Grand Unified Partcombine Project, Yay! (GUPPY) to fix the [myriad] problems with the current implementation — maybe this is the time to kill two birds with one stone! Because your suggestion doesn’t [fully] use \partcombine as originally intended/designed/coded (i.e., there will never be simultaneous notes), I’m not sure if any of its current idiosyncrasies will become stumbling blocks, or whether it’s ready to go as is; it will require investigation and testing. In any case, thank you so much for a very eye-opening suggestion! I look forward to playing around with your idea(s) and reporting back. Best, Kieren. _______________________ Kieren MacMillan, composer www: <http://www.kierenmacmillan.info> email: i...@kierenmacmillan.info _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
