Tuplets new support: please do give your opinion!! :)

[oddtime]

In pull Req #1251 (that replaces #1127) I am developing Tuplets. I suggest you to read the first message there, it shows shortly the idea for the core. //changed in #1251: note double tick positions

I already have some questions:

1. should the resolution combo box still include the Triplets items 1/4T, 1/8T...?
   the items 1/4, 1/8, ...1/64, off are enough for any resolution. Keeping triplets in the menu may be strange if you read next question.

2. after if you enter a tuplet ratio, when you change resolution, should the tuplet ratio be reset (making tuplet ''off'')?
   I think no.

3. Are you ok with this tuplet LCD?

I think it is very good to have such feature next to resolution, since it is really something linked to it mathematically (tuplets are the way to represent durations like 1/12, 1/17 that have not their dedicated notation symbol), and something I would like to use frequently ;). Also you have to see clearly if the current resolution is a tuplet resolution.

if you click on the tuplet LCD, a dialog pops up like the Pattern Size Dialog:

you can enter the tuplet ratio or just the numerator (in that case the most standard denominator will be calculated by hydrogen: eg 5:4, 3:2, 9:8...)

4. How to make tuplets inactive?
   now I simply click on the LCD and enter 4. quite fast, but if you like some faster toggle button or shortcut we may think of it.

5. How to draw tuplet notes? the gui should allow to see what type of tuplet the note belongs to, otherwise you may be in trouble finding out by ear/eye.
   I think that tuplet numerator is enough information for the user to set the proper grid tuplet resolution in order to edit the note.
   eg: quintuplets => show 5 someway, even if tuplet was entered as 5:3 you will get a proper resolution density simply selecting a sufficiently dense resolution (from Resolution combobox). Furthermore the same note position could be entered with many different tuplet ratios, all having numerator = 5
   Displaying the complete ratio is heavy as well.

We can discuss the core as well if you want. There are some doc comments inside the pull req.

I have not looked into the MIDI output yet. For midi file export an idea is to increase the tick resolution.

[theGreatWhiteShark]

Before addressing your questions I would like to zoom out for a minute. What do you think is the usual use case for the tuplets?

1. Right now we support triplets by altering the (whole) grid resolution. But this somewhat implies that everything in that pattern is a triplet. And if it's not, you change back the resolution and your triplet notes do look somewhat off the grid, which is strange. Also, when having multiple different tuplets in the grid they are quite hard to distinguish. Figuring out which kind of tuplet by altering the grid resolution would be too cumbersome.

2. Wouldn't it be better if "being a tuplet" is a somewhat "local" property of the grid? In a way that you work e.g. on a sixteenth resolution and add two triplets and a higher order tuplet within the same pattern. This local property could be a local change in the grid resolution or anything else. Important thing is that there is a visible difference between the tuplet and the regular note. (Let's keep it on a purely hypothetical level yet and let's worry about "how hard to implement" or "how severe the changes" later). The main difference compared with 1. is that the tuplet wouldn't be entered as a regular note but require a specific user intent for "creating a tuplet". This could be both right click + "add tuplet" and a keyboard shortcut. This local property could then be copying etc and be worked with like a regular note.

[oddtime]

There is one thing that I actually prefer in mode 2: the ability to start a tuplet subdivision easily from any position (e.g. an eighth-note triplet starting from the second eighth). In mode 1 it would be possible with a higher resolution
(I had this problem in mind and I thought to a custom offset in the grid).

Of course mode 2 would imply much greater work

[theGreatWhiteShark]

I think that we should rather give either mode 1 and mode 2 options in preferences

We can not drop the way triplets are handled right now because this would break existing songs.

Also, being unable to copy and paste a part of tuplets (not the whole) into another place is indeed one thing that I do not like in sibelius and musescore, because it makes tuplet note editing much slower in my experience.

This could be possible in both versions.

I like a lot the idea to split the instrument into multiple lines: still only one instrument (with its settings, volume etc) but up to many "voices", like in music notation.

+1

Of course mode 2 would imply much greater work

The main reason I have started to think about the very basics of interactions in the pattern editor here is that - at least for me - the triplet support in Hydrogen always felt more like a hack than a proper feature. It's nice to have but always was awkward to interact with. If we are not thoughtful when further developing this existing feature, we and a with an overall application that is worse in its general UX.

[oddtime]

The main reason I have started to think about the very basics of interactions in the pattern editor here is that - at least for me - the triplet support in Hydrogen always felt more like a hack than a proper feature.

Isn't it the case in Cubase also? I am not saying that it would be a justification, but I appreciate the triplet input quickness in H2

[theGreatWhiteShark]

Isn't it the case in Cubase also?

Uh, the most recent version I worked with was Cubase 4. And I can't recall doing anything else than recording audio.

I am not saying that it would be a justification, but I appreciate the triplet input quickness in H2

Sure. I think we can come up with a fast and intuitive input mode. I'm more concerned with the large number of scenarios we would have to deal with in method (1.). E.g. when the user copies the last two note of a quintuplet and inserts them at the second position of a triplet. There would be no grid able to represent it.

But I'm also not saying we should definitely pursue method (2.). There are probably other and maybe even better solutions out there.

[oddtime]

E.g. when the user copies the last two note of a quintuplet and inserts them at the second position of a triplet. There would be no grid able to represent it.

Right, I was thinking to that issue and I came to this reflection:
even if legit, such operation would be a very weird idea from the (probably unconscious) user. Only a sophisticated composer like Pierre Boulez should try to do it ;) so if the result is weird it's actually what he wanted.
In that specific example the representing grid resolution (for both notes) exists but necessarily very dense, if the grid has 0 offset.
I am indeed at this point now in the implementation (move/paste notes).

But with method 2 you wouldn't need to have very dense resolution, because you would have an implicit grid offset.
Still this would be the same weird rhythm :)

There are probably other and maybe even better solutions out there.

Yes, maybe this discussion can generate even further ideas. I shall continue to think about

[cme]

Hi guys, I'm trying to catch up here! I have only a few points.

1. I actually don't mind switching the grid resolution manually. If I write something that's mostly 4/4 with a few triplets (or offbeat triplets, etc) and keep the grid that way in general, it's easy to see which notes have a different division because they're the ones not on the grid.
2. Having a short-hand to treat tuplets as a single unit sounds handy perhaps, but limiting. Having it in addition to the more flexible (permissive) structure might be handy, but should only be shorthand for what's underneath.
   At the moment, when I keep the grid res set up for the natural division, it's easy enough to manipulate an off-the-grid tuplet by selecting it and dragging it to a different location, etc.
3. Between "length" (with denominator), "res" and "tuplets" (itself having 2 numbers) it looks like there's quite a bit of redundant information. A bit daunting for users, it should be possible to simplify. There are really only 3 things, how long the pattern is, and how many things it's subdivided into
4. A lot of folk I know don't understand what a "tuplet" is (so many times I've heard people refer to 3 regular notes as a "triplet"), is there a better term that can be used, such as "division" (a la MIDI) etc?

[theGreatWhiteShark]

I think that @theGreatWhiteShark was thinking also in case a user wants to make even more complex patterns including triplets, quintuplets or septuplets... in that case I would be in trouble without any hint.

Yes. And the fact that most users asked for this feature in combination with "polyrhythm". But when we integrate the "add voice" feature in the pattern editor (the respective instrument get's another line to insert notes), it should be rather easy for the user to get their note hygiene straight. With this we won't need to make such big changes as (2.).

Still, when featuring a large set of different tuplet grids 'being off the grid' is not a clear indication of a note anymore. But this could be a different symbol, color, keyboard shortcut to switch to the grid the note was created in etc.

I thought the same and I would like to set just the resolution indeed, but unfortunately it doesn't represent the way used in music notation. I think a common musician (thinking to my colleagues) is not intuitive nor informed enough to set quarter triplets using resolution=1/6 or eighth quintuplets with res=1/10 or 16th-septuplets with res=1/28...
But they could learn it in Hydrogen! XD.

I wouldn't be able to use this 😉. I also wouldn't understand the term 'tuplet' without looking it up. But the latter shouldn't be much of an problem.

How about we have our current resolution dropdown with 1/4 till 1/64, after that a separator and right below a fold out menu providing checkbox for the different tulpet kinds. So, the users would set a number resolution, like 1/8, and can use the menu to switch to 1/8 quintriplet. Changing the numerical part to 1/32 would yield a 1/32 quintriplet grid until option 'off' is set in the truplet menu. This would behave more or less like our current version with the triplet being located in the same dropdown underneath the "regular" grid resolutions.

[oddtime]

How about we have our current resolution dropdown with 1/4 till 1/64, after that a separator and right below a fold out menu providing checkbox for the different tulpet kinds. So, the users would set a number resolution, like 1/8, and can use the menu to switch to 1/8 quintriplet. Changing the numerical part to 1/32 would yield a 1/32 quintriplet grid until option 'off' is set in the truplet menu. This would behave more or less like our current version with the triplet being located in the same dropdown underneath the "regular" grid resolutions.

I am not sure to follow, you mean classifying tuplets in a menu? They are infinite...

[oddtime]

I wouldn't be able to use this wink.

Don't be humble! ;)
So my hopes to have beautiful fractional resolutions after @cme's comment are vanishing ;)

[theGreatWhiteShark]

I am not sure to follow, you mean classifying tuplets in a menu? They are infinite...

You are right. But I would spell out the first 3 or 4 and than add a "custom" (or "other" etc.) entry to manual set higher order ones.

The reason for this is to provide a consistent UX. Currently users are used to set the triplet grid using the options in the lower half of the resolution menu. When the tuplet support will be added they try to do the same but don't find what they are looking for anymore. If there is a menu in the bottom of the same widget which unfolds and provide the clickable option "triplet", probably most people will get acquainted with the new feature by themselves. If, instead, a numerical value of 1/6 has to be entered, almost everyone not following this discussion will be lost. Since our task is to fix bugs, to repair inconsistencies, and to remove some dust from this awesome application someone else did developed, avoiding such frustrations is amongst the top priorities. Else people will just stick with the previous versions.

[oddtime]

Ok

[oddtime]

The comment about redundancy and the term "tuplets" by @cme made me think to this alternative way to set the grid resolution. It is just an idea, basically fits in "mode 1", as we called it in discussion with @theGreatWhiteShark, even more difficult for the complexity that it allows but more powerful:
No tuplet LCD
Instead we add an item in Res Menu called "Custom Grid".
When you select that item (adding a keyboard shortcut to it is good) a dialog is created and there you can set the resolution as (Quantum Length in whole notes units) with numerator/denominator AND a grid offset (always with same units) with other numerator/denominator.
The use of the offset is to handle tuplets starting at upbeat positions, or in compound meters..., more easily. For example

On "Ok pressed" the resolution and offset could be displayed in the res LCD (whose spaces would be increased).