lilypond-user
[Top][All Lists]
Advanced

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

Re: Engraver not getting an event


From: Aaron Hill
Subject: Re: Engraver not getting an event
Date: Tue, 02 Apr 2019 04:59:59 -0700
User-agent: Roundcube Webmail/1.3.8

On 2019-04-02 4:26 am, David Kastrup wrote:
Aaron Hill <address@hidden> writes:
Where have I gone wrong in my thinking?

_Either_ the Event_chord_iterator _or_ the Rhythmic_music_iterator are
doing the broadcasting of note events, depending on whether the notes
are within a chord or not.  _Only_ the Rhythmic_music_iterator
broadcasts articulations, so they are _only_ removed and broadcast for
non-chord notes, and actually only if there is a listener for them,
otherwise they are kept on the rhythmic event like articulations on
chord notes _always_ are.

Huh, I was so sure I saw recursion in the broadcasting of events. I need more coffee and/or sleep. :/

Out of curiosity, how does Lilypond decide which iterator-ctor to consult and instanciate? Is it something like the outer container of EventChord trumping the contained NoteEvents? But then why does the same not apply to SimultaneousMusic or SequentialMusic?

If you want to do anything with chord note articulations, you have to
listen for the chord notes and look at their articulations property.

Is there a best practice between listening for events vs. acknowledging grobs? I noticed that New_fingering_engraver--which needs to handle articulations within chords--opts to acknowledge rather than listen.

Also, it does seem that special care would need to be taken to unify the results of handling events that are broadcast vs. the ones that need to be wrestled from the clutches of chords. Or, would it be more appropriate (read: sane) to never listen directly to such post-events and instead just listen for the rhythmic-events, querying their articulations as appropriate? (The latter seems like it could be inefficient.)


-- Aaron Hill



reply via email to

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