On 2023-03-28 20:45, Jean Abou Samra wrote:
(CCing Jason Yip, who may be interested in this as part of this GSoC
application on the auto-beaming project.)
Yes, I had that in mind, but since the main topic of the GSoC was beam
subdivisions I hope that you Jason can find a suitable delimitation of
the project so that it doesn't grow out of bounds. Only consider my bug
report if it's closely related to what you anyway want to do within the
project.
Le mardi 28 mars 2023 à 14:50 +0200, Mats Bengtsson a écrit :
Hi,
I know that there are several old bug reports on auto-beaming, but
I've
come across a couple of problems that are not necessarily covered by
the existing reports.
Problem 1: Automatic beaming doesn't always work if a voice context
ends in the wrong place. This might be closely related to #4690, but
I'm not sure. Example:
\version "2.24.0"
\score{
\new Voice \fixed c' {
<< { e8 f } \ c4 >> g2. | % Autobeaming fails!
<< { e8 f g f } \ c2 >> g2 | % Autobeaming successful!
<< { e8 f g f e f } \ c2. >> g4 | % Autobeaming fails!
<< { e8 f g f e f g f } \ c1 >> | % Autobeaming successful!
}
}
The |<< \\ >>| create new voice, and each Voice context has its own
beaming engravers. It works if you make one of the Voice contexts
continue from the polyphonic passage into the monophonic one.
I don't agree on your conclusions. The current logic in LilyPond says
that if there is a series of beamable notes that is followed by a rest
or a space or a non-beamable note before the moment of time where the
beam normally would end according to the auto-beaming rules, they still
get a beam. Examples:
\score{
\fixed c' {
e8 f g2. |
e8 f r2. |
e8 f s2. |
e8 f g f e f g4 |
e8 f g f e f r4 |
e8 f g f e f s4 |
}
}
The only thing I'm requesting here is that the same should happen if the
series of beamable notes appear just before the Voice context dies.
|\version "2.24.1" \new Voice \fixed c' { << { \voiceOne e8 f } %% no
\new Voice ! \new Voice { \voiceTwo c4 } >> \oneVoice g2. } |
I don't think it's possible to make your input "just work" because
|\version "2.24.1" \new Voice \fixed c' { << { e8 8 8 } \\ { c8 8 8 }
>> d } |
does not tell if it should be engraved as
|\version "2.24.1" \new Voice \fixed c' { << { \voiceOne e8 8 8 } \new
Voice { \voiceTwo c8 8 8 } >> \oneVoice d } |
or
|\new Voice \fixed c' { << \new Voice { \voiceOne e8 8 8 } { \voiceTwo
c8 8 8 } >> \oneVoice d }|
|Following the logic I explained above, it shouldn't be engraved as any
of these, rather it should be engraved as
|
|\new Voice \fixed c' {
<<
{ e8 [ 8 8 ] }
\\
{ c8 [ 8 8 ] }
>>
d
}
Which would be exactly what I would expect (since I'm telling LilyPond
to create new temporary voices). If I wanted to typeset music where, for
example, the upper voice is beamed together with the next note, I would
tell LilyPond that it's actually the same voice, as you did in your
first interpretation:
\version "2.24.1"
\new Voice \fixed c' {
<<
{ \voiceOne e8 8 8 }
\new Voice { \voiceTwo c8 8 8 }
>>
\oneVoice
d
}
However, in that case, I would still expect the lower voice to have
three beamed notes, note three unbeamed notes. This, again, illustrates
the problem I want to highlight and it would produce the expected result
if the beaming algorithm treated end of Voice the same as rest/space/any
other unbeamable event. The extrapolation to Issue #4690 would be that a
manually inserted bar line also would be treated in the same way, i.e.
as a trigger to end any ongoing prospective beam.
|
||
So, no bug here from my point of view.
I hope I have convinced you that it is!
Problem 2: ...
Looking quickly at auto-beam-engraver.cc, it looks as if
Auto_beam_engraver::recheck_beam () is supposed to handle the problem I
described. I'll take a more detailed look and see if I can also find a
way to solve Problem 1.
Feature request: It would of course be desirable to have more rich
possibilities to express beaming patterns, where I for example
would be
able to express beaming patterns so that the previous example
automatically gives the same as
\score{
\fixed c' {
a8 [ g ] f8.-\trill [ ( e32 f ) ] e32 [ f g f ] e [ f g f ] e4 |
}
}
Sounds interesting. You understand more about this topic than I do,
maybe create the tracker issue yourself?
I'll give it a try.
/Mats
