[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Chapter "Collision resolution"
From: |
Trevor Daniels |
Subject: |
Re: Chapter "Collision resolution" |
Date: |
Thu, 13 Jan 2011 14:08:16 -0000 |
David Kastrup wrote Thursday, January 13, 2011 12:47 PM
I've decided that this is not a restriction, but a bug. Here is
the
reason: when merge-differently-headed is set and three or more
notes are
in the note column, heads _are_ getting merged but get assigned
the
wrong notehead.
No, they're not. See what happens when \shiftOnn is
commented out in the example I send previously. I've
removed the first bar so you can see it more clearly:
\relative c'' {
<<
{
\mergeDifferentlyHeadedOn
% \shiftOnn
g'2 <fis d>
} \\ {
e,2 r
} \\ {
e8 a b c s2
}
>>
}
So this bug needs to be resolved either
a) completely by letting Lilypond pick the right notehead in this
case
b) by turning it into a restriction, namely not letting Lilypond
attempt
merging heads at all when there are too many of them
(b) is exactly what Lily does at present. See the example
above. As I explained earlier, the 'merging' you thought
you saw was simply the effect of bad source code causing
a collision of two noteheads.
I am taking a look at the code to figure out what happens and what
one
might want to do about this.
:)
Trevor
- Chapter "Collision resolution", David Kastrup, 2011/01/12
- Re: Chapter "Collision resolution", Trevor Daniels, 2011/01/12
- Re: Chapter "Collision resolution", David Kastrup, 2011/01/12
- Re: Chapter "Collision resolution", Trevor Daniels, 2011/01/12
- Re: Chapter "Collision resolution", David Kastrup, 2011/01/12
- Re: Chapter "Collision resolution", Trevor Daniels, 2011/01/12
- Re: Chapter "Collision resolution", David Kastrup, 2011/01/13
- Re: Chapter "Collision resolution",
Trevor Daniels <=
- Re: Chapter "Collision resolution", David Kastrup, 2011/01/13