lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Add tab-tie-follow-engraver (issue2723043)


From: David Kastrup
Subject: Re: Add tab-tie-follow-engraver (issue2723043)
Date: Sat, 13 Nov 2010 11:23:25 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Carl Sorensen <address@hidden> writes:

> On 11/13/10 2:01 AM, "David Kastrup" <address@hidden> wrote:
>
>> address@hidden writes:
>> 
>>> OK, so now I've eliminated the triple nested loop.
>>> 
>>> There is what appears to me to be a required nested loop.
>>> 
>>> One loop to loop through the note-heads.
>>> Then an inner loop (with a break) through the ties looking for a tie on
>>> a note head.
>>> Followed by a second inner loop (with a break) through the slurs looking
>>> for a slur on the note head.
>>> Followed by a third inner loop (if we didn't find a slur) through the
>>> glissandos looking for a glissando on the note head.
>>> 
>>> I can think of no way to simplify this code further.  If you have any
>>> ideas I'd be happy to hear them.
>> 
>> It's not a simplification, but the usual manner to find multiple
>> associations and deal with them is sorting.
>
> Thanks for the idea.
>
>> You sort the noteheads according to some criterion, and use the same
>> criterion for sorting the other data structures according to their
>> notehead anchors.  Then you have three lists, and you work off the
>> notehead list, checking its current head with the other current heads,
>> advancing the other lists when their heads get behind, and treating the
>> association when the heads match.
>
> I'd thought about doing this.  But I'm not aware of any criteria that
> one could use for sorting in this particular case.  I'm not aware of
> any index or property the grobs have that is sortable.

With non-compacting garbage collection, memory address of grob is a
perfectly fine, if arbitrary, criterion.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]