[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Engraver not getting an event
From: |
David Kastrup |
Subject: |
Re: Engraver not getting an event |
Date: |
Tue, 02 Apr 2019 14:15:41 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Aaron Hill <address@hidden> writes:
> 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?
scm/define-music-types.scm defines the iterator-ctor to use if not the
default. And the default is
Music_iterator::get_static_get_iterator (Music *m)
{
Music_iterator *p = 0;
SCM ctor = m->get_property ("iterator-ctor");
SCM iter = SCM_EOL;
if (ly_is_procedure (ctor))
{
iter = scm_call_0 (ctor);
p = unsmob<Music_iterator> (iter);
}
else
{
if (dynamic_cast<Music_wrapper *> (m))
p = new Music_wrapper_iterator;
else if (m->is_mus_type ("event"))
p = new Event_iterator;
else
p = new Simple_music_iterator;
iter = p->self_scm ();
p->unprotect ();
}
p->music_ = m;
assert (m);
p->music_length_ = m->get_length ();
p->start_mom_ = m->start_mom ();
return iter;
}
> Is it something like the outer container of EventChord trumping the
> contained NoteEvents?
It's not a matter of "trumping". Only the outermost music expression is
iterated. Its own iterator may decide to do iteration of some contents.
> But then why does the same not apply to SimultaneousMusic or
> SequentialMusic?
It does. Those are pretty complex iterators exactly because they need
to coordinate when to create/call iterators for their contained
expressions.
>> 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.
Well, it may need information regarding the respective grob placements
in order to place the articulations in relation to them.
> 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.)
It depends on what you want to achieve. The string number engraver does
just that. Historically (before the advent of the
Rhythmic_event_iterator) that implied that only in-chord notes could get
string numbers.
--
David Kastrup