I haven't been working on this much lately, but I finished the 'add channel' menu! That is, the interface part of it - without the ability to place notes, and with the buttons and sliders not yet functional, it's pretty useless right now...

Yeah, you'd use SPCHR (The format is 'SPCHR Control Number, U, V, width, height, attribute' I think) but remember, if you do not specify the width or height it will default to 16 by 16. This means a 24*32 sprite, for example, would change to a 16*16 one. SPCHR also keeps the sprite color, rotation, scale, etc. values how they were (a sprite made red with SPCOLOR will stay red, etc.)

This is still very much work in progress. I haven't even added note placing yet!

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!

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.

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.

Would this work? Or am I overcomplicating this?

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.

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.

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.)

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".

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.

Since SmileBASIC can only handle a number as large as a 7-digit number, an additional spot will need to be used and therefore will block an area from placing notes - part of the downside to my idea. Would this be a good system, or should I probably use something else?

If the note was specified as what will be treated as an effect, plenty of the effects will need more operands. If it is just something like the "Q" or "L" commands, they will get their operands from the "length of note" spot, as that part is irrelevant to everything but the notes themselves. However, "@E" or "@MA" will need four operands, and therefore eight digits in hexadecimal.

Next two digits - length of the note. It will represent the length exactly as it is shown in MML - 01 is a whole note (C1 for example), 04 is a quarter note (E4), and so on. Since SmileBASIC usually runs at 60 fps, the cap will be 1/60th. I highly doubt you'd want a note that short anyways! If this value is over 60, then this will be a dotted note - 61 is 1., 6F is 15., and so on.

Each element will look somewhat like this, for a normal note: First two digits - note to be played. Octave will be found by dividing this by twelve, and if it is different from the octave of the previous note, it will adjust the octave using <, >, and the O command. If the digits represent a number over 120, this will represent an effect (modulation, etc.)

My idea was that there are sixteen 14,400 element arrays which each store information about notes and effects for each track. This would mean 230,400 elements in all, which is somewhat concerning as this may take a good chunk of memory but should manage. Each element should be a decimal number converted from a four digit hexidecimal number. Some effects will change how many digits are required.

No major updates yet, the track list is my current project, however I am getting close to the creation part. Basically, whenever in the view range, placed notes will appear as sprites with colors of the track they are in (faded if not the current track) and of appropriate length - basically what you may see in a MIDI sequencer. I'd like some input for how music data is stored.

It basically works the same way sprites in a game would - in my game, POLYGON, the player is normally controlled with the stylus, and follows where the touch screen is being touched. Then it checks for collision with your enemies throughout the main game loop.

It's much more simple to use collision once you've figured it out - without them, all you could really do is use a whole ton of IF statements that test whether the cursor is in a particular range. With sprites, you can even make the button move and it will bring the collision range with it, meaning you could have the cursor interact with a moving button.