[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
beam:
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 ...
Best
Urs
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
beam-subdivision.png
Description: PNG image
document.png
Description: PNG image
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Another beam subdivision issue,
Urs Liska <=