Commander X16

I don't suppose we'll get a 2nd SD or Network connection anytime soon. But either 1 is a prime target for an expansion card.

I don't know if it will be available - I actually don't know how the SD card stuff works actually since I just use the kernel calls (e.g. MACPTR, which is glorious). But a VERA-on-a-card has been discussed as a means to get a second monitor. Probably unnecessary for a vast majority of folks playing games (but who knows, could be a Nintendo DX16 hehe) though for developing it would offer having a dev screen up with important debugging info while having the normal app screen on the main one.

Point is, if that exists it could also have an SD card on it perhaps. To make that work would require some kernel updates, though it's been toss around on Discord. One thing I'm _not_ excited about in a 2nd VERA card is 16 more PSG channels I don't plan on supporting that (certainly not for a while). Wonder if the sound stuff could be removed and repurposed for other things perhaps...

For a second SD card, get an SD2IEC, and plug it into the IEC port.

kelli217 wrote: ↑Mon Sep 25, 2023 4:01 am For a second SD card, get an SD2IEC, and plug it into the IEC port.

Yep that was discussed but I don't think MACPTR works with it since that uses fancy VERA SD card magic. So loading songs could be much slower. Loading the app from the 2nd SD card might be fast enough though, but it uses MACPTR for loading the UI assets off disk sort of "on demand". Something I'll wanna test though I don't have an SD2IEC at the moment.

Been working on _a lot_ since the last post. FM works, with some pattern effects available (including glide and legato whee!). The FM UI screen is still a bit rough around the edges but it's functionally usable. Instrument preview also works on the FM screen.

I've decided to extend the max song title and artist length to 32 and reorganized the misc bank which stores this info alongside sample data. This mostly works for old songs, though the initial speed has to be readjusted. There was already padding in place for the sample names so all that is untouched.

I'm adding some options there in anticipation of implementing them and built up a new song options screen (splitting off file load/save into its own UI):
The sync is for another day but I have ideas there. I will always support vsync since that makes it easy to use the songs in a game that's also tied to vsync. VIA will allow for BPM style timings (still with speed adjustments) which would work similar to Impulse Tracker and Furnace. MIDI would be for external MIDI clock sync which would require hardware of course. That hardware is still up in the air. Since I've been thinking about a cartridge edition of DreamTracker, I could add the hardware there. Or I could consider a user port or a separate more full-featured MIDI I/O card. All DreamTracker itself needs is MIDI Clock.

I also added some future global FM options so they can be set at a starting state without having to configure them via pattern data (which is already available).

My fav addon is description and I want to support that fairly soon. It is another nod to Impulse Tracker which had a "Message" section to add to the song. In DreamTracker it's more limited (1k). Perhaps that might change in the future but for now I'm using extra storage in the MISC bank for this (above the sample info). I think it's a reasonable amount.

DreamTracker: Now with ZSM export!

Here's a teaser of the very first (super naive, very inefficient and likely buggy and only working on PSG for now) implementation of ZSM export working! Right now it exports in "realtime" meaning you have to play the song to export it- just like you would recording your song to tape in the 80's (well and modern day too as we use reel to reel in my band for things, but I digress). That will change (at some point) but before that I need to get FM and ideally PCM working and have a means to turn export on/off (until I have a non-realtime export routine)

Another ZSM export update! I have things working rather well for PSG and "working" for FM. There are some timing issues I need to sort out where sometimes the song plays much faster in ZSM. It seems to be specific to FM so I have a feeling I know what it is (likely has to do with writing to the FM registers outside of the playback ISR, filed this bug to track that). ZSM export also now has proper delays (at least for PSG) which results in a much smaller output file. There is now a dedicated ZSM export option. Currently this enables ZSM export and starts the full song playback. All this can be seen here:



EDIT: Tested a workaround for the noted bug above as well as trying out ZSM export on the real hardware and I can produce an accurate ZSM by working around the bug (which means for a larger ZSM file). ZSM export on hardware works! But as I expected it can cause audible stutters in the realtime playback though that doesn't seem to affect the ZSM export.

Alpha ZSM export now fully working! Export hasn't been well tested on hardware yet and it's slow due slow processes for writing to disk. File load/save/ZSM export all needs to be improved (by way of more MACPRT and MCIOUT). I learned quite a lot about file I/O that I haven't had to do yet with just the tracker format, which I'm hoping to use to help flesh out the x16-docs as well.



I'm hoping this will help motivate folks to try DreamTracker out. It is still alpha (I still need to finish adding the tables feature and adding more effects to FM, even if that's just exposing out the registers to pattern effects) but it's already quite usable and it would be interesting to see what people think and what folks might want as DT matures.

For now though, whew, PCM support in particular took some effort but with MooingLemur and DesertFish's help and patience I was able to get that going! (It requires doing random I/O which was brand new for me).

I proposed this on the Discord but for those not there or that may have missed it - Now that ZSM export is working I'm switching back over to core features in DT. Among them is exposing out the FM registers as pattern effects. I'm debating on whether or not I should break up the parameters into their own effects. Leaning towards not.

For instance coarse detune and decay rate 2 are stuffed in the same byte-sized register. So I could break them into 2 effects or leave it as-is. Pros and cons to both. One pro of exposing the full byte out is you can change both values at the same time and there are fewer effects to keep track of. Con is the potential for math since the one register is broken up across 2 different effects (many of the FM registers do this). Also means you may have to know what the default values are and act accordingly since you would always be updating multiple parameters at once.

That option, however, is much simpler on the code side. It could simplify the effect evaluation (potentially by a lot if I can cleverly map the effect values in the tracker cleanly to the registers - then I can use a single routine to handle all the register effects). It would also be more performant I suspect.

This is probably what I will land on but thought I would ask other folk, musicians in particular on what they thought about this just to make sure I'm not missing anything really important there.

Quickish update! I've been working on the x16 docs and a case for Wavicle's OtterX (you can find more info about that here) and between that and the Holidays I haven't done too much with DreamTracker, though they are noticeable changes nonetheless

• Implemented much faster loading using MACPTR finally
• Implemented direct FM channel register effects
• Initial support for 512k systems

Latest version is 0.63 and is now on dreamtracker.org (if you still see 0.62, do a hard refresh as that should help purge the cache).

I know loading on real hardware was a real pain and finally got around to vastly improving it. Saving is still quite slow (I'll fix that at some point) and the load could be even faster with a bit of cleverness, but is pretty huge still and I think will make a big usability difference.

As per my previous post, FM channel affects are implemented. The work the same way as the instrument screen where I'm hiding the attenuation behavior of the FM chip so things match the PSG and modern synthesizers and things with how envelopes and things work. This is done behind the scenes with a look up table along with AND and OR'ing as appropriate. The commands do otherwise operate on the full register at the moment. I think to make that a bit more bearable I'll want to have an FM instrument debug/details screen or something. Also the location of the effects _might_ change, I'm not sure yet (if it does I'll try to write a migration tool - that's something I'll have for sure by the time I bless DreamTracker with a beta label).

Moving on, the 512k RAM I've been wanting to do for a while but ended up prioritizing that as part of my own OtterX build as I was having issues with the higher memory banks. This feature is current naive. It organizes the program and samples banks (from the top of RAM) leaving the rest for pattern data. To do this, the max number of samples was reduced down to 16 (for now). There's no real feedback or error checking preventing you from, say, opening up a save file that won't fit in RAM but that's coming. I will say DT is still best suited for 2MB but so far all the songs I've written fit into 512k. DreamTracker: Cartridge Edition would include at least some cart RAM for samples (is the plan) which would allow quite a bit more space for 512k systems as well.

Some additional quality of life features planned, as well as a "David Mode" that allows DreamTracker to work on composite using a lower resolution output. And lots of bugfixes. Lots. of. bugfixes.