[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Chapter "Collision resolution"
From: |
David Kastrup |
Subject: |
Re: Chapter "Collision resolution" |
Date: |
Thu, 13 Jan 2011 16:11:57 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
"Trevor Daniels" <address@hidden> writes:
> 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.
Hm. Ok, thanks for the hint, it helps me to research this problem.
--
David Kastrup
- 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, 2011/01/13
- Re: Chapter "Collision resolution",
David Kastrup <=