DO NOTE: IT IS AN APPROXIMATION of 14EDO, not 14edo itself (sadly)

anyway to elaborate on the description:

moai🗿 files store notes as 12edo numbers, e.g., if 0 is some base note, a moai🗿 note with a value of 1 would be one semitone ABOVE the base note 0. This means a multiple of 12 in any moai🗿 note will be an OCTAVE. therefore, it is just a matter of mapping the microtonal notes onto maoi's 12-tone readable format.

FOR EXAMPLE if we wanted 14edo, the 'note space number line' is SQUISHED such that EACH multiple of 14 is now a multiple of 12, if that makes sense?

the math i discovered:
interval=12/EDO
pitch=(pitch*interval)+interval

However a problem i experienced is that it still sounded off (atleast compared to the .mptm 14 edo file!), i have no idea why, it LOOKS like the octaves were working, but some of the chords have a slight difference, some were really different. IDK if i got the maths wrong or if maoi🗿 doesnt store pitch numbers linearly like i imagined?? i hope to figure it out maybe

ALSO while the it2moai converter does work on .it, it also works on .mptm! this is because .mptm is just an extension of .it

i originally wanted to make a custom parser to detect the .mptm tunings and apply it to converted moai🗿, but idk how to parse files and had issues understanding the mptm 288 chunk structure

. i made an effort though and i did end up learning a few things about it so im pretty content with the experience

anyway, all in all this was very fun. even if the notes are a little off from 14edo, it sounds close to my .mptm file, and it just means i may have more time to FINE TUNE the code i added (as well as the notes ^_^)

thanks for reading!

breaking new ground! Awesome

this is SO cool, SO SO cool, it seems so obvious now that you did it but i never once thought to try using decimal values for pitches in moai...! HUGE potential. i would be very interested to give this a try myself if you're willing to share your script, but no worries if you'd rather not

i too am a little confused by the discrepancy of pitch thing; i even looked at your pitch values in the .moai file compared to the freq values of a 14edo .scl file and they look correct. i also briefly made a test file to see if maybe the moai pitches weren't that granular, i tested out to two decimal places and still heard a difference, so i feel like it ought to be at least "accurate enough". the linear thing might be it, but that seems kind of strange if so.

gosh even besides the microtonal aspects of this, combined with the new Note Volume feature you could utilize slight detune to create chorusing effects or for reverb/delay..

++ for innovation
i know youre not happy with the accuracy but to a lay listener we are not going to notice that it is not exact, only that it is deliberately inexact from 12s (the main point). though im sure the answer will be found to fix eventually

i was curious about this so i played around with editing a save file and the tuning seems accurate to me. maybe a problem with the conversion math?

hm. im not too sure what you mean lol; my conversion maths, or do u mean the way moai itself converts the pitch numbers into frequencies? because if the tuning is accurate, wouldnt the conversion maths be fine, too? unless theres something im missing out

sorry, what i meant was that the way moai converts pitch numbers into frequencies seems "linear" (really logarithmic) and accurate, so the problem might be a bug in the it2moai edo tuning code

that being said, i just checked the save file programmatically and all the pitches are offset from zero by some multiple of a 14edo-step, so the code is definitely generating 14edo

ahh okay. i see
hmm.. when i get the time, i'll try looking into this!

unlikely, but im thinking that the issue could be to do with all the floats? glancing at the note nums in my .moai entry, there are SO many decimal points..
im curious if moai engine is unable to interpret decimals with high precision. coz IF that is true - and moai would have an easier time with deci-nums like .5 or .75 (instead'f something like .560777056) - THEN, in the context of my edo tuning code, we should see that the edos of simpler producing decimals (e.g. 24edo[.5] or 48edo[.25]) would play more accurately in moai

the lack of exact values is just a limitation of float precision (but not in a way that should lead to any audible artifacts). the amount of decimal places shouldn't be a problem since parseFloat is built into js and doesn't have issues with that

like i mentioned in my original comment i did compare the values in your song with the values in an .scl and they were the same, so i'm a bit at a loss about the accuracy. i could tell audible differences out to the hundredths place when i experimented with moai but didn't keep testing beyond that and i guess there could still be inaccuracies on its end

hmmm.............................