Re: Engraver not getting an event

[David Kastrup]

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