lilypond-devel
[Top][All Lists]
Advanced

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

Re: Getting beam subdivision working


From: Jason Yip
Subject: Re: Getting beam subdivision working
Date: Fri, 16 Jun 2023 17:47:56 -0700


On 2023-06-16 17:26, Carl Sorensen - carl.d.sorensen(a)gmail.com wrote:

Before you work too hard on beam-subdivide-tuplets.ly <http://beam-subdivide-tuplets.ly>, you may wish to investigate Urs's comment on local beat structure for tuplets.  As far as I know now, you don't have a beat structure yet implement for subbeams; that may be a very powerful construct that could be helpful.

I suspect that much of the concern about baseMoment and subdivision in Urs's paper can actually be resolved with baseMoment and beatStructure (including local beat structures).  And using baseMoment and beatStructure would potentially resolve the problem of only allowing 1/x subdivision discussed on page 3.

You have created a Sub_beam class.  Is there a reason to use a Sub_beam class instead of just creating a new Beaming_pattern element as Urs suggests on page 7?  Can a Sub_beam just be a Beaming_pattern?  Perhaps using the same class of object would prevent duplication.

The purpose of my Subbeam class is to calculate a local baseMoment and beatStructure on the fly. You can see at https://gitlab.com/ljyip/lilypond/-/blob/e7d39a076ccf50555bfa2d352400caaf28db2678/lily/beaming-pattern.cc#L272 . The code infrustructure to support fancy tuplet-local beatStructure's is already there, but the default local beatStructure is assumed to just be a list of /denominator/ items of value /numerator/ for now since we should discuss the way to support such from manual user input or automatically.

I originally wanted to avoid Beaming_pattern acting as the recursive class because it would have to make copies of Beam_rhythmic_element in their own vector and I thought that it could be too computationally expensive. Subbeam acts like a C++20 range on the vector, only storing a start and end index for itself. Most people won't even have nested tuplets anyways, so maybe Beaming_pattern can bear the computations anyways.


P.S. Have you tried any of Urs's hard examples to see if your code works on them?  It would be nice to see how many you have already solved!  I suspect it's most of them.

Figure 1 code:

```lilypond

\relative a' {
  \compoundMeter #'((2 4) (5 32))
  \set baseMoment = #(ly:make-moment 1/32)
  \set beatStructure = #'(8 8 5)
  \set subdivideBeams = ##t
  \repeat unfold 16 a32
  \repeat unfold 5 a32
}

```

My extended version of Figure 4 code:

```lilypond

\relative c' {
  \time 1/4
  \set subdivideBeams = ##t
  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 }
  }
}

```

I'll take a look at the figures on pgs. 7-9 next week


--
- Jason Yip

Attachment: figure_1.pdf
Description: Adobe PDF document

Attachment: tuplet-nest-beam.pdf
Description: Adobe PDF document

Attachment: OpenPGP_0xB69A3DD87D22F506.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


reply via email to

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