lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 2.16 release candidate 3 imminent


From: address@hidden
Subject: Re: 2.16 release candidate 3 imminent
Date: Sat, 21 Jan 2012 18:32:59 +0100

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.

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

Cheers,
MS


reply via email to

[Prev in Thread] Current Thread [Next in Thread]