Re: instrumentSwitch and addInstrumentDefinition use
From:
Flaming Hakama by Elaine
Subject:
Re: instrumentSwitch and addInstrumentDefinition use
Date:
Wed, 14 Jan 2015 15:43:47 -0800
On Wed, Jan 14, 2015 at 6:55 AM, Kieren MacMillan <address@hidden> wrote:
> > You want to write music as if it is for a single voice
> A single *player*…
A very interesting concept.
Trick question: where in lilypond is the concept of a 'player' modeled?
I've never quite found the right term for this.
'Player' isn't bad, although I would also suggest considering the following: 'folder', 'chair', 'stand' or 'desk'.
These refer more to a set of parts (from different pieces) that will be compiled together in a folder (normally, we might call this a 'book', but that name is already taken) and distributed to a stand within an ensemble. (Or, it might be used to indicate the person reading that material. As in, "she's the first chair oboist in the St. Something orchestra.")
In the case of most winds and brass, this is often one player per folder, in which case 'player' is rather appropriate. But for strings you usually have two players per stand, and with divisi, you might have different parts for different stands. So, the most complete definition might be chair + stand (like: Violin I, stand 2).
Part of the appeal of using staff groups to model this is that there is a property that names this collection of instruments that will be played by the same players, e.g. "Reed 2". This name is distinct name from any of the individual instruments that are actually active at a point in time.
> > 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. Does it produce one or several files from a single 'part' ?
> > 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!? ;)
Yes, but until this modern malady of considering "content" and "presentation" as being two distinguishable and separate things, there were no such existential issues. You just put ink on paper where you needed it. It was either comprehensible to the consumers, or it wasn't. It didn't matter what an arbitrary "model" said about it, nor did you have to trick the model into doing something it wasn't designed to do.
Some of our problems come because we've half-abstracted what we need, sometimes on the basis of "musical" concepts like notes, durations, etc. and sometimes on the basis of visual display like beams and double bars. Then we become a slave to this half-baked notion of "content", which is really a bouillabaisse of "music" and "formatting".
Especially in light of the philosophical debate, it seems to me that you are deliberately abstaining from modeling what needs to be modeled. You are intent on specifying neither content nor presentation, but rather facilitating the "engraver's" workload.
If two sets of notes are to be played by two different instruments, then you cannot expect to model them within the same structure, yet have them interpreted in different contexts. I am not saying that some syntactic sugar cannot be developed to allow the workflow you desire. It is just that you cannot go from syntactic sugar to presentation. I believe that we need to have a coherent model as an intermediate stage. Once we have that, we are left with two smaller and more solvable problems: translating your syntax into an accurate model, and then rendering the model appropriately.
> > 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 what I suspected. Which makes me wonder why using separate music variables is so especially maddening for you.
Does it not boil down to the following?
You already have a construct in which you are working, like:
reedTwoEverything = \relative c { ... }
And in the middle of it, you want to change to flue by typing (something like):
\changeInstrument "flute"
When instead you could type the following:
} reedTwoFlute = \relative c {
Is there something I'm missing about the scope of work involved in splitting a single _expression_ into several?
> > 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. ;) Sorry, but no matter how much good music you write (or engrave, since apparently I don't know the difference), unless you destroy everyone else's work, there will still be an overabundance of music with awkward, poorly-thought out transitions in the universe.
> > 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.
I guess I'm not entirely sure what the difference is these days.
Which is to say, I still think the composer is responsible for pointing out instrument changes, key changes, clef changes, etc.
What musical work does an engraver do that a composer doesn't?
> > a design that doesn't require any considerations leads to people never making those considerations.
> That’s a logical fallacy.
Maybe from a purely logical point of view. But we are not talking about logic, we are talking about lilypond. From a language design perspective, providing interfaces is the only mechanism we have to suggest, assist or influence behavior.
We can never compel people to do sensible things.
But we can choose structures and names that account for everything that needs to be considered. Until we do that, we cannot expect to have a usable feature.
> > I realize this does not fit your desired workflow, because you would have to:
> ...
> > Supply instrument change marks and key signatures at the point of switching
> That’s the part that should be done automagically by Lilypond. Here is where we disagree. Would you say that printing three sharps in response to "\key a \major" is "automagical"?
Specifying instrument changes seems similar in nature to writing "\key a \major". You are required to do it because it is something that, while it might be derived accurately some of the time, benefits from thought and consideration. Plus, an algorithm's best guess might be imperfect, and you need a way to override it or do it explicitly anyway.
I agree that, once the intention of when and what instrument change is specified, that everything that goes along with it (textual marking, clef, key signature) should be done without any additional work on the composer's/arranger's/engraver's part. But there is nothing magic about it. At least, no more magical than printing three sharps when you say "\key a \major".
> > 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).
On the one hand, I am curious to learn more about forced line breaks are when using staff groups--does \noBreak fail?
On the other hand, I would actually support an instrument switch feature that raised errors or warnings if there was such a case of insufficient visual or temporal space to effectively switch instruments. To me, this type of situation is a red flag that there likely isn't enough time for the instrumentalist to switch.
> 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.