Continued: 170: @MP // 171: @MA // 172: @ML 173-1613: Notes. Subtracts 173 and divides by 120 for pitch, subtracts pitch multiplied by 120 for duration. Actual value represents length, so 3 would be a 1/3 note. Above 60 represents a dotted note (like 68 for 8.) 1614-2125: @ // 2126-2253: V // 2254-2445: L 2446-2701: @D (Subtracts 128 from operand) 2702-3213: T (Affects all channels)

The MML commands are represented by integer values: 0-8: O // 9: & // 10: _ // 11/12: [/] (Next element after ] is loop times, 0 for infinite) 13/14: (/) (Nudge volume, used if change is under 4) 15: @ER 16-31: Call macros (up to 16 can be created with BitByte MML) 32-40: Q // 40-167: Pan // 168: @MOF 169: @E (Next element is hexadecimal string for ADSR)

For each channel: @C0_PIANO 'Channel number and name DATA "FF0000847F407F7F7F7F00" 'The first line is a hexadecimal string representing channel color and initial values for the MML commands Q, O, V, P, @E, and @. DATA 260, 3, 513, 9, 769, 770, 10, 1028, 11, 262, 12, 31 'Each element represents a command or operand for one

I think I have a better idea for how BitByte MML songs will be saved. My idea is to use PRG Slot 1 and DATA commands under labels to organize the song into each channel. The first line will look something like this: DATA 2, 120 'This is the number of channels and the tempo

Whew! Just finished implementing OPTION STRICT in BitByte MML. I've already used a ton of variables! I'm trying to look for ways to get rid of a few though, and I've gotten rid of some.

@*J.P.*[P]£ The function of the D-Pad is to scroll through the song and piano roll, and the circle pad interacts with the upper screen. I'll see what I can do though.

BitByte MML will be a piano roll based music composing program, allowing you to construct MML songs in a much more simple manner involving touch controls to both visualize and hear your project as you make it. What's more, I have a built in 'MML Controller' planned, which functions very similarly to a MIDI controller. Loops, macros - every important MML command is planned to be implemented!

Still haven't added much, mostly because my code is getting messy and I keep introducing extra unecessary variables... However, I've decided for better practice BitByte MML will use OPTION STRICT. I also wrote down all my plans for this project so it's much more organized. Updates are soon to come, I plan to finally get back to work!

Here's using two-digit beat values. Had to check the last bit twice, it was that fast!

I haven't done too much recently, but with some experimenting I've found a way to get the length in seconds out of MML! This also considers loops and will tell you if it is infinite. I proved this further by making the program stop the song after it theoretically should be done - and it doesn't stop early or late! It also factors in tempo. This should be useful for BitByte MML!

At last! Now all the color selection features are done except text input - and each part interacts with the other! Pressing the + sign for red, for example, will change the other slider gradients to include the new red value, display the numerical value, and move each slider - on top of incrementing the value by one.

What kind of error? A syntax error?

The syntax for SPHOME is usually: SPHOME control number, x offset, y offset It is ideal to use (width/2) and (height/2) as the X and y offsets respectively, as this will make the center of the sprite the center for commands like SPSCALE.

He's not asking about collision. The problem is that, since the reference point for commands like SPSCALE is by default (0,0) the top left corner is where the command works around. Therefore you need to change this point - that's what SPHOME does. Your sprite is a 16*16 pixel one, right? This means you should use 'SPHOME control number,8,8'.

Finally! Working out the bugs on this bit was ANNOYING. I didn't program it that great! I want to have the menu link to all the buttons and stuff, however linked sprites' origins throw the coordinates off. Might just have them move together instead. I probably will redo some bits because they were poorly programmed...

If that number is 0, you do not have any potions, and if it's above that, then it could appear on the item list with the number of how many (which will be stored in ITEM[3] anyways). Basically this will allow you to have an item for each element of the array (doesn't have to be 10 elements) but remember it starts with element 0, and ends with one less than the number in the DIM command.

Doing that will increase the number of total items, so unless you make a variable for each item... I would use an array for the items, to make one use DIM. DIM ITEM[10] will make a ten element array with the name ITEM, which means ten variables in the list ITEM. Then each element could represent an item, for example ITEM[3] (the third element) could represent your number of potions.

The UNTIL command requires a REPEAT command with it. Put REPEAT before the code you want repeated, and UNTIL after the code to be repeated. UNTIL requires a condition as well - this can be any normal expression you may use with IF, for example. This will tell it when the loop should stop - UNTIL A==1 for example will keep looping until A is equal to 1.

You can use the plus sign to concatenate two strings or add number values, but '+' is a binary operator. You can not use it without two values in each side of the operator.

The syntax seems to be quite off... To start off, the '+' suggests you want to add the string to something. Because you did not specify what to add the string to, you get part of your error. The 'TO' command is only used in FOR loops, and labels ('@') are only used with commands like GOTO and RESTORE. The syntax for PRINT is simply: PRINT string or number or variable[,...]