Visually distinct triplets (issue #125)

[manumeter]

PR for #125 (as requested).

[estellecomment]

Great, thanks ! ❤️

The display looks a bit different on my machine than for you... For "4/4 with triplets", the X are now very close and stepping on top of each other. I'm not sure if I'm clicking in the right place or not. A little bit more space would be nice.

When I switch to "24" I get this :D (looks like veeeerrrryyy faasssstt playing)

[manumeter]

Yes, this is actually intentional because I tried to improve the situation in upstream where, if you have some triplets, doubles, shoutings or so, the whole table column shifts and what should be evenly spaced by sound is not anymore visually, so I switched to a fixed with per beat. And for patterns with a high amount of subdivisions, this requires (visually) overlapping strokes, but this should actually never happen in reality, because patterns with 12 or even 24 subdivisions don't need this because they are so fast but because they combine different tempos (like doubles and triplets). So you just need to leave the correct amount of empty spots between your strokes (depending on the tempo). Or do you actually have a use-case for that many strokes per beat?

By increasing the width per beat, the table gets very wide for something like 24 intersections with no real need, which decreases readability in my opinion. (Like in the screenshot here: #125 (comment))

[manumeter]

But, what would be a nice feature idea: When changing the subdivisions, the pattern could be streched/shrinked to the new time signature. Of course shrinking would not be possible without loss.

[estellecomment]

I think the misunderstanding is this : with 24 subdivisions, I'm indeed able to write rhythms in code, but not able to compose them by clicking in the interface, because the subdivisions are too narrow.

Example : I have written a rhythm in the code for the repique. In the interface, I try to make the snare play the same rhythm as the repique. This happens :

Screen.Recording.2025-11-27.at.19.57.33.mov

In the interface, with the fixed width and the very tiny subdivisions, I cannot click precisely enough to place my strokes, I don't really know if I'm clicking at the right spot. It's also difficult to remove a stroke, because it's hard to click on the stroke itself, I often click on an empty space next to it instead.

Up to 12 subdivisions ("4/4 with triplets") it's still doable 👍 (though also a bit tricky)

I do agree that before this PR, like in the screenshot, the width is too much, it makes it hard to read.
Could we use something in between?
Or use a fixed width if time <= 8, and a width proportional to time if time > 8 (for example) ?

UX-wise, I think the best way would be to allow to change from binary to ternary by hand for each beat, and thus display only the necessary number of subdivisions (either 8 or 6, rather than 24), which would make it easy to use and understand. But I don't have an easy way to do this :)

[estellecomment]

Actually, I think we should move this width debate in another PR. Because the display of triplets is really the point here, and will be helpful regardless of width. What do you think ?

[estellecomment]

This does not work in the Compose tab, because strokes are < a > links. This rule is overriding the color change :

Also, < a > links are blue by default, so maybe green would be a good color for triplets ? (or something else)

This would work for example :

                &.is-triplet {
					color: var(--bs-green);

					a {
						color: var(--bs-green);
					}
                }

[estellecomment]

would you consider giving graphical examples, things like : X X, so that it's easier to understand ? I'm struggling. :)

[manumeter]

Okay, I try to visually explain the different cases:

          idx
           |
           v
 CASE1:  X.X
       X...X
   X.......X
 CASE2:    X.X
           X...X
           X.......X
 CASE3:   X.X
        X...X
         X.......X
 CASE4: |........X...|X...X..

BTW this function could be made more efficient for sure (it's slowing down everything for large patterns, but I don't know how to elegantly solve this without the recursion I used).

[manumeter]

Hmm, I see your issue. (Never was one for me because not many people write rhythms in our player and if I do it, I use the keyboard, especially for more complicated stuff.)

Maybe we should separate the use-case of listening and the use-case of composing patterns. In the listen UI, I still think evenly spaced bars make the most sense, independent of the number of subdivisions. But we could increase the width in compose mode to make it more user friendly. What do you think?

And regarding colors: I thought the coloring of triplets in the compose mode is not important, only in the listening UI. But I can change that to also color links if you want. (And I chose blue because it's already an existing convention with us to have the triplets in blue. But we can change that upstream if needed and I will patch it back to blue for our instance.)

Regarding splitting the PR: Hmm, you're right, strictly speaking, it's a different issue. But since the triplet thing also requires a lot of CSS changes in the same area, I'd rather keep it together to avoid having two conflicting PRs.