bug-lilypond
[Top][All Lists]
Advanced

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

Re: Auto-beaming issues


From: Mats Bengtsson
Subject: Re: Auto-beaming issues
Date: Wed, 29 Mar 2023 11:38:56 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0


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




reply via email to

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