Tuplets are not converted correctly from MIDI

[kernighan]

If importing a MIDI that various tuplets, the values used are incorrect. For example, an 8th note triplet should be a length of 12. So what I would expect for an 8th note triplet of: 'ede' would be:

e12d12e12

But what gets generated is:

l16e19.d.e19.

This doesn't even sum up to a valid value, is it is longer than a quarter note, and will cause de-syncs in the music.

[fourthline]

It cannot be done because it is aligned with L64. Most data will be unreadable without alignment.

[kernighan]

This is a factually false statement. 3MLE is able to import tuplets that while not entirely correct at 64th quantization at least are correct in total length. an 8th note triplet is supposed to take the same time as a quarter note. Your current code is longer than a quarter note, making the import literally break the ability to keep tracks in sync.

[fourthline]

L64 = 6tick (Resolution 96) triplet L12 = 32tick (Resolution 96) 32 / 6 = 5.3333333.....

[fourthline]

Even the version of 3MLE I have on my PC has L64 alignment, so I can't seem to import triplets in L12 representation.

[Lisedrika]

This is a factually false statement. 3MLE is able to import tuplets that while not entirely correct at 64th quantization at least are correct in total length. an 8th note triplet is supposed to take the same time as a quarter note. Your current code is longer than a quarter note, making the import literally break the ability to keep tracks in sync.

If the tool doesn't convert triplet perfectly, it doesn't mean anything. It only adds to the annoyance of editing. :(

[Mabinogi-delight]

I can understand the frustration but I know exactly why it happens.

The real issue is that, when converting from MIDI to MML, some midis (or tracks) are not perfectly quantized. Since a 64th note is only 6ticks (under 96TPQN condition), while a 48th note is 8 ticks. Some tracks can have an offset of 2~3 ticks (especially for instruments with longer attacks, like string instruments), if tuplets are allowed, we need to find a way to solve this issue.

Currently, what I am doing with midi files with large amount of tuplets, is to scale note length by 1.5 or 0.75 to get rid of 1/3 factors in note length, and make adjustments accordingly.

As for MabiIcco, I can think of two ways to improve (that will require a lot of hard works from Fourthline of course).

First way is to have a separate option to convert tuplets while importing midi. However, prior to converting, midi files needs to be quantized correctly, and starting time for each track need to be aligned to proper resolution (say 16th) to avoid confusion.

Another way is to have a function that converts selected notes to tuplets (just like how reduced rest notes functions). You select notes you want to convert to tuplets, you use the "convert to tuplets" function, and it will find all selected notes by group of 3's, calculate the total duration to nearest 2^nth notes, then divide by 3 to set the new note length.

for example, if you select d+16&d+64e16.f16&f64, there are three notes in total: d+, e and f the total duration is 30+36+30 = 96 ticks

Therefore, each note's duration should be 96/3 = 32 ticks, which means they should be 12th notes. So after the conversion, they should be L12d+ef

[Lisedrika]

I can understand the frustration but I know exactly why it happens.

The real issue is that, when converting from MIDI to MML, some midis (or tracks) are not perfectly quantized. Since a 64th note is only 6ticks (under 96TPQN condition), while a 48th note is 8 ticks. Some tracks can have an offset of 2~3 ticks (especially for instruments with longer attacks, like string instruments), if tuplets are allowed, we need to find a way to solve this issue.

Currently, what I am doing with midi files with large amount of tuplets, is to scale note length by 1.5 or 0.75 to get rid of 1/3 factors in note length, and make adjustments accordingly.

As for MabiIcco, I can think of two ways to improve (that will require a lot of hard works from Fourthline of course).

First way is to have a separate option to convert tuplets while importing midi. However, prior to converting, midi files needs to be quantized correctly, and starting time for each track need to be aligned to proper resolution (say 16th) to avoid confusion.

Another way is to have a function that converts selected notes to tuplets (just like how reduced rest notes functions). You select notes you want to convert to tuplets, you use the "convert to tuplets" function, and it will find all selected notes by group of 3's, calculate the total duration to nearest 2^nth notes, then divide by 3 to set the new note length.

for example, if you select d+16&d+64e16.f16&f64, there are three notes in total: d+, e and f the total duration is 30+36+30 = 96 ticks

Therefore, each note's duration should be 96/3 = 32 ticks, which means they should be 12th notes. So after the conversion, they should be L12d+ef

I think it's a good idea. This problem is not unique to Mabiico, and I remember that even commercial programs are not completely solved. It's a technology that's easy to say, but difficult to implement.

But, the second way makes my heart flutter. It would be so comfortable even with that much function. :D

[fourthline]

Thank you for your wonderful suggestion. I made a test version. v1.2.79

1. Option to unalign when reading from MIDI: default is unaligned, options 2tick, 6tick can be selected

2. Convert to tuplet function: You can select multiple notes and execute from the right-click popup menu

[Lisedrika]

Thank you for your wonderful suggestion. I made a test version. v1.2.79

1. Option to unalign when reading from MIDI: default is unaligned, options 2tick, 6tick can be selected
2. Convert to tuplet function: You can select multiple notes and execute from the right-click popup menu

That's very cool! It is inconvenient to enter the end of the last note well, but it is encouraging that input that has not been possible. And finally, Mabiicco can replace 3MLE completely.

[Lisedrika]

I think it can all be applied to the divisor of 960. Please check.

And here is a test MML

[fourthline]

Do you mean that you want to do something like the following? MML@r1l10<cccccccccc<gggggggggg>cccccccccc<ggggggggggr1>l9ccccccccc<ggggggggg>ccccccccc<gggggggggr1>l5ccccc<ggggg>ccccc<ggggg,l1rgegergegergege,;

In the Mabinogi environment (96TPQN), L5 and L10 are not divisible, so I think they will be out of line with other notes.

L1c = 384tick (96TPQN) L10c = 38.4tick (Cannot be expressed under 96TPQN)

[Lisedrika]

Do you mean that you want to do something like the following? MML@r1l10<cccccccccc<gggggggggg>cccccccccc<ggggggggggr1>l9ccccccccc<ggggggggg>ccccccccc<gggggggggr1>l5ccccc<ggggg>ccccc<ggggg,l1rgegergegergege,;

In the Mabinogi environment (96TPQN), L5 and L10 are not divisible, so I think they will be out of line with other notes.

L1c = 384tick (96TPQN) L10c = 38.4tick (Cannot be expressed under 96TPQN)

Oh, I was confused for a moment. The present is the most accurate. Please forget the optimization feedback written above. I deleted it. :D

[Lisedrika]

Translation correction is required.

연표로 변환 ▶ 잇단음표로 변환

[fourthline]

Released in v1.2.80