DreamTracker Dev Log

[bansai]

Some possible feature requests...maybe you have these implemented in some capacity, but I missed them in the docs on your .org site:

A second global transpose. Whittaker used this a lot of C64, probably because he was the king of transposed compositions.

One shot arp because it can be used to make plucking effects at the start of a sound.

Join two voices emitting sum and difference that updates every invocation of the register update part of the player, mostly to emulate ring modulation. I have to experiment yet to see how well this could work on PSG.

Cache the 4 bytes/PSG voice at the end of frame for allowing echo/reverb/pre-echo effects to fill out unused voices.

[m00dawg]

Some possible feature requests...maybe you have these implemented in some capacity, but I missed them in the docs on your .org site:

A second global transpose. Whittaker used this a lot of C64, probably because he was the king of transposed compositions.

One shot arp because it can be used to make plucking effects at the start of a sound.

Join two voices emitting sum and difference that updates every invocation of the register update part of the player, mostly to emulate ring modulation. I have to experiment yet to see how well this could work on PSG.

Cache the 4 bytes/PSG voice at the end of frame for allowing echo/reverb/pre-echo effects to fill out unused voices.

Some great thoughts here! Can you elaborate on a 2nd global transpose? The transpose is adjustable as a pattern effect but sounds like you might be referring to something else here?

One shot arp you should be able to do with the tables feature. I'm still working on that and will probably just make sure I have the data structures prior to moving to Beta but it's coming. It'll work like LSDJ's tables, only have at least 4 effects per row (and 16 or 32 rows) and, like envelopes will eventually have, will be either one shot or looped (forward or ping-pong).

For now, though it would be tedious you could get the plucked sound via the pitch envelope. I say tedious because you'd have to do the math on the pitch values so that's probably not very fun

Ring mod is a thought, I'll have to ponder that one. The effects I have also thought about. In true Impulse Tracker style paste doesn't wrap to the next pattern so if you're doing a delay/echo you have to do that manually right now. I don't want to hide too much behind the scenes in terms of the channel to voice hard coupling so I think echo might be a function of a better copy/paste is how I've been pondering that.

[bansai]

If you have or plan on having tables, the one shot arp is easily doable. OK, cool.

For the second transpose, I haven't given it too much thought as far as how it works in a tracker, mainly because I've had my nose way too deep in the typical music macro language (MML) bytecode interpreted music that was prevalent on the C64. Probably some generic command if encountered anywhere is sticky until the next time it's encountered. Your normal global transpose is going to be something like a CLC/ADC into the note index vs frequency table. This would be just another CLC/ADC after the first one. It might not work according to a tracker methodology though. I don't know.

BTW, I forgot to mention this earlier, but one super handy thing to have for demo programmers is being able to communicate data from the music back to outside code through a well-defined memory location in the player or specified via some supplemental init routine that sets the address. For the infamous C64 WE M.U.S.I.C. demo "The Trap", the gladiator guy's beating on the drums is perfectly synchronized with the music because the music updates a memory location ($C001) with an action command and the main program simply polls its value to determine, "OK, start to hit the drum with left arm now," or "turn head right, " or "start to hit the drum with left arm now." The same goes with various demo transitions and the like, the rockets crashing into the planet's surface, etc. It's kind of cool because the *musician* himself has direct control over choreographing/driving program code routines without him explicitly having to do JSRs or whatever in 6502 memory space. All that is needed is that he and the coder are in agreement what the actions specified in that smoke signal memory location or locations should represent. Back in the interrupt routine after the player, it reads that control byte to determine what action to take, if any. I want to say some trackers on the Amiga had this feature, but I don't remember. I sure as heck know you're not doing anything with tight synchronization like the effects for the demo Hardwired without the music directly driving the code in some capacity. Obviously, one could frame count versus an external action-to-take table, but that is extra work and if the music ever changes, the synchronization is wrecked.

709 ;------------------------------ 710 L_JSR_C3AC_C084 711 ;------------------------------ 712 L_CMD_1C 713 c3ac 8d 01 c0 STA L_SYNC 714 c3af 60 RTS 715 ;------------------------------

It's ridiculously beautiful in its simplicity and highly effective as shown here: https://www.youtube.com/watch?v=EvYtt2ptvBU

[m00dawg]

Dreamtracker 0.66 is now available!

https://www.dreamtracker.org/

This version fixes bugs (don't worry there's more ) and implements envelope forward and ping-pong looping. This was been available in the UI for the PSG for some time but went unused until now. Looping works on pitch env too but of note because the pitch env is an add/sub (rather than an absolute value), it doesn't necessarily work the way you think it might.

[m00dawg]

DreamTracker 0.67 is available!

Head over to https://www.dreamtracker.org to download!

This version is mostly a bugfix release, including:

• Exported ZSMs now loop correctly
• Reorganized the FM instrument screen
• NOTEOFFs in FM channels affecting PSG channels
• Save routine now uses MCIOUT (holy crap is it fast)
• Glide had to be enabled before the glide note (now it works immediately)
• Made background slightly blue (not a bug but still a change)
• FM instrument randomizer (ALT-R)
• Initial song parameters have usable values (PSG is a saw; FM is a ding)
• Screen is now set to 80x25 on startup

Several small fixes too not part of open bugs. I wanted to fix a bunch of these issues before tackling the two big ones before beta (pattern effects reorg and macros/tables). A few smaller features I want to get in before beta as well, such as arp speed. Some of these features are based on user feedback. Meaning if you have something you want to see in a native tracker, can be worth giving DreamTracker a try and let me know your thoughts!

[mortarm]

Since there's been some visual changes, you should include a screenshot for those not familiar with the program.

[m00dawg]

Yep agreed! I haven't been super diligent there partly because it's an alpha and things might change multiple times. So it's a time proposition. I'll be updating the docs (and that includes screenshots) likely in one big swoop when I'm about to cut the beta release. There's some tech debt in the docs right now I noticed yesterday.

One thing I didn't mention yesterday was thoughts on the effects reorg. Originally I said I'll have a python script to convert things (which is still true) but I have been pondering an X16 conversion tool as well. It wouldn't be part of the main app but would let folks convert songs without having to copy things around and deal with Python. I might have that after the beta though.

[m00dawg]

Quick update for folks switching to the new R47 ROM. The current released version of Dreamtracker does *not* work with R47 because of some changes to the PS2 handling. The source currently has a fix for R47 but that won't then work on R46. Trying to sort out the best options there in between working on features.

[m00dawg]

Lots of big changes underneath DreamTracker going on! But this is the one that's most visible and something I have been wanting since basically day one:



Infinite pattern scroll! As with many DreamTrackerisms, this implements a similar feature in Impulse Tracker of a condensed pattern view during playback. On the pro, you can see all channels. On the con, you can't see all the columns at once. The order of precedence will be note, volume, effect. So if no note is being played but the volume or effect is being used, it'll show that.

This thing is already rife with known edge cases so I'll need to iron those out before I push out a new release. Right now the look-ahead doesn't take into account pattern cuts or order jumps and the prefill routine also doesn't consider what happens when starting playback mid-song (F7). Plus I'd really like to make the thing more colorful.

The other big change is loadable modules. Not in the tracker sense but in the program one. Each main UI is now loaded on demand from the SD card. Though I wasn't running into memory limits yet, I wanted to solve for that possible cause now before it got more complicated. Similarly this change makes DreamTracker: Cartridge Edition a little bit closer. As part of this change, I will likely be moving away from loading static UI elements of the SD card too as those are done by loading the entire screen buffer (which is 9.6k) and now I have the extra RAM to just draw the UI programmatically. This helps to some degree in making at least some UI changes. 9.6k is a lot when you consider the biggest module (the pattern editor) is only 2.7k. This will also help for the cartridge version.

Not sure when I'll release an official update but in the meantime folks that really wanna try bleeding edge can build from source if ya like! Do be aware R47 is required.

[m00dawg]

Infinite Pattern Scroll is uhh scrolling!