Write a triplet of 16th followed by an 8th. The sum of all this is one beat, so it makes sense to beam them together for readability. But if you do that, the triplet symbol disappears, making the whole thing more than one beat.
Testing PR42, the rendering in notation looks wrong. The "3" shifts to the right and is balanced with all four notes instead of being balanced with the first three. I assume some work needs to be done on the notation renderer to fix this.
@lman, can you take a look at PR42 and see if it makes sense to you? Is this the right way to fix this issue? I only noticed one issue with how it displays on the screen.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My first impression is that this will do no harm - the change is very specific to this particular case.
I think the problem of the tuplet text positioning can be fixed.
There are still some issues - I discovered that the case where a quaver is followed by a semiquaver triplet still does not work ! Maybe David can look into that one too.
The change is unconventional - a group which contains different beam types - but this is probably the only way to achieve what is wanted.
It's possible other tuplet logic may break but only in the particular case here.
I think we should go with the changes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I believe I have a fix for the positioning of the tuplet text. I have also added the tuple line in this case - as lilypond does.
When David's change is in master I will add this fix.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Possible fix: https://github.com/tedfelix/rosegarden-official/pull/42
Testing PR42, the rendering in notation looks wrong. The "3" shifts to the right and is balanced with all four notes instead of being balanced with the first three. I assume some work needs to be done on the notation renderer to fix this.
@lman, can you take a look at PR42 and see if it makes sense to you? Is this the right way to fix this issue? I only noticed one issue with how it displays on the screen.
This is an interesting idea - having a beamed group with different beam types !
Let me look into it.
My first impression is that this will do no harm - the change is very specific to this particular case.
I think the problem of the tuplet text positioning can be fixed.
There are still some issues - I discovered that the case where a quaver is followed by a semiquaver triplet still does not work ! Maybe David can look into that one too.
The change is unconventional - a group which contains different beam types - but this is probably the only way to achieve what is wanted.
It's possible other tuplet logic may break but only in the particular case here.
I think we should go with the changes.
I believe I have a fix for the positioning of the tuplet text. I have also added the tuple line in this case - as lilypond does.
When David's change is in master I will add this fix.
With my change the quaver + semiquaver triplet seems to work too !
Here before beaming,
And after
Oh... meanwhile I pushed a fix for that too, in https://github.com/tedfelix/rosegarden-official/pull/42
OK, yours looks better (with the bracket above the 3). I'll remove mine. If you're curious you can read it at http://www.davidfaure.fr/2026/0001-Fix-tuplet-bracket-lost-when-beaming-across-a-tuplet.patch
Last edit: David Faure 2026-03-25
Yes - my code is very similar !
I've pushed a new bug1773 branch which includes @dfaure_kde's change:
https://sourceforge.net/p/rosegarden/git/ci/bug1773/tree/
@lman, please apply your changes to that branch and push a new branch for me to review/test/merge.
OK. See merge request.
Last edit: Ted Felix 2026-03-30
David and Philip's changes pushed as [545738]. Please test latest git.
Related
Commit: [545738]