Re: Auto-beaming issues

Mats Bengtsson <[email protected]>
Newsgroups gmane.comp.gnu.lilypond.bugs
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.