Search the Community
Showing results for tags 'tracker'.
I thought I would start a new thread as the old one was about sparse files, which I decided not to use currently. I think it can be a goal for a nice on disk format but I'm finding using hiram is working pretty well. Yes it's pretty wasteful but saves on CPU cycles and will make editing patterns, when I do start working on the UI, perhaps bearable. Here's the latest version! With support for 6 channels, though no effects other than volume and note-off. And also no concept of instruments. Each channel is configured to play a static instrument for now: Next steps, there are many klieptasch and I have been sharing some ideas on how to integrate the Concerto synth engine with the tracker. This opens the door for some really interesting things, and means I can focus on the UI. In this way it also keeps the synth engine separate from the tracker engine so folks could more easily use the various parts of both programs if they wanted to do something else (though given both apps are open source it would also be nice for folks to contribute to either!) The UI will be a big deal and I'm not actually show how complicated it will be yet haha. I have ideas on how I might do some things but that will all be new to me. But then again so was 6502 and I'm pretty happy with the tracker thus far! I'm not sure what I will work on next - trying to interface with Concerto or start the UI. I have ideas fresh in my head for Concerto but also editing patterns by hand is quite the pain so I'll have to ponder that more. Anyways the source code is here: https://gitlab.com/m00dawg/command-tracker/-/tree/master I don't have a demo up on the forums yet because I already have some file I/O interactions (pulling in Petdraw screens but this is also the basis to handle song files). But since there is no functional UI, apart from hand coding patterns in hex, not too much to do yet
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: https://gitlab.com/m00dawg/commander-x16-programs/-/blob/master/command_tracker/index.md 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. 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 had the idea of supporting multiple effects since this is a common feature in modern trackers (even FamiTracker has this). 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. 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. But given even complicated patterns have empty space in them, by using a sparse format these requirements go down considerably. Only rows which have data are defined and, within that, only channels which have data are defined. So a row can be as few as 3 bytes if there's only one channel playing on that row with no effects. 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 I recommend looking at the link (specifically the sparse patterns link) The trade-off is a playback routine has to track a lot more things as opposed to just reading a pattern row by row. 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. When the counter equals the current row, it then can parse out the row to do the things. This ignores envelopes and some automatic commands (like how the volume slide works in Famitracker as compared to how it works in Impulse Tracker) as those could be firing while there is no row data. Figuring out how to efficiently edit pattern data is another task entirely though. If one adds data to a previously empty row, the sparse file would have to be reorganized. The best solution here is having a non-sparse pattern buffer - which would be fine for a dedicated tracker where we have room to move about. But given the space requirements, it means patterns would span multiple pages and that could get interesting when adding in things like envelope tables and things. I should say I'm not an awesome assembly programmer - just a musician who is very excited about the prospects of a tracker, but given the vast sound capabilities of the X16, it feels like it will take some thought to do well given the "limited" space (which is itself far more than the 8-bit systems of yesteryear). That's why I thought it might be good to try and start the conversation by coming up with at least something that can serve as talking points.