DreamTracker Dev Log

[desertfish]

Heheheh 90's eurodance. I wasn't a fan at the time, but have to admit it's kinda cool to hear it in this form

[m00dawg]

DreamTracker 0.68 is out! This is the Infinite Scroll edition! Not too much else obvious to the user, though lots under the covers with the module loading re-org and converting the UI elements to be drawn programmatically. This is most visible in the new (but not yet necessarily better) loading and help screens. Some bugs crushed too but mostly it's the kick-ass pattern scroll stuff. Download link is in the first post (dreamtracker.org).

[m00dawg]

While I had planned on having the next version of DT out soonish, I decided to go full steam ahead into the effects reorg and have been making changes within a branch just in case folks are building from source and/or I need to do any minor fixins to the current release.

The next release will have the effects reorg changes. Many of these are in the docs within the branch but you can see them here as well. Additionally I have been changing out the static screen buffer files for drawing the display more programmatically which is both faster and makes things easier for me to change things around without quite so much toil. This required updating some of my printing functions to be a bit more intelligent which took some time. I'm also trying to crush some long standing bugs, such as lack of error reporting / freeze if you try to load a file that doesn't exist. Stuff like that.

Back to the reorg, now that I have loadable modules, that means I have a lot more code space. Previously I was worried about adding non-essential or one-time use code to DT for fear of running out of RAM. That's much less of a problem now and, as such, I will now have in-app file-conversions. That means if you load an older song, DT will convert it to the current song format. It won't be the fastest operation but this both presents a decent user experience while allowing the DT file format to change and grow more organically without breaking compatibility.

All these changes I think are enough for me to perhaps consider making the next release of Dreamtracker the first Beta release which would be a huge milestone. Beta doesn't necessarily mean it's feature-complete (noting tables/macros are still planned). Just that it's solid enough that I don't expect file breaking issues between versions.

Anyways the gap to the next release given all of the above and some travel I have coming up might be a bit longer than it has been lately but I think it'll be very much worth it!

[mortarm]

...making the next release of Dreamtracker the first Beta release...

Yes! Just what I've been waiting for. Can't wait to break..er, play with it.

[m00dawg]

Oh don't worry, there will still be plenty of breaking things

[m00dawg]

Alright just a quick update for folks that wanna try it out. It's not "released" yet (as in it's not the main download link off dreamtracker.org) but here's a pre-release / work-in-progress of version 0.69, hopefully the last alpha, which contains the effects reorg and song conversion:

https://www.dreamtracker.org/downloads/ ... .69-pr.zip

[m00dawg]

Announcing Almost Beta! Maybe. Sort of.

DreamTracker 0.70 Pre Release 2 is out and you can find it over on dreamtracker.org!

I'm hoping 0.70 will be the first beta release and while 0.70 itself is getting reasonably close, there have been some huge changes underneath. Notable the effects have been reorganized to better suite future expansion and sharing effects inherent to 2 or more sound sources while also giving effect space for dedicated per-source effects. I've written a conversion routine that will remap effects in older songs so no problem there.

But I also changes how the vibrato, pulsolo and tremolo effects work. I think for the better! But I haven't yet updated the conversion routine and even when I do it won't be perfect due to how the effects now work. Part of Beta is a (hopeful) goal of not introducing big changes like that. So here's hoping it's the last one. Where I do make big changes, I will leverage the conversion routine setup. So while I can't fully guarantee full compatibility, I will commit to converting songs to the newest format as best as is reasonable.

In addition to this, note delay, finetune, and legato are now available pattern effects, some more keyboard shortcuts exist and numerous bugfixes.

To hear some of the new changes, download the newest version and load up CAVE.DTR. Or you can listen to it here:

[m00dawg]

Of Tables and Macros

I'm looking again at the macros and tables features. In part because I'm running into case where I myself could use them (macros notably). I've decided to try and tackle both, with macros happening first.

I'm trying to sort out how to organize these things noting that there's a lot of banks, even in the X16 base model, but not so many I can just go crazy. For now I'm pondering grabbing another bank for macros, even though they practically might may not end up needing one depending on how many macros some composer wants to keep track of.

Here's a brief overview of the two features:

Macros:

Macros allow for being able to have more than 1 effect per row/channel. In the current approach I'm looking at, it would be up to eight effects which seems like plenty. Effects in the macro are evaluated left to right. The evaluation would be similar to any normal pattern effect. So instant effects would be evaluated, well, instantly. Stateful effects would set the stateful channel values, etc.

One example might be a macro which would look like:

01: 06FF 0855 4A02 0501 .... .... ....

This would enable glide at the fastest glide value, enable a mid-vibrato, set the pitch speed multiplier to 2, and then set a volume sweep down.

Then in the pattern, it could be called with:

C-4 01 .. 1601

For 8 effect per macro, up to 256 could be allowed with space leftover for giving them named labels though I'm not sure if that makes sense. 64 seems like a pretty sufficient amount for most cases and that's only 1k which means they could fit inside some of the existing banks. Even more than 32 might get to be hard to track.

Tables:

Tables are a multi-row version of macros of sorts. Up to 64 will be supported with the possibility to name them as an idea I've been batting around. They only support 4 effects but allow for up to 16 rows of effect manipulation. This can be useful for things like custom arpeggios, PWM modulation, drums, etc. Tables by default run at engine speed, but there will likely be a similar speed divisor (just like with envelopes) to slow them down. They can also loop or be used one-shot (with a table-stop effect, sort of like song stop).

They would be fired in the same way:

C-4 01 .. 1301

Unlike macros, they are stateful and attached to the channel. Only 1 table can be used per channel.

TLDR, they are very similar to the tables available in LSDJ (GameBoy tracker).

---

Tables will be more complicated to implement, and since they could perhaps even use macros within them, it makes sense to look at macros first in a sort of walk-before-run approach.

As a semi-related aside, because neither Macros nor Tables are 256 byte aligned, looking up either in memory will be slightly more complicated, though not by too much. This same approach could be used for envelopes, which at present are 256 bytes long (to make the lookups fast) though I am pondering shortening them to allow for more envelopes. I'm not quite sure yet since adding mouse support (planned) will help make drawing a very long envelope much easier. But that might not be as useful as simply using a slower volume sweep (a volume sweep divisor much like the envelope speed divisor is planned).

These are mostly just rambling so I can keep track of my own feature ideas but still thought I'd share them for anyone curious.

[DragWx]

I grew up with Adlib Tracker II, and towards the end of my time with it, they had introduced a feature where each channel had two effects columns instead of just one. This might be a simple, user-friendly thing you could try out to see how well it gets around the usual effects limitations, though macros would definitely be more powerful.

That's kind of a weird thing about trackers though; the note and instrument columns tend to be the only stateful columns, and the volume and effects columns tend to be momentary per-row. I program music in byte-code where everything is stateful, and that's even more strange when trying to project it onto a tracker view.

[m00dawg]

Yep I thought about multi-effect columns, especially coupled with a more sparse storage format. I opted not to for a few reasons. The most practical one is each channel with the single effect format uses 5 bytes. So 5 * 25 * 64 is 8000 bytes, which fits into a page of HIMEM with a small bit left over for some fun things (like named patterns and/or colorizing patterns). Macros are a way to get near the features of a more modern Famitracker style tracker (e.g. Furnace notably) while only having 1 effect col. Because DreamTracker is based on ImpulseTracker, having 1 effect column (as well as a single orders list) pays homage as well.

As far as stateful vs stateless, DreamTracker does both (see: https://www.dreamtracker.org/#manual/effects/) depending on the effect. This is _not_ like ImpulseTracker, which was mostly stateless. But for a chiptune tracker it just made a ton more sense. Since you like stateful, you might like the way DreamTracker approaches that. Has the side effect of not needing to use as many macros in a typical song and also makes the single effect column not so bad even without macros.