[Top][All Lists]
[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
Re: For those who need new features and bug fixes..., Kieren MacMillan, 2012/12/21
Re: For those who need new features and bug fixes..., Urs Liska, 2012/12/21