I redeveloped some of my ideas on how BitByte MML will save music. A 30,000x16 element array will store music data, with the first 28,800 for notes. The last 1,200 will detail things such as a change in modulation, and the position of any of these effects, as well as their operands.

Each element represents one frame; a 60th of a second. The precise frame is recorded with any effects, for where they will go. For notes, a five-digit hexadecimal value converted to decimal will store data for the note, in the format "11223".

The 11 spot will detail which key the note is, every 12 notes will change to a new octave. The max value here is 120. The 22 spot details note length, exactly as it appears in MML; 01 is a whole note, 04 is a quarter, etc. If this is over 60, it is a dotted length, of however much over 60 it is. 61 is a dotted one (1.) or 74 for dotted 14 (14.)

If the 3 spot is 1, then the note is joined with the next. If it is 2 it is joined in a portamento. For effects, the format is "1111233", 1111 is the exact frame for the effect. 2 is the type, specifying whether this is the tempo command or envelope or so on. 33 is the value of the effect.

Commands such as tone, tempo, or envelope will need more than one operand, or a larger number than 255. In those that need a larger number, the 33 spot is not used and instead the next element in the array is used for the command value. If the command needs multiple operands, the first will be taken from the 33 spot, and the rest from the next element, as a 6-digit hexadecimal number.

Would this work? Or am I overcomplicating this?

30,000 X 16!?? Does it depend on sequential sorting? I don't know this is too complicated for me.

Sixteen arrays because you can have up to 16 tracks at once (the : command says 0-15) and 30,000 because every element is a 60th of a second, thus there are 3,600 frames per minute so you can make up to eight minute songs with this program. The last 1,200 are for modulation, in each array.

Mm, I completely misunderstood, my bad.

Nah, that's OK. I'm kind of questioning it though, because I really feel like this is a way more complicated system than it needs to be. Then again, I can't think of any better way to precisely store all the data in a format the program can read and write.

Cool, well I'm not sure there is an easier way. As far as I can tell, these kind of apps are complicated.

I'll probably just check out how Litterbox does it, and if it's better maybe base my idea off of it, if it's about the same I guess it will stay as is!