Broadcast articulations not in EventChord

Broadcast articulations not in EventChord
This is in preparation for issue 2070.
Should not cause any differences in output with current parser.

[MikeSol, 2012-01-17 17:42:38]

I would advise not handling it this way - the function to_event is supposed to
take music and return an event.  In this patch, it is taking music, returning an
event, and maybe broadcasting music and/or sending it to a context.

I'd recommend creating a new iterator, rhythmic-music-iterator, that inherits
from Simple_music_iterator.  Have this be the constructor for the NoteEvent and
RestEvent (iterator-ctor).  Then, in this iterator, duriing process_music, have
something that looks at an "articulations" callback of the iterator.  This
callback would handle the articulations list, much like the "elements-callback"
handles the elements list (see the sequential-iterator).  This is more in
keeping with the way the code is written and would make it easier to
follow/debug.

Cheers,
MS

[MikeSol, 2012-01-18 11:39:18]

I still think this patch goes outside the model of the way these things are
usually designed in LilyPond.  I'm not saying that LilyPond's design paradigm is
objectively good or bad (I truly have no idea, as I know nothing about any other
piece of software), but I think it's best to follow it whenever possible.

Currently, this patch is making a modification to music-iterator, the base class
from which all others inherit.

Normally, be it an iterator, engraver, or grob, whenever a new functionality is
needed in LilyPond, a new X is created (where X is iterator, engraver, or grob).
 There are only a few rare cases where the base class has to be modified (i.e.
adding color to a grob, which effects every grob).

I'll send you a sketch of a patch that's more in line with the way these things
are coded in the current LilyPond style.  There's no guarantee that it'll work,
but it'll give you an idea of how to modify this one.

Cheers

[dak, 2012-01-18 11:40:58]

On 2012/01/17 17:42:38, MikeSol wrote:
> I would advise not handling it this way - the function to_event is supposed to
> take music and return an event.  In this patch, it is taking music, returning
an
> event, and maybe broadcasting music and/or sending it to a context.
> 
> I'd recommend creating a new iterator, rhythmic-music-iterator, that inherits
> from Simple_music_iterator.

I have reduced the impact on strange areas: it is now just send_to_context and
its caller report_event that take an optional argument changing the behavior.

I don't see how a rhythmic-music-iterator would help here since the rhythmic
events need to get handled either way, whether they are called inside of an
EventChord or not.  The problem is that the _default_ behavior of articulations
needs to be that they just get _removed_ from events and broadcast in parallel. 
Only inside of EventChord are they allowed to stay associated with the
individual event carrying them.

That's the way things work currently.  It is just that this unwrapping and
parallel broadcasting is currently wired into the parser, where _everything_
gets wrapped in an EventChord (except when it isn't, like inside of a chord),
just in two different manners depending on whether we are in-chord or not.

So if we are not wrapping non-chord notes in EventChord, this difference needs
to get established elsewhere if the input is to retain its meaning.  And that
means the default behavior needs to be unwrapping, while EventChord refrains
from it.

I don't see that a rhythmic-music-iterator would help since it gets to play at a
time when the distinction of EventChord-or-not must already have had its effect.