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: i...@kierenmacmillan.info
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
