bug-lilypond
[Top][All Lists]
Advanced

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

Re: Implementation of \tuplet allow both incorrect and correct musical e


From: David Kastrup
Subject: Re: Implementation of \tuplet allow both incorrect and correct musical expressions
Date: Tue, 24 Mar 2015 09:11:56 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Ralph  D. Jeffords <address@hidden> writes:

>> I'm not top posting.
>
> %{  MAJOR ERROR in implementation of Tuple:
>
>   The tuple construct allows not only correct expressions but a multitude of
> incorrect expressions for the same musical construction. "1st Test" shows  5
> different expressions that give the same MIDI output, but only one of which
> is correct.
>
> Worse yet with the incorrect expressions, there may be multiple tuple
> expressions resulting in identical music expressions, but result in
> different MIDI interpretation (see "2nd test")
>
> The solution for ruling out bogus tuples of the form  " \tuple  n/d  { _m
> ... }"  (where d/m is the duration for the tuple and _m indicates the
> inverse duration expression for the first note of the body for the special
> case when d and m are both powers of 2 is that you must have 2^floor(lg n) =
> d. This correctness criterion follows from the following observation (for
> the special case where duration = 1 quarter note) which is easily
> generalized to durations of whole note, half note, quarter note, eight note
> etc.:
>  
> (n,d,m)
> -------
>
> (1,1,4)   (single quarter note)
>
> (2,2,8)   (two 8th notes)

[...]

I'm an engineer, not a mathematician, Jim.

Instead of describing the problem at an abstract level, it is better to
write one or two LilyPond one-liners (or slightly longer), describe in
which manner the resulting output is deficient, and _then_ follow up
with the generalizations if one has a good idea for them.  That way,
prospective bug fixers (of which there are numerous) can see the
symptoms and simple examples immediately and do not need to invest
15 minutes upfront before they can decide whether this bug (rather than
the bug report) is in their range of expertise.

You don't want to burn the intellectual energy of bug fixers on
understanding the report rather than finding the problem.

Now you _do_ include an example which at least helps in skipping the
theory and see what this is about, but it is rather large and it is
mostly left to the reader to figure out what is wrong with individual
lines when going there.

I'll try taking a look later this day.  But for the future you'll
improve your chances for competent replies by making it really easy to
get a first impression of the bug.

-- 
David Kastrup



reply via email to

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