Re: Tweaking notehead direction in chords

[Thomas Morley]

2012/12/20 Paul Morris <address@hidden>:
[...]
> I started work on editing it for the LSR (see attachment).  Having the 
> comments explaining the steps is really nice.  I thought it would probably be 
> good to comment out the test section and the music examples that go with it 
> to keep things focused and simple for people browsing the LSR.  I do like 
> keeping these tests in there since they will help people understand the code 
> and the problems that it solves.  What do you think?

We should provide a shorter example than my last.
I used the custom-note-heads only for advanced testings.
I'd prefer a double-line, though, above the original, below the tweaked version.

>
> Also, I noticed a small fine-tuning issue.  In the four note chords in the 
> last measure of the attached LSR example, the two offset E flat notes are not 
> exactly aligned with the A and C notes above them in either chord, if you 
> zoom in.  In the previous version they were fully aligned.  I haven't had a 
> chance to try and fix this yet.  Any thoughts on what needs to be adjusted 
> there?

Thanks for spotting this.

First I thought I had used a wrong value and yes, I did it wrong:
In the definition of `stem-x-corr´ I used (else stem-x-width), but it
should be (else (/ stem-x-width 2))

But this showed up another, greater problem:

(Starting from the basics)

(1) The common typesetting-practise:
Noteheads are printed to the left of a pointing-up-stem.
If it is not possible to add further noteheads to the left without
collisions, they are added to the right.
(There are some special rules which noteheads are printed on which
side of the stem, but these rules are of no interest for now)
For down-stems it's the opposite.

(2) LilyPond
So far so good and LilyPond _does_ it quite good.
Though, the amount of covering the stem-width isn't the same for left
and right printed noteheads.
For up-stems a left-printed notehead covers the whole stem-width but a
right-printed one only about the half (or two-thirds?).
Not sure about the reasoning.

Look at this example at high zoom.

\relative c' {
  \override NoteHead #'layer = #3
  <
   \tweak #'color #green
   \tweak #'layer #4
   ees
   \tweak #'color #red
   f
   \tweak #'color #magenta
   a
   \tweak #'color #cyan
   \tweak #'layer #5
   a
  >
}

I think there is no way to align moved noteheads left and right from
the stem _and_ to keep a correct 'stem-attachment in x-axis-direction
in all thinkable cases.
The y-value of 'stem-attachment has to be modified in several situations anyway.

(3) Solution
Apart from correcting the above mentioned wrong expression, I changed
\adjustStem.
It now requiers a pair as argument.
The car of it adds multiples of the stem-width to the x-default.
The cdr multiplies with the y-default (as before).

>
>> BTW, 'stem-begin-position doesn't exist in 2.14.2, but overriding
>> 'stem-attachment will work, if it is placed correctly.
>
> Huh, that's odd, as overriding 'stem-begin-position is working in the current 
> LSR version (2.14.2 -   http://lsr.dsi.unimi.it/LSR/Item?id=861).  Maybe you 
> meant it doesn't exist in 2.16?

No.
It _isn't_ part of 2.14.2. And it _is_ in 2.16.1
Don't know what the LSR does, but trying to compile a file using it,
with 2.14.2 returns:

GNU LilyPond 2.14.2
Processing `offset-note-heads-04.ly'
Parsing...
Interpreting music...
warning: cannot find property type-check for `stem-begin-position'
(backend-type?).  perhaps a typing error?
warning: doing assignment anyway

> Good to know that stem-attachment will work for chords.  I'll just need to 
> figure out the proper placement.
>
> Regards and thanks again,
> -Paul
>

Attached offset-note-heads-04-rev.ly

Would be very nice if you could have a look again. :)


Thanks,
  Harm

offset-note-heads-04-rev.ly
Description: Binary data