Re: [PATCH] Clusters

[Han-Wen Nienhuys]

address@hidden writes:
> > >   Then, for protocol reasons, I removed this code and used
> > >   #(make-span-event ...) instead to create span requests.  This still
> > >   works, but the start and end point of the spanner are shifted;
> > >   e.g., if I say "... c d #(make-span-event 'ClusterEvent STOP) e f
> > >   g a b", the request refers to the "a" or "b".  This is especially
> > >   true, if polyphony like "<c d>" occurs shortly beforehand.
> >
> > that's strange. Can you give an exact example?
> 
> With the new "<< ... >>" syntax, it seems now to work.  Still, the cluster
> systematically stops one music event too early.  I fixed this with the
> attached patch.

Your patch looks like a kludge.

The real problem is that it does

     typeset_grob (cluster);
     cluster = 0;

from process_music(), which happens before the last notes are caught
in acknowledge_grob().  Move the typeset_grob() to
stop_translation_timestep(), and you should be fine. Look to other
spanner engravers for more inspiration.

Some other nitpicks:

  * member naming is inconsistent with the standards. Please use
    "member_" (note the final underscore.) instead of "member"

  * The engraver duplicates the mistake of the ambitus engraver,
    namely that it puts musical info (pitches) into the backend, all
    the more since all that is needed is the vertical difference in
    position between two note heads. Try
    Staff_symbol_referencer::staff_position() for getting the position
    of a head.

    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 [*]

(oh, btw, I'm probably sounding terribly grumpy. Sorry.  Clusters are
cool.)

> 
> > if you want to use #(..) in stead of \stuff, you have to use
> > ly:export, i.e.
> >
> >    note-#(ly:export (make-some-music .. ) )
> >
> 
> Ok, but currently, if I replace
> 
> startCluster = #(make-span-event 'ClusterEvent START)
> 
> in ly/spanners-init.ly with
> 
> startCluster = \notes {
>   #(ly:export (make-span-event 'ClusterEvent START))
> }
> 
> (which I expected to work analogous to the definition of e.g. "cresc")
> 
> then I get a parse error when trying to compile
> input/regression/cluster.ly.  Is this intended behaviour?

Yes. Events are syntactically different from Atomic_music objects;
Events (cluster-event, note-event, script-event, etc.)  can not be
used where notes are. Between \notes { .. }, you have to put notes,
rests, syllables, etc which have the form of EventChords,
i.e. something like

  startCluster = \notes {
    #(ly:export (make-request-chord (list
         (make-span-event 'ClusterEvent START))))
  }

then you can do

     \notes { c4 \startCluster d4 e4 }

but the \startCluster will happen after the C, simultaneously with the
start of the D.

If startCluster is an event identifier, you can do

  \notes { c4-\startCluster d4 e4 }

and the startCluster happens simultaneously with the C.  Jan insists
that without the dash it is easier to use, so we also allow

  \notes { c4 \startCluster d4 e4 }

to mean the same. As you can see, this is a little ambiguous, since it
means something different when \startCluster is a music identifier.
(I'm still uncertain whether this is an improvement)

> >        <unnamed port>:
> >        grob-property-description.scm: Can't find property: segments
> >        make[2]: *** [out-www/lilypond-internals.texi] Fout 2
> 
> Ooops, sorry for that.  Actually I hesitated compiling the full web site,
> since this takes many hours on my machine (mostly because of the mftrace
> stuff), and I can not run it over night, because my tetex installation
> (which is mounted via nfs due to lack of disk space), comes with an old
> texinfo version, and therefore I have an additional, newer version of
> texinfo installed locally, but since these two versions bite each other, I
> have to switch paths several times during compilation... (arrgh!)  But I
> will try anyway, next time.

You can download the PFA fonts assuming that the latest tarball built
correctly with the following script

        #!/bin/sh

        cd ~/usr/src/lilypond/mf/out
        for a in `ls -1 *.tfm `; do
          PFAF=`basename $a .tfm`.pfa
          echo $PFAF
        if [ ! -f $PFAF ] ; then 
           wget http://lilypond.org/development/mf/out/$PFAF >> pfa-log
        else
           ls -l $PFAF
        fi
        done

        for a in cmbx14 cmbxti7 cmbxti8 cmbxti12  cmbxti14 cmcsc7 cmcsc12 
cmtt17 cmbx17; do
               wget http://lilypond.org/development/mf/out/$a.pfa >> pfa-log
        done 

what I really mean, is that you should also build the internal
documentation. That's also done if you do

   make -C  Documentation/user/

-- 
Han-Wen Nienhuys   |   address@hidden   |   http://www.cs.uu.nl/~hanwen