lilypond-devel
[Top][All Lists]
Advanced

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

Re: PATCH: Issue 638 Autobeaming


From: David Kastrup
Subject: Re: PATCH: Issue 638 Autobeaming
Date: Thu, 17 Dec 2009 09:25:58 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (gnu/linux)

Carl Sorensen <address@hidden> writes:

> On 12/16/09 10:23 PM, "Frédéric Bron" <address@hidden> wrote:
>
>>> At last, thanks to help above and beyond the call of duty by Neil, I
>>> have finally got the autobeam engraver fixed so it beams 4 4 right
>>> when there are 16th notes in the 2nd or 4th beat of the measure.
>> 
>> Very nice job. That's now a good reason for me to upgrade to 2.13.X.
>> Does this apply only to 4/4 or is it more general? Is it
>> custumizable?  and how does it interact with normal commands to set
>> auto-beaming rules?
>
> There is nothing specific about 4/4 in this patch.  It will apply any
> time that there is a bigger group for longer duration notes (e.g. 1/8
> notes) and a smaller group for shorter duration notes (e.g. 1/16
> notes).
>
> I've not looked carefully at all of the places in standard beaming
> that it might apply.  I fixed the fundamental problem, so it should
> work everywhere.

Ok, stupid question time.  I've glanced over the code, and the way it
looks to me is that when the previous shortest duration of some note
group changes, it resets data structures and puts up new accounting,
continuing with the new accounting.

Deep breath.

So it would appear that no terminal/irreversible decision based on the
minimum duration has been done yet at this point of time.

If that is the case, why not postpone all of the minimum-duration
dependent accounting to the time where it is actually _needed_?

There does not seem to be much sense in making some temporary
calculation based on possibly wrong assumptions when one can safely do
it at a later point of time anyway.

So it would appear to me that either we can do the calculation later
anyway, or that there might be circumstances where the recalculation
based on the new minimum-duration may not be able to revert some
decision based on the old assumption, which might be a bug.

It is quite possible that I am missing some detail here (actually, I am
missing _all_ details right now because I did not bother to look at this
level yet, but there might be some _relevant_ detail among them).

This is just what hits me as a gut feeling about this patch right now.

-- 
David Kastrup





reply via email to

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