Menu

#2361 Beams with multiple subdivisions

Duplicate
nobody
None
Enhancement
2019-07-31
2012-02-26
Anonymous
No

Originally created by: *anonymous

Originally created by: colingh...@gmail.com

Carl Sorensen posted to request this enhancement to Lilypond:

http://lists.gnu.org/archive/html/bug-lilypond/2012-02/msg01097.html
http://article.gmane.org/gmane.comp.gnu.lilypond.general/70226

Original enhancement request follows, including David Bobroff's post to lilypond-user:

On 2/26/12 2:10 AM, "David Bobroff" <address@hidden> wrote:

>I'm looking for a way to achieve this beaming pattern:
>
>http://notendur.centrum.is/~bobroff/lily/complex-beam.png
>
>Can LilyPond do this?  I suspect I'll have to use a combination of
>subdivideBeams and stemRightBeamCount/stemLeftBeamCount.  Is there a
>known solution?
>
>Thanks,
>
>David
>
>
>

Lilypond does not currently do "second-level" beam subdivisions.

Please add this as a feature request.  I have been looking for a good
example of what it means to have multiple subdivision.

I believe this can be achieved; I will try to get to it in the next couple
of weeks.

I believe this beaming could be expressed as something like:

(subdivide . ((1 . 8) . (1 1 1))
             ((1 . 16) . (1 1 1 1 1 1)))

although I am not proposing this as the syntax.

It might be better to change subdivideBeams from a boolean to a list,
where each element of the list would be a beat length at which to
subdivide.  If that were the case we would achieve the beaming in the
sample by

\set subdivideBeams = #'((1 . 8) (1 . 16))

Or perhaps

\set subdivideBeams = #'((ly:make-moment 1 8)
                         (ly:make-moment 1 16))

Or perhaps even (with David K's new syntax, where we can have duration
elements)

\set subdivideBeams = #'( 8 16 )

I'll put this in the hopper and think about it.

Thanks,

Carl

Related

Issues: #5547

Discussion

  • Google Importer

    Google Importer - 2012-02-26

    Originally posted by: colingh...@gmail.com

    A typical example provided by David Bobroff

     
  • Google Importer

    Google Importer - 2015-03-10

    Originally posted by: tdanielsmusic

    I don't think we need any input syntax to do this.  LilyPond should just do the correct subdivision if subdivideBeams is set.  In "Behind Bars", on pages 156-157, Elaine Gould makes it quite explicit that using a single beam to separate groups of four 64th notes is wrong.  She says, "the number of beams separating the groups [should be] equal to the duration of the groups they separate".  A group of four 64th notes equals a 16th, so two such groups should be separated by a 16th beam, i.e. two beams.  Four such groups should have two beams between first and second and between third and fourth groups, and a single beam between second and third.  She gives an example showing exactly this.  The example shown above follows exactly this rule, but in this case using groups of two 32nds.

    Trevor

     
  • Google Importer

    Google Importer - 2015-04-24

    Originally posted by: Carl.D.S...@gmail.com

    LilyPond's beam subdivision was clearly wrong when compared with Gould.  That error has been made a separate issue (issue 4355) and a patch has been submitted.

    In this music there are two levels of subdivision.  There is a subdivision at the 1/8 note level, and one at the 1/16 note level.  The first 1/8 note is connected by a single beam two a two-note group with a duration of 1/16 note.  This group is connected by a double beam to another two-note group with a duration of 1/16.  Then, as we are at the end of a 1/8 duration, we are connected with a single beam to the next 1/16 note group.

    The current logic of lilypond's beam subdivision allows us to choose to subdivide at only a single level.  So we cannot get the desired beaming.  Instead we get either a single beam between 1/8 note groups (and no other subdivision), or a double beam between 1/16 note groups (and no other subdivision).  The enhancement request (which will require some kind of syntax change) is to allow more than one level of subdivisions.

     
  • Google Importer

    Google Importer - 2015-04-25

    Originally posted by: tdanielsmusic

    Hi Carl, thanks for working on this.

    I'm not sure why you think a syntax change is needed.  Gould (p 156) says, "The number of beams separating the groups is equal to the duration of the groups they separate."  So this seems to be calculable, allowing a division based on baseMoment to be implemented if subdivided beams were requested.  Is this simply too difficult to calculate?  Or are you thinking that the user might prefer a subdivision based on something other than baseMoment (ie not following Gould) and the syntax change would be a way of specifying this?

    Trevor

     
  • Google Importer

    Google Importer - 2015-04-25

    Originally posted by: Carl.D.S...@gmail.com

    After further review, I don't think a further syntax change is needed.  Originally I misunderstood subdivision.  Now, I agree that it is not necessary.

    The patch for issue 4355 also causes this example to work.  So I am merging the two issues.

     
  • Google Importer

    Google Importer - 2015-04-25

    Originally posted by: Carl.D.S...@gmail.com

    (No comment was entered for this change.)

    Mergedinto: 4355
    Status: Duplicate

     
  • Google Importer

    Google Importer - 2015-05-07

    Originally posted by: Carl.D.S...@gmail.com

    Issue 4355 involves an error is displaying the link between the subdivisions.  This issue deals with having multiple levels of subdivision, i.e., in comment 2,  Trevor talks about groups of 1/16 duration and groups of 1/8 duration.

    At this point, I'm not sure what the mechanism is for allowing and controlling the multiple levels of subdivision.  But I'll continue to think about it.

    Mergedinto:
    Status: Accepted

     
  • Google Importer

    Google Importer - 2015-05-07

    Originally posted by: Carl.D.S...@gmail.com

    In response to Trevor at comment 5, a subdivision based on baseMoment is very achievable (and that will be the fix for issue 4355).

    The issue is how to decide when we want to subdivide also at 2*baseMoment or 3* baseMoment.  Or whether we should subdivide at baseMoment/2 or baseMoment/4.

     
  • Google Importer

    Google Importer - 2015-05-07

    Originally posted by: dak@gnu.org

    I think we do not want to subdivide at multiples of baseMoment since just how base moments are patterned is decided by the beaming patterns.  We don't want to introduce alternative patternings even when autobeaming is overriden.

    So that only gives us baseMoment and its divisors to work with by default.

     
  • Google Importer

    Google Importer - 2015-05-07

    Originally posted by: Carl.D.S...@gmail.com

    Our current code only supports subdivision at baseMoment and its multipliers.  

    Certainly this could be changed.

    The most straightforward way I can see for accomplishing multiple levels of subdivision is to change beatStructure from a flat list to a nested list.

    So currently, we might have for 3/4 time a baseMoment of  1/4, with a beatStructure of (1 1 1)

    To subdivide at 1/8, we would set a baseMoment of 1/8, with a beatStructure of (2 2 2)

    To subdivide at 1/16, we would set a baseMoment of 1/16, with a beatStructure of (4 4 4)

    To subdivide at *both* 1/16 and 1/8, we might set a baseMoment of 1/16, with a beat structure of ((2 2) (2 2) (2 2))

     
  • Google Importer

    Google Importer - 2015-05-25

    Originally posted by: Carl.D.S...@gmail.com

    The other alternative I can see is to subdivide at baseMoment and baseMoment/2^N.  I am currently investigating a patch based on this behavior.

    Status: Started

     
  • Trevor Daniels

    Trevor Daniels - 2015-12-07

    Reverting to Status:Accepted as there has been no progress on this in over 6 months.

     
  • Trevor Daniels

    Trevor Daniels - 2015-12-07
    • Description has changed:

    Diff:

    
    
    • status: Started --> Accepted
    • Needs: -->
    • Patch: -->
     
  • Simon Albrecht

    Simon Albrecht - 2019-07-31
    • status: Accepted --> Duplicate
     
  • Simon Albrecht

    Simon Albrecht - 2019-07-31

    We should regard this as superseded by [#5547].

     

    Related

    Issues: #5547