Start to add quintuplet, septuplet and 9-tuplet support.

[ksatyaki]

Hello guys,
Hydrogen is wonderful, however it lacks a support for custom tuplet organizations. For example, you can have Quintuplets inside 4/4.. Just like triplets. With this, it would be very powerful drum machine.
Ideally, any number of tuplets should be possible.

I have added some code to make this possible. (Very very minimally). However, the visualization is not correct. But, when I add notes, they are added at the right places. I hope someone can help me fix the viz. I don't understand the code really well.

Thanks!
Chittaranjan

[trebmuh]

Sounds to be a great improvement. I'm looking towards to testing it when it's ready for that :)

[ksatyaki]

I guess you can test my branch already. But I haven't don't the visualization part yet. The quintuplets, etc work already. but one doesn't see the dashes where they should appear.

[SamuelMiller]

Hi,
I look forward to being able to create polyrhythms with Hydrogen. If you haven't already, you might want to check out orDrumBox to see a way of implementing custom steps per beat for each track. Thanks, Sam

[SamuelMiller]

Any progress in adding more possible beat tuplet resolutions to Hydrogen such as quintuplets and septuplets? Playing with time is what rhythm is all about?

[ksatyaki]

Progress was made. But ignored. Progress still exists.

[trebmuh]

@ksatyaki what do you mean by:

Progress was made. But ignored.

?

I didn't see any new commit here since the first one so I thought you do have no time anymore to dedicate to this feature. Am I wrong assuming this? Is there something new to test? Possibly the visualization part?

PS: Github tells me the file src/gui/src/PatternEditor/PatternEditorPanel.cpp is conflicting.

[oddtime]

Thank you so much for the job. I've just tested the mods (in v1.0.0 beta).
I like this feature development a lot.
In my opinion, from the solfege point of view, "8Q" should be called "16Q" - and so on for the other tuplets - since the notes of a quintuplet filling a quarter note are more similar to 16ths than to 8ths.

I note that the generated 'positions' for following tuplets are:
2Q : 0____________________38_______________76, 115, 153, (192)
4Q : 0________19__________38____________57, 76...
8Q : 0___9____19____28____38___(,48)...
16Q: 0, 4, 9, 14, 19, 24, 28, 33, 38, 43...

The algorithm does not solve the resolution problem, i.e. some notes are necessarily shorter/longer, but it's a practical way.
I had recently suggested for 5tuplets positions (0, 10, 19, 29, 39) which seemed more musical... but (0, 9, 19, 28, 38) come automatically with calculus approximation (if I understand the mod), so ok.

The "Fill note..." function has to be reviewed as the grid visualization.

[oddtime]

Still don't understand the code but I hope this helps reprogramming the grid visualisation.

It seems taking the second note position as a unit for all following tick lengths. But second note position is approximate to int. The difference could cause the problem

E.g. pattern size=192 (4/4 bar), in resolution 2Q: second note position = 38 while the exact position should be 48/5 = 38,4. The difference -0,4 times 5 (=number of ticks) equals -2.
The visualised grid gets to beat '5' two positions before the end of pattern (try to set res off and zoom: you can draw 2 notes after the visualised 'fake' beat-5)

[oddtime]

Ok now I understood how the grid vertical lines are set and can solve the visualization problem.

I would try to improve the placement of notes with round( (float) ...) to avoid rounding always down (does it make sense?)

Since I am working on the new beta, and I cannot compile the branch by ksatyaki which needs qt4, can I make a new pull request?

[SamuelMiller]

Thanks Oddtime for working on this. Adding full tuplet support is a must.

[oddtime]

Hi @ksatyaki see #759

[theGreatWhiteShark]

Hey @ksatyaki ,

Sorry for the late reply. The problem with the custom tuplet support is not so much the visualization but the fact that in it's current design/implementation Hydrogen is only able to support "approximated" tuplet. The results sound kinda like tuplets but most notes are off by a tiny but constant amount of time. This would be very undesirable for us as we want to deliver a drum machine as tight and precise as possible. The patch required to support floating point precision placements of notes is not trivial. But, fortunately, @oddtime is working in #1251 on an implementation and it already made good progress.

About this PR: Do you want to do some further tweaks or shall I close it as it is superseded by #1251 (without any notice I will do so in two weeks)?