Re: [PATCH] Clusters

[Juergen Reuter]

On Sun, 17 Nov 2002, Han-Wen Nienhuys wrote:

> ...
> > 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?
> >
>
> The list is pruned automatically. This happens for slurs and various
> other spanners as well. Besides, columns_scm happens in interpreting,
> which is well before linebreaks are calculated.
>

Ok, I didn't know that.

> ...
> I would think that the list of note-head grobs would be broken up into
> chunks containing the note heads that belong to the same column. Then
> you can take the minimum and maximum Y coordinate for each chunk, and
> run the polygon through all minimums first, and then through all
> maximums.
>

Agreed, this should work for the way the cluster engraver is currently
implemented, i.e. assuming that min and max are being reset at each
time-step, but ...

> I don't understand your argument about minimums and maximums, since
> min and max are being reset at each time-step. Storing the noteheads
> at each time step gives just as much information.

... exactly, that's the point: my argument does not hold for the current
implementation, but I want to keep it open for a more advanced future
implementation of the engraver that does *not* reset min and max at each
time-step, but also considers note durations.  Example:

\startCluster < f2 { a4 g } > \stopCluster

currently gives the same result as:

\startCluster < f4 { a4 g } > \stopCluster

which is musically wrong.  It rather should give the same result as:

\startCluster < { f4 f } { a4 g } > \stopCluster

I.e. a future advanced implementation should also consider duration of
notes.  But this obviously should not be done in the backend, and that
means that the additional dummy note head "f" has to be inserted, e.g. by
the engraver.  Maybe this could be done by some sort of preprocessing upon
the music input, but this sounds rather hairy, and it might have
unexpected side effects upon other engravers that take notice of this
additional dummy note.

If, instead, the engraver computes pitch differences and passes them
(rather than note head grobs) to the backend, no dummy note heads will
have to be created and no such side effects will occur.

Maybe another (but also ugly) solution is to pass at most one note head
grob per timestep to the backend that serves as reference point to compute
x/y coordinates, and an associated extent property that specifies the
vertical extent of the polygon relative to the given note head.

Greetings,
Juergen