lilypond-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] Clusters


From: Juergen Reuter
Subject: Re: [PATCH] Clusters
Date: Sun, 17 Nov 2002 22:14:58 +0100 (CET)

On Sat, 16 Nov 2002, Han-Wen Nienhuys wrote:

> ...
>    Better yet, simply store a list of note heads in the cluster grob,
>    and let the Cluster grob sort out X and Y-positions. [*]
>
>  * The contents of columns_scm are not protected from Garbage
>    collection. Your code will make mysterious ugly crashs on larger
>    scores. Use Protected_scm, or better yet, use [*]

If I put all note heads in the cluster grob, then, if the spanner is
broken, how do I determine which of these note heads are in the current
broken piece of the spanner, if not using columns_scm?

Another difficulty is that constructing a polygon from a given set of
points is ambigous, even with the constraint that edges do not intersect,
e.g.:

f               e
       b
a       c       d


a-b-c-d-e-f-a and a-c-b-d-e-f-a are both polygons with no intersecting
lines.  To circumvent this ambigous situation, I currently produce pairs
of min/max pitches, such that I get to additional points, let's say B and
C:

f      BC       e
       b
a       c       d

(Actually, in this particular example, the current implemetation would
choose B=b anc C=c rather than Bx=bx, By=fy, Cx=cx, Cy=fy, as indicated in
the above figure.  But this is anyway a musical decision, since it has
to consider musical time and/or note durations (with the latter
currently not being considered by the engraver), and therefore is
definitely something not to be put into the backend.)

The addditional points B an C as synthesized by the engraver now give me
pairs (a,f), (b,B), (c,C), (d,e), and the polygon is now uniquely defined
by travelling through the first element of each pair (from the leftmost
pair to the rightmost), then through the second element (from right to
left) back to the first, i.e. a-b-c-d-e-C-B-f-a.

I do not have this information in the backend if I use note heads instead
of pitches, unless I create additional dummy note heads for B and C, that
just serve for storing x/y coordinates (and possibly may corrupt other
things such as ties or midi output?).  Should I really do such a hack?

In other words, the shape of the polygon is not determined by the
coordinates of a set of note head grobs.  Rather, I think a set of min/max
pairs has to be computed by musically interpreting note-events and be
passed to the backend.  Of course, I do not need to pass pitches to the
backend, but may pass rather the difference in pitch (i.e. height).

Greetings,
Juergen





reply via email to

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