Re: 2.16 release candidate 3 imminent

[address@hidden]

On Jan 21, 2012, at 7:12 PM, David Kastrup wrote:

> If you wrote note^postevent previously, the postevent ended up in
> "articulations" of the NoteEvent when written inside of a chord, or as
> an EventChord companion when not written in a chord.  Now it ends up in
> "articulations", period.
> 

I think it this is good - this is what will help scrap the fingering and script 
engraver.  It seems like this is a separate problem from wrapping notes in 
event chords or not: if all articulations are in an articulations list, then 
they can all go to the new fingering engraver.

>> My question is this: what is the basic advantage of having rhythmic
>> events not wrapped in event chords?  I understand that it can be used
>> to wedge a distinction between <c> and c, but how is this distinction
>> useful?
> 
> <URL:http://code.google.com/p/lilypond/issues/detail?id=1110#c26>
> 

Why couldn't this be solved on the iterator level?

> The problem that I have been tackling is more: is there an inherent
> difference between c-. and c-. and, if not so, why the heck do they look
> utterly different in the music expression depending on whether inside of
> < > or outside?
> 

I absolutely agree that everything should be in an articulations list, but I 
think this can be done while preserving event chords.  It just means that 
EventChords will no longer contain articulation events and that all 
articulation events will be pulled out of NoteEvents or RestEvents and 
broadcast at the iterator level.

> And the everything-is-an EventChord mantra gave you a false sense of
> security: you thought if stuff worked with single notes, chords would be
> covered as they are the same.  Poppycock.
> 
> When c-. works, that does not mean that <c-.> will also work.  Because
> suddenly it becomes quite different even though both are in a chord.
> 

I'm not quite getting what you're saying here...

> With the current setup, the music expressions reflect the input, the
> Stream Events (and thus everything passing through engravers) reflects
> the old behavior that was previously hand-cranked in the parser.
> 
> You can now synthesize single NoteEvents and have them work as expected.
> 

I think that expected behavior depends on how we define it.  If there were 
synthesized articulation events that fell outside of an EventChord, LilyPond 
would not know what to do with them.  Similarly, if we simply say that a 
NoteEvent makes no sense outside of an EventChord, then there is no expected 
functionality for a dangling NoteEvent.

I'm not at all saying that this is a bad proposal, but rather that as I'm 
learning more about how iterators do their thing, I'm realizing that all 
articulations can be in a list attached to a rhythmic event and that event 
chords never need to carry articulations.

Some of this comes from my continued limitation in understanding what this 
patch does - I get the general concepts in your e-mails, but it is very 
difficult to understand how LilyPond works without seeing lily code.

So,
***
What would be really helpful is an e-mail that has almost no text explanation 
but that shows before and after examples of how this will change LilyPond.  
This can be syntax before versus syntax after or music stream before versus 
music stream after.  I know that adds an extra burden to your work, but I'd 
greatly appreciate it!
***

Cheers,
MS