Playing goes bananas mid way

[robin-raymond]

claro-de-luna (play problem).zip

FYI - I tried with and without the vol, and it doesn't matter, the track 1 repeats at a strange spot.

Each block is $780 is duration for every track, but for some reason track 1 block 00 repeats mid-playing the block causing the song to go horribly out of sync (the $BC in the track definition can be removed and the problem still exists).

[martinpiper]

Underneath the block, I can see the "Block byte size" is much larger than $100 hex (256 decimal) bytes long. it shows $21s (538) bytes.
At the moment, the play routine code only support blocks up to $100 bytes long, so you'll need to split the blocks into smaller chunks.

I could update the play routine to support longer blocks, but this will use more CPU time. It could be an automatic option to use long block code if the editor detects long blocks. :)

[robin-raymond]

Ah okay, I knew about the import limit of 1024 but I didn't realize there's a block byte limit (might be good to go red in the size cell to indicate error?). I can see why that would be very difficult to automatically fix, and yes, best not to make the CPU have to handle 16 bit block sizes for an 8 bit CPU.

[martinpiper]

I'll make the editor output a warning/error/make the size go red...

[robin-raymond]

Another idea would be to import but if the next note added would > $FF byte size then move the note to the next block so the block size becomes a maximum size not a fixed size. Although that could be a bit "dangerous" cutting so close to $FF if someone wanted to add a few settings tweaks to the block (so a max byte size during import could be solve that concern)... but this would also solve the import bug where an imported note crosses a block boundary and does not play back properly bug.

[martinpiper]

I've also been pondering the track layout. Currently the number of blocks is limited because the track byte value shares a lot of range with transpose and repeat commands. If I want to expand the ranges then track commands, for transpose and repeat, could be two bytes and allow around 250 blocks instead. The editor would have to upgrade old files using the old track format.

These are quite large changes for a future version though.

[robin-raymond]

I think the number of blocks is fairly reasonable right now given the 8 bit limits. The bigger challenge is getting the notes to fit within the max bytes/block size, and if you exceed then you can't easily "insert" a new block between two blocks and insert a few missing commands between. Although the work around is to insert a block at the end of the filled range and make the player play the block out of order sequence number wise so that too isn't such a big concern. If the import allowed specifying a max bytes per block then at least you could reserve a few bytes in your block during import for adding a few extra commands.