Dream Tracker

[m00dawg]

Asking for feedback about tables

Now that FM has some effects and things, while there are still more to add, I want to look at another big feature (perhaps the last one before thinking about a 1.0), which is tables. This is a prototype preview UI screen for it:

Screenshot from 2023-10-07 11-21-42.png (40.44 KiB) Viewed 19678 times

Tables would work much like they do in LSDJ. They are a way to effectively do multiple effects at once, and have fast effect evaluation for the potential for doing fun things. They run at the engine speed so for VSYNC that would be 1/60 - same speed as envelopes, sweeps, etc.

Each table will be 256 bytes with support for 32 tables (8k total). This keeps the table lookup math easy (just like for envelopes). That 256 can be arranged any way I want and I'm currently pondering having 4 effects per row (32 rows total) vs 8 effects per row (16 rows total).

Curious for fellow tracker musicians which option seems more appealing? I can't think I've ever run into a case where I needed more than 4 effects in something like FamiTracker but likewise I also haven't needed more than 16 rows in LSDJ for doing something. One use case I was thinking is tables can be a nice way to get the SID style drum sounds. 16 rows would be plenty for that.

I forgot to say tables will be either loopable or one-shot but I haven't decided how best to do that but am leaning on using the pattern cut, loop, and stop effects to do that.

Any strong feelings from folks?

[GTR3QQ]

not a musician, and not really used a effect tables before.
Fami(0cc) Adtracker // and Furnace all got instrument(or macro tables) based marco.
But if I were to convert inst. macros to effects only, like there's a famitracker demosong in which instrument is default 2a03, and all the wave setup is done by effects.


I'd say 4 effects should cover most cases, one for volume(ADSR) one for pwm/waveselect, two more for fun.


But if count in some crazy PSG instruments and elephant in the room FM, effects could get complex very quickly.
So maybe 4 is enough.

[m00dawg]

I'm planning on having tables for both PSG and FM though the FM may prove more limiting due to the write speeds. Not entirely sure about that one yet. I'm trying to make sure shared effects are using the same effect numbers which means tables can be used on both. The tracker will happily let you mix and match even in cases where the effects don't match which could be interesting.

FM will probably have have more total effects than the PSG due to having more settings. I could expose nearly every register out to an effect value for instance. Not sure at what point the write limit starts becoming a problem but that would otherwise allow for a lot of manipulation where I could see more than 4 slots being maybe useful. Indeed for the PSG 4 is certainly more than I ever used in Famitracker as in pattern effects. Though old Fami didn't have engine speed tables as I recall - just envelopes (which I have too though I haven't implemented the pitch env yet).

I opted to do tables first as they cover the case for macros. Though if I only had 4 slots and someone wanted more, a one shot macro effect is one I had thought of as well (with or without tables). That would be another way around the per row effect limits.

Anyways 4 effects and 32 rows is what I was leaning towards but figured I would ask to see what folks thought.

[voidstar]

Quick note - DreamTracker is "VGA-only" xD

Maybe that's just the way it has to be (so many channels!), or is an acceptable restriction (track creators not using CRT?)

Just pointing it out early in case some adjustment might be possible to help make this viable to run on composite CRT
(but totally understanding functionality - and a file selection box!! haha - are higher priority)

[ahenry3068]

When do you plan ZSM file save. I'm a rank beginner at trackers, furnace is damn cool but I'm more than a little overwhelmed by all of it's features. I need something simpler.

[m00dawg]

Sorry for the delay! I don't seem to be getting email notification from the forum.

ZSM is definitely planned though I don't have a timetable yet as I want to be at least close to feature-complete before I do. I am also planning a tracker engine of some sort games can use if they prefer (there's a few pros to doing it that way, perhaps not many but a few). I'm not sure what that will look like yet as it may need to be difference depending on cartridges vs SD cards but I have some thoughts there. That also needs to wait until I'm closer to feature complete.

The biggest feature I want to get done is the tables feature (similar to LSDJs concept of tables). I've started work on it already so it won't be too much longer. After that some polish and then I think I can start looking at ZSM exporting. I roughly know how I'm going to do it in theory but not quite sure about practice.

That does mean at present there are no export options as of yet though in terms of tracker complexity, I do think DreamTracker is more approachable by being more focused and with an Impulse Tracker UI. That is by no means a dig on Furnace either - rather my tracker was meant to be a bit simpler (it only has one effect per channel per row for instance - though this why I'm adding a tables features) and I only have to solve for 3 sound sources.

Either way though I plan on doing videos for how to use DreamTracker and at least some of them will apply to Furnace. I'll be sure to share them here (as well as on dreamtracker.org as part of the documentation). How to use the FM chip for instance would apply to both (though DreamTracker handles FM's envelopes a little differently, the concepts will be the same).

[m00dawg]

Quick note - DreamTracker is "VGA-only" xD

Maybe that's just the way it has to be (so many channels!), or is an acceptable restriction (track creators not using CRT?)

Just pointing it out early in case some adjustment might be possible to help make this viable to run on composite CRT
(but totally understanding functionality - and a file selection box!! haha - are higher priority)

That's a very fair callout. Not quite sure how I may approach that since I use all the real-estate though most of the screens except the pattern data could probably fit in the smaller space. I'll log a feature request for that to see what I may be able to do there in the future.