Re: 2.16 release candidate 3 imminent

[address@hidden]

On Jan 21, 2012, at 10:15 PM, David Kastrup wrote:

> "address@hidden" <address@hidden> writes:
> 
>> On Jan 21, 2012, at 7:58 PM, David Kastrup wrote:
> 
>> 
>>    that all articulation events will be pulled out of NoteEvents or
>> 
>>    RestEvents and broadcast at the iterator level.
>> 
>> 
>>    There is such a thing as a chord articulation.
>> 
>> 
>> 
>> Why couldn't this distinction be captured via a different event name?
>> ChordArticulationEvent versus ArticulationEvent, for example.
> 
> Where would be the point?
> 

To not make the distinction in the parser.  I think that changing the parser 
should be a last resort if we can't figure out a way to represent information 
through different event classes.

>> What would really help are some before/after examples (ly code and/or
>> music streams and/or brief text like "before the patch, you could not
>> do X, after, you can" or "this patch will allow me to experiment with
>> implementing X") would help a great deal.  As if it were going into
>> the Change Log, for example.
> 
> It's a bit hard since the whole design (perfected by the
> rhythmic-music-event) was intended to make no user-visible difference.
> The music expression has just become predictable.  You get an EventChord
> iff < ... > has been in the input.  You get articulations on NoteEvent
> for pitch-postevent regardless whether or not this is part of a chord.
> 

Why can't we treat c as shorthand for <c>?  Having a compulsory wrapping around 
singletons is just as predictable as no wrapping at all.
As for articulations being on a NoteEvent whether or not this is part of a 
chord, I agree that this is a very good idea, but I think this can be 
accomplished by wrapping everything in an event chord and farming out the work 
to iterators.

> If you use \displayMusic on something that you might want to put into a
> chord, you don't get wrong input.  Tacking < > around a construct does
> not change the structure of its inside.  It is not necessary to tack < >
> around a construct to make a \tweak work (which is a user-visible
> change).
> 

Why couldn't tweak make this distinction in the music function itself?
The music function could check if its input is an EventChord and, if so, feed 
it the first entry in the 'elements list of the EventChord.  This seems like a 
less intrusive change than changing the parser.

> You can use #{ #} for constructing material that ends up _inside_ of a
> chord.  Something like
> \displayLilyMusic < \displayLilyMusic ##{ c-. #}>
> does not go up in flames but just does what one would expect.

This is indeed an interesting case.  Again, though, I would expect this to 
fail, precisely because #{#} manipulates the material.  If we define c as 
shorthand for <c>, then this would be like doing \displayLilyMusic < 
\displayLilyMusic <c> >, which I would also expect to fail.

I'm playing devil's advocate because it is an important change and I want to 
make sure that its benefit outweighs the cost of adding exceptions into the 
code base that facilitate the in/out of EventChord distinctions.

Cheers,
MS