[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Renaming baseMoment
From: |
Kieren MacMillan |
Subject: |
Re: Renaming baseMoment |
Date: |
Fri, 13 Dec 2024 18:29:51 -0500 |
Hi Trevor (et al.),
>>> Can someone explain what structural properties LilyPond's model of
>>> duration has, above and beyond simply modeling a length of time?
>>
>> It has three parts:
>> 1. power-of-2 note value
>> 2. number of augmentation dots
>> 3. scaling factor (to describe a member of a tuplet, for example)
>
> Then what seems to be happening in the naming is a confusion between one
> way of *representing* duration (with the dots and scaling factor) and
> duration itself. These are not the same thing.
To make it concrete, let’s consider a 5:4 tuplet division of a quarter note,
containing three musical events: a dotted eighth note and two sixteenth notes.
When talking about the first musical event in that tuplet, noboty I know
(including me!) would use the word “duration” to express the power-of-2 note
value (eighth) or the number of augmentation dots (1) or the scaling factor or
any combination thereof.
When asked to describe the “duration” of that first note/event, I/they would
almost certainly say something along the lines of “3/5s of a quarter note”.
> The naming problems would go away if this three-part way of modeling
> duration were qualified in its name: dottedDuration, dottedIntegerDuration,
> probably something like that since the augmentation dots appear to be the
> most distinctive feature of this particular model for duration. Though
> anything could work.
> This would have the effect of freeing up "duration" to just mean what the
> English word means: an amount of time. If you do something like this, then
> there will be no need to introduce "music length" as a crippled synonym for
> "duration."
Maybe something including a reference to “scaling” or “scaled”? Or
“visualDuration” (or sim.)?
Despite the inherent ambiguities of all language, I feel optimistic — almost to
the point of certainty — that there’s a clear and elegant answer to this
conundrum which does better by the user(s) than the status quo, and no worse by
the developer(s). We just need to find it. :)
Cheers,
Kieren.
______________________________________________
My work day may look different than your work day. Please do not feel obligated
to read or respond to this email outside of your normal working hours.