I recognize that mml formatting :) I think, I imagined people would just do something like: VAR SONG_ARRAY$ LOAD "TXT:SONG_FILE.MML",SONG_ARRAY$ Instead of copying the song data directly into their program. Might be easier to manage that way, in case you change the song in the editor.

I certainly will, that's a great suggestion

Since the top bit is the sign bit, large values turned negative during sort and ended up before other notes. First step in building MML is to determine how many leading rests are before the first note, since the first note is actually very far into the pattern (usually around 16 measures), it padded the song with a bunch of silence. TL;DR, Sign bit screwing me up during sort function

Note data has multiple components: Position, Channel, Length, Value; which is packed into a single 32 bit integer. The position value is stored in the top 12 bits, and when MML strings are being generated for playback or export, the pattern array is sorted by position in timeline. Since the position is in the top bits, I sort without bitmasking or shifting (optimization)....

Litterbox - MML Tracker Key: [ NDKJR3X3 ] This update fixes an issue with notes during playback if the position value is past 2047. Technical details in the comments. Old songs should still work, this update just fixes playback in the editor.

Ok, I've updated the program to fix this issue, here's the new key: [ NDKJR3X3 ] Thanks for reporting this. Happy composing!

This'll be a very rewarding project, good luck!

Ok, I figured out the issue. I need to get to bed, but I'll try and upload the fixed version over the weekend (need to double check something before I do). It was a problem with how I optimized my bubble sort, which compares the top 12 bits for the note position. The signed bit gets flipped on, resulting in high numbers being turned negative, and sorted before the first note in the pattern.

In the meantime, you can keep working on your song if you want, you just need to reduce the number of measures from 20 to 16, and just add a second pattern to continue adding notes. It's probably easier in the long run to work with multiple patterns as you can organize parts of your song and don't have to scroll so far to make edits. I'll let you know when there is a patch. Thanks!

Quick update; this is certainly a bug. I haven't determined why it happens, but it is only on the editor side. You song is perfectly intact and all the notes are there. The issue has to do with the way I calculate leading rests between notes. For some reason when there are more than 16 measures in a pattern, it adds 16 measures worth of rests. I'm debugging now, but I'm happy your song is OK.

Thanks Lizards, I'll take a look at it.

Oh, that's strange. Hmmm. Are there any other details you can tell me? This might be a bug in the editor. When did you start seeing the issue? After a specific operation? (sav,load,etc..) This is a big ask, and I'll understand if you don't have the time, but if you upload the SNG file for your song and send me a key I'll be more than glad to try debugging it to figure out what happened.

It looks like you have 4 measures of rests in your song at the beginning. If you left empty space at the beginning of the song you'll get silence. You might double check it. When you press "X" in the note editor to play the song, what happens? Do you see notes at the beginning?

MML isn't a regular SmileBASIC program. That is to say, you can't execute it. To play back that song, usually you would just read the file into a string array and tell BGMPLAY to play it. However, to keep things simple, you could surround your above code snippet with quotations and put BGMPLAY in front of it. Like this: BGMPLAY "{P0C0=@99......{P0C1}]" (the .... are just placeholders)

Woah, this is a surreal moment. Thanks for the shoutout Devon! Alternatively, Lizards, you can find the key for Litterbox under my play journal posts.

Been waiting since day one for this!

You are assigning PTWOHIT, in what looks like a comparison operation. Maybe you meant: IF PTWOHIT==TRUE THEN...

YASSS! Nice job dude!

Sub folders inside projects. Would help keep data organized and project clean.

User defined constants would be nice. Something like: DEFINE #SOME_THING 10 VAR A=#SOME_THING * 2 'Or however you want to use it At the moment, user constant values can only be expressed explicitly, which isn't as descriptive as a definition name. Using a VAR to hold the value, doesn't protect it from being overwritten and wastes memory.