lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Getting beam subdivision working


From: Carl Sorensen
Subject: Re: Getting beam subdivision working
Date: Mon, 19 Jun 2023 17:05:54 -0600

Jason,

This work is looking amazing..  Great job!

I think I like the idea of a Moment rather than a Duration right now.  Part
of me thought we might want to just use beam_count (which is the equivalent
of a dur_log).  But as is mentioned in Urs's document, that would
preclude any numerator other than 1.   Personally, I suspect the most
musically-consistent way to get numerators other than 1 is to make a
sub_base_moment and a sub_beat_structure.  But we haven't explored that
yet, and in the meantime allowing non-unity denominators is worth
exploring, I think.

Carl


On Mon, Jun 19, 2023 at 11:28 AM Jason Yip <sripedia_getpgrp@slmail.me>
wrote:

>
> On 2023-06-17 06:27, David Kastrup - dak(a)gnu.org wrote:
> > David Kastrup <dak@gnu.org> writes:
> >
> >> Dan Eble <dan@lyric.works> writes:
> >>
> >>> On Jun 16, 2023, at 19:13, Jason Yip <sripedia_getpgrp@slmail.me>
> 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.
>
> I've went ahead and set the 2 new properties as Moments since I wasn't
> sure how to make them Durations from Scheme. I was able to get them to
> do as I wanted. I attached the compilation of this snippet:
>
> ```\relative c' {
>    \time 1/4
>    % \set subdivideBeams = ##t
>    \set minSubdivideInterval = #(ly:make-moment 1 8)
>    \set maxSubdivideInterval = #(ly:make-moment 1 16)
>    c32 c
>    \tuplet 3/2 {
>      \repeat unfold 4 c64
>      \tuplet 3/2 { \repeat unfold 12 c128 }
>      \repeat unfold 4 c64
>    }
>    c32 c
>    \break
>
>    \tuplet 3/2 {
>      \tuplet 3/2 { \repeat unfold 12 c128 }
>      \repeat unfold 4 c64
>      \repeat unfold 4 c64
>    }
>    c32 c
>    c32 c
>    \break
>
>    c32 c
>    c32 c
>    \tuplet 3/2 {
>      \repeat unfold 4 c64
>      \repeat unfold 4 c64
>      \tuplet 3/2 { \repeat unfold 12 c128 }
>    }
> }
>
> ```
>
> In this example, I wanted just the eighth and 16th note levels to be
> subdivided. So minSubdivideInterval is a eighth note duration,
> maxSubdivideInterval is a 16th note duration. My results seem to
> correctly be what I want. Code is at
> https://gitlab.com/ljyip/lilypond/-/tree/new_scm .
>
> To clarify the usage of these 2 variables, minSubdivideInterval must be
> less than or equal to eighth note length in order to have any effect.
> maxSubdivideInterval must less than or equal to minSubdivideInterval to
> have any effect also. The intervals to be subdivided are inclusive of
> the bounds, so if minSubdivideInterval and maxSubdivideInterval both
> equaled eighth note, it subdivides just the eighth note level. Adding
> dots or specifying a factor to the Moment/Duration does nothing,
> although a specified factor may have some sort of possible use case. I
> only came up with these constraints today as I worked on the code, not
> when I first suggested them.
>
>
> --
> - Jason Yip
>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]