Carl Sorensen <c_soren...@byu.edu> writes: > On 12/16/09 10:23 PM, "Frédéric Bron" <frederic.b...@m4x.org> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
