lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: midstaff line = stem shortened?


From: Mark Polesky
Subject: Re: midstaff line = stem shortened?
Date: Fri, 9 Apr 2010 21:15:53 -0700 (PDT)

Carl Sorensen wrote:
> Mark, thanks for putting this together.  I think this
> really helps us have something to discuss.
>
> I'm not sure what you mean by "Ted Ross optional". I'm
> guessing that's your interpretation of how he would handle
> things as implemented in his exceptions (Examples 1 and
> 2).
>
> As I read Ross, the stem lengths I quoted before are for
> standalone stems. I don't see any discussion of "optional"
> stem lengths.

I'll try to explain my interpretation: The footnote at the
bottom of p.85 says:
  "* These stems are quite often more effective at 3 1/4
  spaces." (\stemUp a' \stemDown b' c'')

Of the 5 red notes in "Ted Ross optional", these are the
first, third and fourth.  I put a question mark next to the
third (\stemDown c'') because I can't see any conceivable
logic behind it.  Perhaps the asterisk over the c'' at the
bottom of p.85 was a mistake?  (There are other mistakes in
the book, so it's a possibility).

The third staff-example on p.86 is also given a footnote:
  "* These notes could possibly be 3 spaces."

Unfortunately, none of the notes are marked with an
asterisk, but since he writes "notes" (plural), I
conservatively assume that only two notes are missing an
asterisk.  The only two notes that could conceivably be
extended (from 2 1/2 to 3 spaces) are the first of each
group (\stemup c'' \stemDown g').  Of the 5 red notes in
"Ted Ross optional", these are the second and fifth.  I've
also put a question mark because using a 3-space stem
inexplicably breaks the continuity (which I've evened out in
the "suggested compromise").  Perhaps it's a stretch, but I
wonder if instead of "3 spaces", he should have put "2 3/4"?

Obviously the strength of my argument depends on assuming at
least three significant textual errors in Ross's book, but
I'm just trying to keep it logical.  Another potential
problem with my approach is that (perhaps) I'm rushing too
quickly to a compromise because it hurts my brain to think
about actually implementing all of his suggestions exactly
(like extending the snare drum stems only if unbeamed eighth
notes are nearby).

> In your Ross standard line, there's a problem...
> [...]
> In your Ross optional line, you've fixed the problem
> between a and b going up.  You've also fixed the problem
> between b and c going up.  But you've created a problem...

Well, I haven't fixed or created any problems, Ross has.
The top two lines are just a summation of Ross's rules.

> As you correctly point out, LilyPond violates the Ross
> standard at c with the up stem and b with the downstem.
> That should probably be fixed.

Yes.

> I think your suggested compromise is a good suggestion,
> but that it should be used not as a default stem length,
> but instead as a stem length adjustment when the adjacent
> note is one that requires an adjustment (i.e.  shorten a
> with an upstem when it's adjacent to a b; lengthen c with
> an upstem when it's adjacent to a b; shorten b with a
> downstem when it's adjacent to an a; lengthen g with a
> downstem when it's adjacent to an a).

Yes, that would be the ideal solution.  All I would add to
this is that the adjustments are 1/4 of a staff-space (0.5
units when using Stem #'length).  Before I forget, this is
presently a source of confusion since Stem #'length units
are *staff-degrees*, not staff-spaces as stated in the IR.

> We already have code to adjust the horizontal spacing when
> we have alternating stems, so there is some music
> adjustment based on adjacent stems.  I'd prefer to see us
> make the adjustment only when necessary, rather than as a
> general rule.  But I think it would be better to use the
> suggested compromise than to stick with the current
> LilyPond behavior.

Agreed.

> But remember, I'm probably the least accomplished musician
> in the LilyPond community, so my arguments might not be
> worth anything.

Oh, the modesty!  Your input is quite valuable indeed.
- Mark


      




reply via email to

[Prev in Thread] Current Thread [Next in Thread]