On Wed, Jan 14, 2015 at 6:55 AM, Kieren MacMillan <
kieren_macmil...@sympatico.ca> 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.
I'm glad you took this in a positive spirit.
Glad to hear it moves the conversation forward.
David Elaine Alt
415 . 341 .4954 "*Confusion is
highly underrated*"
ela...@flaminghakama.com
self-immolation.info
skype: flaming_hakama
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
