#GOATTRACKER ARPEGGIO CODE#

I don't think it would be too terrible since there could be a row counter and if the current row read is greater than the counter, nothing is done. The trade-off is a playback routine has to track a lot more things as opposed to just reading a pattern row by row. So I recommend looking at the link (specifically the sparse patterns link)

#GOATTRACKER ARPEGGIO CODE#

I made an attempt to show the proposal row format here but I can't find a way to insert code blocks and it was really hard to read without a monospace font. So a row can be as few as 3 bytes if there's only one channel playing on that row with no effects. Only rows which have data are defined and, within that, only channels which have data are defined. So a single row would be 126 bytes and a 64 row pattern would be 8064 bytes! The file format I came up with can support multiple effects per channel, and when you include these it balloons to a staggering 41.6k if I did my math right.īut given even complicated patterns have empty space in them, by using a sparse format these requirements go down considerably. That may go by the wayside, but even if each channel only had single volume and effect columns, I came up with 5 bytes per channel for VERASound and FM and 3 bytes for DPCM. I had the idea of supporting multiple effects since this is a common feature in modern trackers (even FamiTracker has this). The main issue is that there are 26 channels so to optimize for storage on playback, a sparse format is probably worth the extra complexity in playback routines. I've talked about this before on the FB group, but I've opted to stop using FB and thought it would be a better conversation had here anyway.

Given VERAsound will now replace the SAA1099, and given some other conversations on the forums (such as the conversation about envelopes in this post), I opted to take another look at my proposed tracker file format, which you can find here:

Goattracker arpeggio