[Top][All Lists]

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

Re: Another beam subdivision issue

From: Urs Liska
Subject: Re: Another beam subdivision issue
Date: Tue, 8 Dec 2015 18:47:13 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

I've now discussed this with Carl, and we came to the conclusion that I
can partially revert 0382ed88.
But I would like to fix what Carl tried to fix with that commit,
although it seems more complex than he thought.

Beam subdivisions should reflect the longest conceivable subsequent group:

  \set subdivideBeams = ##t
  \set baseMoment = #(ly:make-moment 1 32)
  c''64^\markup{"baseMoment 1/32"}[ \repeat unfold 14 {c''64} c''64]

should result in a sequence of 3-2-3-1-3-2-3 subdivision beams, like in
the first attachment.

However, the implementation currently doesn't take into account whether
the subsequent group is actually complete:

\relative c' {
  \set subdivideBeams = ##t
  \set baseMoment = #(ly:make-moment 1/32)
  c64  \repeat unfold 11 c r16  r8

produces a single beam at the second-to-last subdivision (see second
attachment). However, as there is only a 16th worth of actual notes in
the last group we think this second-to-last one should have two beams.

The current code in beaming-pattern.cc seems to only reflect the current
position in the rhythmic pattern and not to be aware of how long the
remaining beam really is.
I have tried to get somewhere in Beaming_pattern::beamify, but I have to
admit it's over my head to understand and modify that code. I have the
impression the necessary information should be present, though.

What I think should be calculated is:

  * Get the total duration between the current moment and the end of the
    infos_[infos_.size () - 1].start_moment_ - infos_[i].start_moment_
    was what I came up with, but that gives the duration until the start
    of the last not under the beam (???)
  * Apply the number of beams that would be applicable if the next group
    was that long.
  * In the above example the length of the remaining actual group is
    1/16, so it should return two beams
  * If the remaining groups were 3/32 it should also return two beams

So if someone could help me to retrieve that information from the
variables that are around within that function I would be happy to give
it a try. Of course ready-made solutions are OK too, but I'd be willing
to learn ...


Am 25.11.2015 um 16:34 schrieb Urs Liska:
> After completing my patch for #4664 I tested beam subdivision with
> another example and was unpleasantly surprised that the other example
> produced a wrong result.
> This example should render the subdivisions with a regular alternation
> of two and one beams. Instead all beam subdivisions show two beams
> (first attachment):
> \relative c' {
>   \set baseMoment = #(ly:make-moment 1/16)
>   \set subdivideBeams = ##t
>   c64 [ \repeat unfold 30 c c ] 
> }
> After initial shock I investigated and found out that this is *not* due
> to my patch but to commit 0382ed88 where Carl modified some behaviour of
> his patch for #4355 in 8fa2d858.
> After partially reverting 0382ed88 the example renders correctly as in
> the second attachment. There I have two groups, one with a manual beam
> exposing the new behaviour of my current patch.
> ###
> Carl, can you tell me what you intended with that adjustment? I can see
> two possible purposes:
> - you thought the behaviour with alternating beam numbers is wrong
> - something else I can't see from here.
> If it is the first one I would like to partially revert that change to
> the behaviour of your original patch for 4355. In the other case please
> tell me what you were after.
> Urs

Attachment: beam-subdivision.png
Description: PNG image

Attachment: document.png
Description: PNG image

reply via email to

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