lilypond-devel
[Top][All Lists]
Advanced

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

Re: Issue 3061 (issue 7033045)


From: Zefram
Subject: Re: Issue 3061 (issue 7033045)
Date: Wed, 2 Jan 2013 11:14:58 +0000

address@hidden wrote:
>Excellent point.  Of course, it begs the question how to articulate
>_anything_ in the presence of scaled durations.

The result will presumably end up as zero-duration silence, but I'd
rather it were *properly articulated* zero-duration silence.  Well,
seriously, you could detect the zero scale factor as a special case and
return null music for it, but (a) that just puts the additional code in a
different place and (b) it's a nasty exception that makes \articulate less
algebraically well behaved.  Consistently emitting a scaled articulation,
whatever the scale factor, means that when we look at how anything else
handles the zero-scale case we don't need to worry specifically about
how it'll interact with \articulate.

>It is not just "a bit" of a win.  The code for expanding and
>displaying tremolo dot counts have been at odds with the execution for
>the longest amount of time

Ah, interesting.  OK, we'll keep that knowledge localised.

>The question is whether this is the most useful approach.  Other
>possibilities would be to give ly:duration-length an optional argument
>for overriding the scale factor to an arbitrary value, or make an
>extra function ly:visual-duration-length that ignores the scale factor.

I'd rather not overload existing functions.  visual-duration-length
(I'd call it duration-visual-length) is sensible, and goes alongside my
duration-descale, which could be correspondingly called visual-duration.

>(define (duration-dot-factor dotcount)
>  (- 2 (/ (ash 1 dotcount))))

Neater than I had it.

>duration-rescale with an optional argument defaulting to 1 maybe?  Or
>would that never be useful?

I don't see a need for overriding the scale factor to anything other
than 1.  If the need arises then the circumstances will give us some
clue as to how best to present the operation.

>It is a _necessary_ wrapper around Rational, an internal C++ data type
>predating the availability of rational numbers in Guile.

Makes sense, though a pity that the rational wrapper also got lumped
with the grace-alignment job.  I wasn't aware that Guile had ever lacked
proper rationals.  (This is actually the first project on which I've
used Guile, and the first significant use I've made of Scheme.)

I suppose that history also explains why so much of the code processes
rationals as an unboxed numerator/denominator tuple.  That's another thing
to eliminate now that there are proper rationals.  The only fractions
that need to be handled that way are time signatures, which are not
merely arithmetical fractions.

>"a" library of wider utility is not really required: we already have
>lily-library.scm and music-functions.scm

Right, I was thinking this stuff would probably belong in
music-functions.scm.  I'll produce a revised patch that factors some of
the logic out this way.

-zefram



reply via email to

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