Re: GSoC spanners project

[Nathan Chou]

Hello,

Thank you for the information! I have been thinking more and a few
questions have come to mind:

* However the cross voice Spanner object is created, is it expected to
be identical to the object currently created by the hidden voice
workaround? Just to make sure, Spanners are Grobs, which only contain
graphical information and aren't associated with a context, right?

* Although it is possible to deliver the STOP spanner event to the
engraver of the corresponding START event (e.g. if the spanner has an
ID to match the START and STOP events), is this an undesirable
solution because it basically does the same thing as the hidden voice
workaround?

Thanks again!

Nathan

On Mon, May 16, 2016 at 12:50 AM, David Kastrup <address@hidden> wrote:
> 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