Re: midstaff line = stem shortened?

[Carl Sorensen]

On 4/9/10 10:15 PM, "Mark Polesky" <address@hidden> wrote:

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

Ahh -- I missed these footnotes.  I'll review them when I can get my hands
on Ross again; tomorrow or the next day.
> 
> 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.
> 
OK.  I didn't mean to blame you for the problem...

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

As I read Ross, the 1/4 staff-space adjustment is what one would use if in
the midst of a note cluster (perhaps limited to a measure according to the
text explaining Example 1 and Example 2)  that contains the a, b, c, and d,
so we need to keep the stem progression moving.  If the cluster only
contains b, c, and d, then 2 1/2 works for the b.  And if the cluster only
contains a, b, and c, then 3 works for all three.

But maybe the suggested compromise gets it so close, with so little
difficulty, that we should just implement it and be done.

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

Well, when it comes to engineering and mathematics kind of stuff, I feel
like I can do just fine.  And I do OK on programming.  But I've not had
formal music training since 9th grade orchestra, so I'm basically entirely
self-taught on music.  I certainly enjoy it, but I'm nowhere near an expert.

But thanks for the kind words!

Carl