On 2024-12-10 20:13, Dan Eble wrote:
Current Name Proposed New Name
-- ---
measureLength measureLength (no change)
minimumPageTurnLength pageTurnMinimumRestLength
minimumRe
I'm not sure what in my message gave the impression that I'm in love with
the term "music length." All I said is that I think it's completely clear
what it means.
Is there a concrete proposal of a more elegant name that doesn't require
using the same name for two different types?
On Fri, Dec 13,
>> Kieren earlier spoke in favor of whatever is most comprehensible to users.
>> To me, musicLength seems completely clear and unambiguous.
> Please step outside LilyPond for a moment.
>
> Do you see books written about music and musicians, or about music theory,
> using the phrase "music length"
On Fri, Dec 13, 2024 at 4:15 PM Saul Tobin
wrote:
> I mean it's not a Lilypond specific construct. Duration log + augmentation
> dots is a music notation construct that Lilypond faithfully represents
> using a type named duration. I don't think there's any inherent reason that
> representation of
On Fri, Dec 13, 2024 at 4:07 PM David Kastrup wrote:
> Trevor Bača writes:
>
> > On Fri, Dec 13, 2024 at 1:02 PM David Kastrup wrote:
> >
> >> Trevor Bača writes:
> >>
> >> > I am concerned by what seems to be an unwillingness to use the term
> >> > "duration" to label things in the system tha
I mean it's not a Lilypond specific construct. Duration log + augmentation
dots is a music notation construct that Lilypond faithfully represents
using a type named duration. I don't think there's any inherent reason that
representation of musical time is more deserving of the name duration than
wh
On Wed, Dec 11, 2024 at 5:18 PM Christopher Heckman <
christopher.heck...@asu.edu> wrote:
> On Wed, Dec 11, 2024 at 3:32 PM wrote:
> >
> > Perhaps I'm the only one who feels this way, but I wish we would more
> > carefully distinguish between "duration" as a measure of *time* and
> > "length" as
Trevor Bača writes:
> On Fri, Dec 13, 2024 at 1:02 PM David Kastrup wrote:
>
>> Trevor Bača writes:
>>
>> > I am concerned by what seems to be an unwillingness to use the term
>> > "duration" to label things in the system that are clearly durations.
>>
>> Computers are not fond of ambiguities.
On Fri, Dec 13, 2024 at 1:02 PM David Kastrup wrote:
> Trevor Bača writes:
>
> > I am concerned by what seems to be an unwillingness to use the term
> > "duration" to label things in the system that are clearly durations.
>
> Computers are not fond of ambiguities. I am concerned by what seems t
Carl Sorensen writes:
> On Fri, Dec 13, 2024 at 2:03 PM David Kastrup wrote:
>
>> Trevor Bača writes:
>>
>> > I am concerned by what seems to be an unwillingness to use the term
>> > "duration" to label things in the system that are clearly durations.
>>
>> Computers are not fond of ambiguities
On Fri, Dec 13, 2024 at 2:03 PM David Kastrup wrote:
> Trevor Bača writes:
>
> > I am concerned by what seems to be an unwillingness to use the term
> > "duration" to label things in the system that are clearly durations.
>
> Computers are not fond of ambiguities. I am concerned by what seems t
Hi all,
>> I am concerned by what seems to be an unwillingness to use the term
>> "duration" to label things in the system that are clearly durations.
>
> Computers are not fond of ambiguities. I am concerned by what seems to
> be an unwillingness to use consistent terminology while expecting
>
Trevor Bača writes:
> I am concerned by what seems to be an unwillingness to use the term
> "duration" to label things in the system that are clearly durations.
Computers are not fond of ambiguities. I am concerned by what seems to
be an unwillingness to use consistent terminology while expecti
On Thu, Dec 12, 2024 at 11:18 AM Saul Tobin
wrote:
> Regarding length vs. moment, David's comment from the previous thread on
> this topic may shed some light:
> https://mail.gnu.org/archive/html/lilypond-devel/2024-10/msg00017.html
>
Thank you for the pointer to the thread; David's reference th
On Thu, Dec 12, 2024 at 4:26 PM Dan Eble
wrote:
> On 2024-12-12 11:16, Trevor Bača wrote:
> > 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
> >
On Thu, Dec 12, 2024 at 3:45 PM Saul Tobin wrote:
>
> I meant that in Lilypond's type terminology, properties with the name width
> typically take a value that is a Scheme interval (i.e. a pair of numbers).
> Using the word width to name properties that take a single numerical value
> for a phy
I meant that in Lilypond's type terminology, properties with the name width
typically take a value that is a Scheme interval (i.e. a pair of numbers).
Using the word width to name properties that take a single numerical value
for a physical distance would be potentially confusing for similar reason
On Thu, Dec 12, 2024 at 9:17 AM Saul Tobin wrote:
>
> Doesn't width typically refer to a pair of numbers?
>
No; semantically, you can only talk about the width (or length) of *an
object*; what you're looking at is *the distance between* two numbers
(and hence a pair of numbers).
--- Christopher
On 2024-12-12 11:16, Trevor Bača wrote:
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
Regarding length vs. moment, David's comment from the previous thread on
this topic may shed some light:
https://mail.gnu.org/archive/html/lilypond-devel/2024-10/msg00017.html
On Thu, Dec 12, 2024 at 11:16 AM Trevor Bača wrote:
> On Wed, Dec 11, 2024 at 4:32 PM Dan Eble
> wrote:
>
> > On 2024-1
On Wed, Dec 11, 2024 at 4:32 PM Dan Eble
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 cle
Doesn't width typically refer to a pair of numbers?
On Wed, Dec 11, 2024 at 6:37 PM David Kastrup wrote:
> Dan Eble writes:
>
> > On 2024-12-11 14:04, Trevor Bača wrote:
> >
> >> Regardless of the names of Lily's underlying (and therefore
> >> user-invisible?) types, these user-facing context p
Dan Eble writes:
> On 2024-12-11 14:04, Trevor Bača wrote:
>
>> 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
On 2024-12-11 13:26, Simon Albrecht wrote:
>
Maybe rename grob
property musical-length so users don’t get confused about musical-length
= \musicLength 4 ? Spelling it out, doesn’t seem actually confusing to
me. Don’t have time to continue thinking about that, right now.
I don't know whether i
On Wed, Dec 11, 2024 at 3:32 PM wrote:
>
> Perhaps I'm the only one who feels this way, but I wish we would more
> carefully distinguish between "duration" as a measure of *time* and
> "length" as a measure of *space*. LilyPond deals in a crucial way with both
> of these things. Musical events hav
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.v
On 11.12.24 20:04, Trevor Bača wrote:
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
On 11.12.24 22:24, Dan Eble wrote:
On 2024-12-11 13:26, Simon Albrecht wrote:
Since context property voltaSpannerDuration is deprecated anyway, ...
You're right in the sense that a better alternative (the
musical-length grob property) was added in 2.25.4.
Oops, that’s very recent of course
On 2024-12-11 13:26, Simon Albrecht wrote:
Since context property voltaSpannerDuration is deprecated anyway, ...
You're right in the sense that a better alternative (the musical-length
grob property) was added in 2.25.4. I also remembered this about five
minutes after I sent my message. :)
On Tue, Dec 10, 2024 at 7:13 PM Dan Eble wrote:
> Current NameProposed New Name
> -- ---
> measureLength measureLength (no change)
> minimumPageTurnLength pageTurnMinimumRestLe
On 11.12.24 02:13, Dan Eble wrote:
Current Name Proposed New Name
-- ---
measureLength measureLength (no change)
minimumPageTurnLength pageTurnMinimumRestLength
minimumRepeatLengt
> Current NameProposed New Name
> -- ---
> measureLength measureLength (no change)
> minimumPageTurnLength pageTurnMinimumRestLength
> minimumRepeatLengthForPageTurn pageTurnMi
32 matches
Mail list logo
