Re: [proposal] easy triplets and tuplets - Draft 3

[David Kastrup]

Benkő Pál <address@hidden> writes:

> 2012/10/9 David Kastrup <address@hidden>:
>> Benkő Pál <address@hidden> writes:
>>
>>> 2012/10/9 David Kastrup <address@hidden>:
>>>> I don't really think that people consider \times and \scaleDurations as
>>>> closely related (and their naming choice is also totally different), so
>>>> I don't think that there will be much of an opportunity confusing the
>>>> behavior of \scaleDurations with \tuplet.
>>>
>>> I, for one, consider \times a visually enhanced variant of \scaleDurations.
>>> regardless how it's written, to me both mean metric change (and metric
>>> is represented poorly in graphic anyway).
>>
>> Do you feel that the changed fraction gender of \tuplet would be a
>> potential source of confusion for you in the light of your view of
>> \scaleDurations?
>
> definitely not, I'm fine with the \tuplet proposal, it mimics better the
> engraved representation.  BTW do we still have \compressMusic or
> only \scaleDurations?

Huh.

@newsItem
@subsubheading LilyPond 2.11.48 released.  @emph{June 9, 2008}

LilyPond 2.11.48 is out.  This release fixes a few bugs, and
@code{\compressMusic} has been renamed
to @code{\scaleDurations}.
@*

I was not actually aware that there ever _was_ a \compressMusic, and it
would appear that it had the _same_ fraction interpretation as
\scaleDurations.  Probably that was the reason for renaming it.

Reintroducing it with inversed meaning might not be the hottest idea,
then.  The underlying Scheme primitive, by the way, is called
ly:music-compress:

LY_DEFINE (ly_music_compress, "ly:music-compress",
           2, 0, 0, (SCM m, SCM factor),
           "Compress music address@hidden@var{m} by moment @var{factor}.")

It ultimately calls

Duration::compressed (Rational m) const
{
  Duration d (*this);
  d.factor_ *= m;
  return d;
}

so we have this misnomer of "compress" for what is actually "scale"
(namely making things longer for factors > 1) throughout the whole
Scheme API and C++ layer.

It's just the user interface that has apparently been relieved of this
embarrassing name choice.  Reintroducing it with inversed meaning would
make a bit of isolated sense in the user interface, but would be
horribly confusing in light of all the other layers employing different
terminology.

So if we want to introduce a "scale Durations by 1/x" user level
function at some point of time, \compressMusic seems to be an awfully
bad naming choice for that, for historical as well as continuing
reasons.

I was not aware of that.

-- 
David Kastrup