[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 13:47:09 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
"Trevor Daniels" <address@hidden> writes:
> David Kastrup wrote Wednesday, January 12, 2011 4:23 PM
>
>
>> "Trevor Daniels" <address@hidden> writes:
>>
>>> LilyPond currently has a documented restriction that
>>> merging cannot take place if there are three or more
>>> notes in the same note column. Here there are three,
>>> so the third note has to be moved out to permit the
>>> first two notes to merge. See the Real music example
>>> in the Learning Manual where this is explained.
>>
>> Is there an insurmountable technical reason for this restriction? It
>> seems rather arbitrary.
>
> Well, I guess it's just because it's more difficult
> to handle than arbitrary, but I don't know. I'll
> have to hand further discussion over to those more
> familiar with the internals than I am.
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.
If it were merely a _restriction_, Lilypond would refrain from
attempting to merge the noteheads in this situation at all instead of
merging them with a bad result.
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
I am taking a look at the code to figure out what happens and what one
might want to do about this.
--
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 <=
- Re: Chapter "Collision resolution", Trevor Daniels, 2011/01/13
- Re: Chapter "Collision resolution", David Kastrup, 2011/01/13