Should I make this so that swiping across the piano keys plays every note you swipe over, or should I leave it so the only note that plays is the first one you tap until you release it?

Whew! After like an hour or so of replacing the text in the sprite sheet, my GTXT function in BitByte MML is completely useless! Which means next to remove is the function itself :P As I expected, there aren't any graphical glitches with the text anymore because it's all drawn with GPUTCHR.

Alright, thinking about it, restarting BitByte MML will be unnecessary. I'll just fix what I don't like. Also, I joined SmileBASIC Source by the same username. This here is the first thing I'm changing - I realized I was forgetting about the command GPUTCHR, which renders my text-drawing function useless! I designed a smoothish font that will be drawn with that command instead.

On a different-ish topic from my previous post, I DID successfully make a test program that records MML from notes pressed on a keyboard, so that should be helpful when I get to the 'virtual MML controller' part of BitByte MML!

Well, it's been a while, but I'm coming back to this. I'm starting to get really dissatisfied with some of the programmin and code structure, though, so I believe that a restart on this project is in order...

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.

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!

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.

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

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

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.

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.

Mostly just techincal tweaks, such as the button function that activates when released and plays a sound, however now the interface-hiding buttons are a bit smoother - and the current tool is shown green!

(Almost) full screen mode! Yes, I will be making arrow buttons that point the other way. I have a question regarding sprite collision - what determines the priority of the collision that SPHITSP picks up? I have the white and black keys here, and the black ones are seperate sprites that sit on top of the white ones and are, of course, supposed to play their own notes.

Wow! A very minor yet critical tweak - this editor used to run very slow, and had to redraw the grid whenever you scroll. Just by pre-drawing the interface and using GCOPY instead, it runs WAY faster! To the extent at which I had to make it scroll only every 3 frames a button is held to still allow some precision and avoid graphical glitches! xD

Small update on BitByte MML - now you can scroll through the editor, both time-wise and note-wise. Note-wise will of course slightly modify the piano roll. Now you can also preview notes by tapping the piano keys, and the menu on the side gives some information.

I forgot a few sprites in the last post :) I also shrunk the view range by 1/3 of a second to make it look better. The buttons with the arrows on them will hide the attached part of the interface, giving more space. I also won't be adding a zoom tool but view range will be a setting!

After rearranging a ton of lines and sprites, the basic layout for the editor is complete! Options for special effects (pan, modulation, etc.), and note length, as well as the selected note's key, will appear in the empty space above 'TRACKS', the content depends on the selected component.