Re: Getting beam subdivision working
On Jun 17, 2023, at 09:27, David Kastrup wrote:
>
>>
>> That sounds like it would make more sense to specify those values in the
>> form of a "duration log", like the first argument to a ly:make-duration
>> call.
>
> Or just use a duration in the first place. First iterations would
> likely only use the duration-log info while I consider it conceivable
> that in the context of tuplets, ultimately also the factor may get used.
There are no Duration properties. I recently tried a step down the path of
adding them and got as far as supporting
\set Staff.parserTestDuration = \breve
\set Staff.parserTestDuration = ##{ 4. #}
\set Staff.parserTestDuration = \duration 4.
before deciding to leave the existing Moment properties as they are and provide
\musicLength [1] to clear ly code of #(ly:make-moment…) cruft.
I'm not saying that Duration properties couldn't or shouldn't be added; I'm
just warning that they're not a ready option.
—
Dan
[1] https://gitlab.com/lilypond/lilypond/-/merge_requests/1887
Re: Getting beam subdivision working
David Kastrup writes: > Dan Eble writes: > >> On Jun 16, 2023, at 19:13, Jason Yip wrote: >>> >>> minSubdivideInterval and maxSubdivideInterval. They are both >>> Rationals. Their numerator and denominator must be a power of 2. For >>> each power of 2 (including negative powers of 2 of course) > > That's redundant. It just means minSubdivideInterval and > maxSubdivideInterval must be an integral power of 2 (including > negative). > >>> between those two values, the beam can be subdivided by that >>> interval. minSubdivideInterval can be 0 for no minimum limit, >>> maxSubdivideInterval can be infinity for no maximum limit. >> >> Setting the representation aside, is the following another way of >> describing what you have in mind? >> >> * These properties are independently optional. >> * The allowed values are integer powers of two (including negative powers). > > That sounds like it would make more sense to specify those values in the > form of a "duration log", like the first argument to a ly:make-duration > call. Or just use a duration in the first place. First iterations would likely only use the duration-log info while I consider it conceivable that in the context of tuplets, ultimately also the factor may get used. -- David Kastrup
Re: Getting beam subdivision working
Dan Eble writes: > On Jun 16, 2023, at 19:13, Jason Yip wrote: >> >> minSubdivideInterval and maxSubdivideInterval. They are both >> Rationals. Their numerator and denominator must be a power of 2. For >> each power of 2 (including negative powers of 2 of course) That's redundant. It just means minSubdivideInterval and maxSubdivideInterval must be an integral power of 2 (including negative). >> between those two values, the beam can be subdivided by that >> interval. minSubdivideInterval can be 0 for no minimum limit, >> maxSubdivideInterval can be infinity for no maximum limit. > > Setting the representation aside, is the following another way of > describing what you have in mind? > > * These properties are independently optional. > * The allowed values are integer powers of two (including negative powers). That sounds like it would make more sense to specify those values in the form of a "duration log", like the first argument to a ly:make-duration call. -- David Kastrup
Re: Getting beam subdivision working
On Jun 16, 2023, at 19:13, Jason Yip wrote: > > minSubdivideInterval and maxSubdivideInterval. They are both Rationals. Their > numerator and denominator must be a power of 2. For each power of 2 > (including negative powers of 2 of course) between those two values, the beam > can be subdivided by that interval. minSubdivideInterval can be 0 for no > minimum limit, maxSubdivideInterval can be infinity for no maximum limit. Setting the representation aside, is the following another way of describing what you have in mind? * These properties are independently optional. * The allowed values are integer powers of two (including negative powers). — Dan
Re: 2.25.6 release
On Fri, 2023-06-16 at 19:46 +0200, Jean Abou Samra wrote: > Le vendredi 16 juin 2023 à 18:11 +0200, Jonas Hahnfeld a écrit : > > I think I'd still lean towards doing the release as planned because (a) > > the issue is already there with the current 2.25.5 and (b) it's also > > not clear that a fix will land before the next weekend. > > Regarding (b), I've now submitted > https://gitlab.com/lilypond/lilypond/-/merge_requests/2041 which I hope will > be satisfactory for everyone. Thanks! In light of that fix, let's delay the release by one week (there's no point in merging early since I'm away tomorrow). > TBH, I feel guilty about that issue and would prefer to delay the release, > but no strong feelings. Well, issues like these happen, especially with many components involved in a complex way. I don't think it's worth it to worry about this too much, it affects one development version for a subset of users on Linux... Jonas signature.asc Description: This is a digitally signed message part
