Re: instrumentSwitch and addInstrumentDefinition use

[Kieren MacMillan]

Hi David,

> 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’.

But (as you go on to point out) a “folder", “stand", or “desk" could certainly 
encompass more than one player — and “player” could [tautologically] not.

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

But why not just a Staff? Why is a StaffGroup either necessary or desirable?

> Does it produce one or several files from a single 'part’ ?

As I said, I never use MIDI… so I can’t answer that. (Maybe someone else 
reading can?) My intuition says that it’s a single track (= ‘part’?), where the 
channel and/or patch (= instrument) changes.

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

Agreed. But our new model is a **superset** of the old way — i.e., it has all 
of the capabilities of the previous method, with many additional powers and 
options. We shouldn’t hobble the new in order to mimic the old.

> we become a slave to this half-baked notion of "content", which is really a 
> bouillabaisse of "music" and "formatting”.

I don’t. For me it’s quite clear: “content” is the musical material without 
formatting, and “presentation” is the formatting. I could provide you a 
grob-by-grob breakdown into the two parts, but that’s hardly worth my time.

> You are intent on specifying neither content nor presentation, but rather 
> facilitating the "engraver's" workload.

While that is certainly part of what I’m trying to do — and, I offer, what we 
should *all* be trying to do — if that’s all you think I’m interested in, then 
I have poorly articulated my position.

> Which makes me wonder why using separate music variables is so especially 
> maddening for you.

Because it’s inelegant, and all things inelegant are especially maddening for 
me. =)

> You already have a construct in which you are working, like:
>    reedTwoEverything = \relative c { … }

As an aside, I am now 100% allergic to \relative mode: I believe we should 
avoid suggesting it to beginners, and possibly obfuscate it entirely in the 
documentation.

> Is there something I'm missing about the scope of work involved in splitting 
> a single expression into several?

Yes: in addition to splitting the code to begin with, you have to then 
recombine the code — what a waste, when you know in advance that it’s never 
going to be used separately!

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

Woe is me if I make decisions for myself based on the poor actions of others.

> What musical work does an engraver do that a composer doesn’t?

1. Makes all presentation-layer choices, including (but not limited to) font 
sizes, margins, page breaks, grob placement, titling, etc.
2. Often makes substantive changes to the visual appearance (e.g., substituting 
clefs) in order to make the piece more easily interpreted and played.

There are others, but those are the big ones.

> We can never compel people to do sensible things.

Here again is something on which we completely agree.  =)

> Would you say that printing three sharps in response to "\key a \major" is 
> "automagical”?

Partly: it is absolutely “automagical” if it shows three sharps in the piano 
part and five sharps in the part for clarinet in B-flat, without additional 
effort by the engraver/user.

> I am curious to learn more about forced line breaks are when using staff 
> groups--does \noBreak fail?

No… but one shouldn’t have to juggle breaking issues. Your idea of using 
\partcombine to put all of the music on a single Staff makes far more sense — 
and I have yet to see/hear a disadvantage (e.g., some situation handled by a 
StaffGroup that wouldn’t be handled equally well by a single Staff).

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

That completely depends on the tempo (composer’s realm), page margins 
(engraver’s realm), and a myriad other factors (in both realms): for example, 
if a page has six measures of 4/4 per system, and the last note on one 
instrument is the downbeat of the first measure, and the first note on the next 
instrument is the last beat of the sixth measure, and the tempo is 30 per 
quarter, there’s a gap of nearly 40 seconds, which is evidently more than 
enough time to switch comfortably.

In any case, I’ll be looking at your \partcombine suggestion and getting back 
to you some day soon. (Might be a while, though: right now I’ve got a two-act 
musical and four large classical commissions to compose and engrave in the next 
few months!)

Thanks,
Kieren.
_______________________

Kieren MacMillan, composer
www:  <http://www.kierenmacmillan.info>
email:  address@hidden