Re: 2.16 release candidate 3 imminent

[David Kastrup]

"address@hidden" <address@hidden> writes:

> On Jan 21, 2012, at 6:14 PM, Keith OHara wrote:
>
>> Carl Sorensen <c_sorensen <at> byu.edu> writes:
>> 
>>> On 1/21/12 9:45 AM, "Graham Percival" <graham <at> percival-music.ca> wrote:
>>>> On Sat, Jan 21, 2012 at 05:27:00PM +0100, David Kastrup wrote:
>>>>> I would very much prefer the work on Issue 2240 (aka 2070) to make it
>>>>> into 2.16.  It is a significant API change 
>>>> 
>>>> IMO, significant API changes should not happen right before a
>>>> release. 
>>> 
>>> We wanted stable versions to
>>> have a significant lifetime so things like LilyPondTool and Frescobaldi
>>> didn't need to always keep changing.
>> 
>> The implication is that issue 2240 changes the interface (but not the
>> input syntax because there is no convert-ly rule) in a way enables 
>> improvements user code (presumably Scheme) that we will want so badly
>> that we cannot wait for 2.18.
>> 
>> Does anybody know what 2240 improves ?
>
> I was asking myself a similar question lately now that I've gotten
> deeper into the non-parser-related aspects of 2240.  After playing
> around with iterators and such, I'm convinced that all the
> articulation stuff can be written to be slicker independent of any
> changes to the parser.  Meaning that, without any changes to the
> representation of event-chords, we could get rid of the script
> engraver and fingering engraver and just keep the new fingering
> engraver, doing all necessary massaging at the iterator level.

That is a backend aspect.  2240 is not concerned with improving the
backend: its changes to the backend are just designed to keep LilyPond
produce the same graphical output given the same textual input.

The advantage is in a much more straightforward relation of input to
music expressions.  That makes experimenting with and programming
LilyPond more simple.

One example from the notation manual:

       For the `\tweak' command to work, it must remain immediately
    adjacent to the object to which it is to apply after the input file has
    been converted to a music stream.  At times, LilyPond may insert
    additional items into the music stream during the parsing process.  For
    example, when a note that is not explicitly part of a chord will be
    placed in a chord by LilyPond, so notes to be modified with `\tweak'
    must be placed inside a chord construct:

         \tweak #'color #red c4
         <\tweak #'color #red c>4

Guess what: both work just the same now.  \tweak is a music function.
Music functions inside of chords were special: they got "chord
constituents" as arguments and were expected to produce them again, as
opposed to "normal" music functions that received notes only wrapped in
EventChord.  If you were serious about making your music functions
maximally useful, you needed to check what you got and behave
accordingly.  Now music functions can get _multiple_ music arguments.
Will only the last be chord constituents when we have a chord music
function?  What if optional arguments are in between?  Actual the
optional argument scanning was so complex that it was only implemented
for "main" music functions, not for "chord constituent" music functions.

Because "chord constituents" are not artificially wrapped in EventChord
unless they are actually placed in a chord, the difference is _gone_.
_All_ music functions will work predictably inside of chords like
outside.  They don't see different input.  They don't need to produce
different output (of course, if they produce something inside of a <...>
chord that has no place inside of such a chord, LilyPond will complain).

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.

> 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>

> Especially given the perspective David addressed earlier that part of
> LilyPond's code base getting better will be it getting more uniform
> and boring, how is this move away from uniformity (meaning creating
> two channels for of handling rhythmic events) beneficial?  I think the
> question boils down to: is there an inherent difference between <c>
> and c and, if so, what is it and why is it meaningful?

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?

Why does \tweak c require chord brackets to work?  Why does
\displaySchemeMusic produce oodles of layers for simple input?

Issue 2240 makes the relation between input and resulting music
expressions much more straightforward.

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.

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.

-- 
David Kastrup