[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed context property renaming
From: |
Trevor Bača |
Subject: |
Re: Proposed context property renaming |
Date: |
Thu, 12 Dec 2024 10:16:25 -0600 |
On Wed, Dec 11, 2024 at 4:32 PM Dan Eble <nine.fierce.ballads@gmail.com>
wrote:
> On 2024-12-11 14:04, Trevor Bača wrote:
> >
> > Thinking this way, proportionalNotationDuration is named correctly,
> because
> > what's being set here is a unit of time.
> >
>
> I am not sure that I made my reason for wanting to rename this clear.
> Maybe this will help:
>
> ```
> \version "2.24.0"
>
> {
> \set Score.voltaSpannerDuration = #(ly:make-moment 1/4)
> \applyContext
> #(lambda (ctx)
> (let ((duration (ly:context-property ctx 'voltaSpannerDuration #f)))
> (if (ly:duration? duration)
> (display (format #f "\nvoltaSpannerDuration is ~a\n" duration))
> (display "\nhuh... I guess voltaSpannerDuration isn't a
> duration\n"))))
>
> s1
> }
> ```
>
> The "huh..." message appears in the output.
>
Ah, so voltaSpannerDuration accepts only whatever the output type of
make-moment is? A moment?
And the snippet above shows that ly:duration? returns false when evaluated
on a LilyPond moment?
So, yes, I see the discordance between "moment" and "duration". But see
more, below.
> > Regardless of the names of Lily's underlying (and therefore
> > user-invisible?) types, these user-facing context properties all measure
> > time, and not space. I think there might be a real gain in clarity in the
> > public-facing API if we move to labeling time-based properties with
> > "duration" and reserve "length" for properties that measure things in
> > centimeters, inches, staff spaces and the like.
>
> { c4 }
> \set Score.voltaSpannerDuration = #1/4
>
> Both of these numbers refer to the musical length of a quarter note.
> (The "4" on the note also has other attributes.) Are both of them
> durations, or is one the duration and the other the reciprocal of the
> duration? How would you explain the difference to the kind of user you
> have in mind (who does not care about internal types)?
> The Notation Reference has explained this special definition of
> "duration" is for quite some time:
>
> Durations
>
> The durations of notes are entered using numbers and dots.
> The number entered is based on the reciprocal value of the
> length of the note.
>
> In my view, if jargon like this must be defined, it should be used
> carefully and consistently. That is why I support renaming the
> properties that have been using "duration" in a broader sense.
>
I was with you until the very last sentence.
Isn't it the case that ...
{ c4 }
\set Score.voltaSpannerDuration = #1/4
... are two ways of referring to the same thing: a unit of time equal to
one quarter of a whole note? Two different types being used to model the
same thing, correct?
So, at least from a type-unaware perspective, voltaSpannerDuration is named
correctly, yes?
But I understand the discordance that happens when we become of the types
that are being passed around: voltaSpannerDuration wants a moment as a
type, even though voltaSpannerDuration is modeling a duration.
Question: if what we're wanting is to harmonize according to the types that
are being passed around (which, to be clear, is not what I think should
happen in public-facing parts of the API), then why not rename
voltaSpannerDuration to voltaSpannerMoment instead of
voltaSpannerMusicLength? In other words, what's the motivation for further
spreading around musicLength when the underlying type is presumably Moment?
Trevor.
--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
- Re: Proposed context property renaming, (continued)
- Re: Proposed context property renaming, Werner LEMBERG, 2024/12/10
- Re: Proposed context property renaming, Simon Albrecht, 2024/12/11
- Re: Proposed context property renaming, Trevor Bača, 2024/12/11
- Re: Proposed context property renaming, Dan Eble, 2024/12/12
- Re: Proposed context property renaming, Trevor Bača, 2024/12/13
- Re: Proposed context property renaming, David Kastrup, 2024/12/13
- Re: Proposed context property renaming, Kieren MacMillan, 2024/12/13
- Re: Proposed context property renaming, Trevor Bača, 2024/12/13
- Re: Proposed context property renaming, David Kastrup, 2024/12/13
- Re: Proposed context property renaming, Trevor Bača, 2024/12/13
- Re: Proposed context property renaming, Saul Tobin, 2024/12/13