Re: GSoC spanners project

[David Kastrup]

Nathan Chou <address@hidden> writes:

> Hello,
>
> I have somewhat looked at the code and want to confirm my
> understanding of the current behavior:
> * While the file is parsed in Scheme, spanners cause a START and STOP
> event with an appropriate type to be created in the context they
> belong to

Ties are also spanners but don't have a STOP event.  It might be
feasible to create the equivalent of a STOP event for them if it turns
out necessary.

>     * After creation of the Music objects, where are they stored?

Where they belong.  Most objects are part of other music expressions.
Every score has one top-level music expression.

> Do iterators go through events from the same place?

I have no idea what that means.

> * Event iterators are eventually created and processed, causing the
> spanner events to be dispatched to their contexts

More or less.

> * Engravers listen for event types they are interested in using
> IMPLEMENT_TRANSLATOR_LISTENER (which I don't really understand at the
> moment)

IMPLEMENT_TRANSLATOR_LISTENER produces some startup code that enters a
given member function of a translator into once-per-type alists (static
member containing a list of callbacks).  I'm currently working on making
this a bit more C++-like instead of using C macros but it won't get
significantly easier to understand I think.

> * As an engraver processes events, it creates spanners with
> make_spanner, which ultimately calls internal_make_grob and
> announce_grob

Something like that.

> Assuming this is correct, I believe I would need to think of ideas for
> engravers to be able to receive events outside of their context. Any
> suggestions or things I should keep in mind?

Engravers can already change their contexts with context-change events.
I don't think that this is quite what you want however.  Grobs/spanners
may be announced to a context different from the context of the original
engraver (see announce_grob and announce_end_grob and their optional
argument).

Slurs/Phrasing slurs have a labelling mechanism allowing multiple
spanners in parallel under control of the same engraver.  Maybe the
machinery should made be more generic so that it works for more than
slurs.  Or it should be replaced by some mechanism that can easily
create extra engravers on the fly.

There are a few valid approaches.  The important thing is to figure out
something that's reasonably easy to make work by the programmers of
engravers as well as easy enough to work with for users.

-- 
David Kastrup