lilypond-user
[Top][All Lists]
Advanced

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

Re: For those who need new features and bug fixes...


From: address@hidden
Subject: Re: For those who need new features and bug fixes...
Date: Fri, 21 Dec 2012 12:03:11 +0100


On 21 déc. 2012, at 11:33, David Kastrup <address@hidden> wrote:

> "Phil Holmes" <address@hidden> writes:
> 
>> ----- Original Message ----- 
>> From: <address@hidden>
>> To: <address@hidden>; <address@hidden>
>> Sent: Friday, December 21, 2012 8:03 AM
>> Subject: For those who need new features and bug fixes...
>> 
>> 
>>> Hey all,
>>> 
>>> I have two 16ish-hour flights this holiday season and I'll be
>>> filling them with composition, Sudoku, and LilyPond programming.
>>> So, this is the time to send me:
>>> 
>>> 1) Features you need implemented.
>>> 2) Bugs you need fixed.
>>> 3) Things you need reviewed.
>>> 
>>> I'll get as many of them done as I can on the flight.
>>> 
>>> Cheers,
>>> MS
>> 
>> I don't know how feasible it is, but
>> 
>> http://code.google.com/p/lilypond/issues/detail?id=34
> 
> I'd recommend against it.  The main problem is that moments are
> interchangeably used as time spans and time moments and the arithmetic
> properties with regard to grace timing are a foul compromise of those
> semantics.
> 
> Doing this properly would, in my opinion, replace all uses of moments as
> time spans with straightforward rationals.  I've started on this thing
> several times with the idea of getting it under control by working on
> the features of moment arithmetic alone, but it is a losing battle due
> to this kind of inconsistency.  Any solution concocted in 12 hours will
> be of the kind opening man-months of subsequent semantics-tweaking.
> 
> -- 
> David Kastrup
> 
> 
> _______________________________________________
> lilypond-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-devel

I agree that moment addition and subtraction is a royal pain. If I tackled 
this, which I might, the solution would be more general in the form of what I 
call "stream filters." Stream filters are Scheme functions applied before the 
engraving stage that somehow manipulate the music stream. They already exist 
for things like displaying only X bars of music. I've written more complicated 
ones that, for example, function like style sheets (automate dotted quarters 
versus eighth tied to quarter on the and of 1, etc.). Auto beams should be done 
like this as well - that way, beam events can be called for certainty when 
beams start and flags will only be created for I beamed notes. Similar types of 
logic can be used on the music stream to avoid the grace problem - for example, 
if event Y exists before grace moment X, add grace moment X to other voices 
with moments before and after this.

I'll have a go at it and will report back. The nice thing is that this approach 
is modular, so we can leave it in or out fairly easily.

Cheers,
MS


reply via email to

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