Jump to content

Command Tracker Dev Log


Recommended Posts

52 minutes ago, kliepatsch said:

CPU, wise it depends really on what you are doing. If you are using the tracker with the UI, playback will use significantly more CPU power than if you are "just" playing back without any visual feedback. And how much CPU is taken up by playback itself also depends on how much of the sound engine's capabilities you are using. That includes, how many voices are playing and especially if the sounds are using a lot of modulation and effects.

Yep this is correct. Actually the UI update on playback is very lightweight - it just scrolls the lower layer and does some small character updates (like the row #). The stalls come from updating the pattern layer in VERA all at once. I know how I'm going to fix that, but for now I'll likely make a simpler UI when playing the full song until I implement a better solution there. Otherwise the main lift on the tracker side is stepping through a pattern via a timed interrupt (currently a multiple of vsync - that's the song speed) and evaluating the row. I haven't measured it but I think that part is pretty lightweight.

55 minutes ago, kliepatsch said:

Edit: I should mention that at the moment, as far as I know, the tracker exists only in conjunction with the UI. But maybe later a player-only version could be made that could be used inside other applications.

This is also correct, however I *do* plan on a decoupled "tracker engine" that can playback songs, ideally in a sparse/streaming format. Currently the songs are comparatively HUGE in RAM because all uncompressed patterns are being read to high RAM and with 25 channels, it's a lot! But in reality the amount of data for most songs will be much much smaller. I have a sparse file format idea in the docs in the project. It's based on a combination of Ron Hubbard's solution and GoatTracker. It's probably not the most compact though - a VGM file might be even better, though the sparse format would be convenient as it would be compatible with both the tracker itself and an embedded playback engine (for games and such). I won't be tackling this for a while though. It will be after the tracker itself is mature enough to make some sensible music with it 🙂

Link to comment
Share on other sites

31 minutes ago, Yazwho said:

Wow, that's very impressive! I've only been able to get basic sounds from the PSG.

That's how I started doing it (the videos from previous posts use my own sound implementation before I started work to integrate Concerto). Concerto is a wonderful sound engine though so yep I recommend taking a look! I'm using it for the tracker, but it could be used for lots of things or at least serves as one good example of how you might want to handle modulation of various things using a more musical (ADSR envelopes) approach. It sounds really nice too and likely the next thing I'll be doing in the tracker is setting up some static instruments so I can start testing out pattern effects and things (and bring back the Bad Apple demo song).

Link to comment
Share on other sites

2 hours ago, Yazwho said:

Looks awesome!

It's all PCM right? Do you have a feel for how much CPU the playback takes? I'm going to guess quite a lot?

Kliepatsch answered this on the contact of Command Tracker and Concerto but to elaborate on this, yes DPCM takes a ton of CPU power. Though it is "stereo" as far as I'm aware it doesn't approach it as independent channels - the data buffer either is a stereo or mono sample. Concerto uses the DPCM to do some really clever timing tricks but otherwise there's no DPCM used.

Though it's out of scope today, I've been passing thoughts about a GUS style soundcard for the X16 to enable "hardware accelerated" sample playback. I'd bet someone is going to come up with this and while it won't be part of the core X16 that could enable some really interesting things. I think something like this would be required in order to create something akin to MODs and sample based PC trackers (like FastTracker, ImpulseTracker, etc.). It might be possible to use some low resolution samples with the tracker for NES like sounds - maybe. At this point I'm thinking we won't have the CPU headroom to do it but it's a bit too soon to say I think. It'd be nice to have some NES drums for sure!

Link to comment
Share on other sites

48 minutes ago, m00dawg said:

Concerto uses the DPCM to do some really clever timing tricks but otherwise there's no DPCM used.

Ah ok, that would make sense, so you can make changes to the wave for periods lower than the vsync provides?

 

Link to comment
Share on other sites

Posted (edited)
22 minutes ago, Yazwho said:

Ah ok, that would make sense, so you can make changes to the wave for periods lower than the vsync provides?

 

Yep! Concerto's ISR sort of outlines how this works:

https://github.com/biermanncarl/cx16-concerto/blob/master/concerto_synth/my_isr.asm

The take-away is that, currently, Concerto runs at about 7ms if I'm reading and remembering this right. Whereas vsync would be 16ms. Concerto's timing is tunable by adjusting how the audio buffer is filled. It's a very neat approach! I think once the emulator has timers there may be other options as well.

Edited by m00dawg
Link to comment
Share on other sites

Nice trick!

I don't know much about audio and the composition of it, but how bad would it sound by using the vsync? The reason I ask is that having an interrupt fire at 'random' time during the could break code that highly relies on line based interrupts.

 

Link to comment
Share on other sites

10 minutes ago, Yazwho said:

Nice trick!

I don't know much about audio and the composition of it, but how bad would it sound by using the vsync? The reason I ask is that having an interrupt fire at 'random' time during the could break code that highly relies on line based interrupts.

Currently CommandTracker is using vsync with Concerto handling it's own timing. It's not bad, but yes that is something to worthy of note and something I was thinking of trying to see how much coarser it makes the envelope evaluation (since it will be about 50% slower). In the "final form" version of the tracker, I'd like to have this be controllable wherein you can select sync sources for both Concerto and CommandTracker and have these settings embedded in with the song file. So if you want very rich smooth envelopes, you can use tight timings with Concerto or using vsync; and/or if you want the tracker to run at, say, a MIDI clock pulse, you could.

MIDI clock or some sort of sync pulse (e.g. by way of the user or controller port) is a big desire of mine so I can sync Command Tracker to external MIDI and have proper timings. But I think due to the CPU issues, having these knobs to turn would be valuable in general.

For instance, right now the tracker is set to a fixed 25 channels, but Concerto has a concept of voices as well where an instrument could use more than 1 PSG voice. That means the number of channels in the tracker could, maybe eventually, be flexible and should reflect the needs. If you're using very rich instruments in Concerto, you might only want/need 4 tracker channels as an example. Or if you're game uses a lot of CPU, you might want to use coarse envelope timings in Concerto and may also want to limit channels in the tracker due to both song size and CPU consumed.

Those are all features that are pretty far down the list from where things are today but are definitely things I've thought about.

Link to comment
Share on other sites

  • 4 weeks later...

Small update, relative to progress anyway, but Command Tracker has now been updated to work with the latest emulator/rom (r39) which includes the changes to how banks are handled and such. There were two bugs where I was doing an unsafe lda ("lda 0") which worked previously since the value at $00 happened to be 0 but could now have data in it (namely the current page of himem).

I'm still having some visual artifacts I didn't see before, specifically with the active pattern scrolling stuff. But since that may get removed (perhaps only temporarily) I wasn't going to worry about that too much.

  • Like 1
Link to comment
Share on other sites

Shortish update:

  • Disabled pattern scrolling when playing entire song (no more stalls) and added ugly placeholder for better graphics (like channel trigger indicators)
  • Added play pattern which DOES scroll since we don't have to reload the pattern (key F6 in edit pattern module)
  • Added start song playing at row (key F6 in edit pattern module)
    • This is buggy because doing things like pulling up the order list while playing crashes everything.

Very rough around the edges. Took a while to sort of slide back into the codebase since it's been a bit of a hiatus. The above is good enough to be able to start working on better integration with Concerto so that's what I will start working on next.

  • Like 2
Link to comment
Share on other sites

Another quick update showing off the PHAT sound that one can make with the Concerto engine! Also showing off the play-pattern feature:

 

I didn't update the whole song because I really need to add in a few additional GUI elements. Namely tracking the current instrument so that I can add notes without having to constantly change the instrument number. And there's still some UI bugs where it sometimes doesn't update the instrument number and I have to end up doing that multiple times (that's a weird bug). But geeeeez that phat sound!

  • Like 3
Link to comment
Share on other sites

On 3/12/2021 at 1:42 AM, m00dawg said:

For instance, right now the tracker is set to a fixed 25 channels, but Concerto has a concept of voices as well where an instrument could use more than 1 PSG voice.

This can be interesting for the FM channels as well. One reason the DX21 was preferred over the DX27 for bass ... despite both being based on the YM2151 and both sharing the well reputed #01 analog bass patch ... is that it is bi-timbral, so you can have two related but distinct bass patches tuned a couple of cents from each other played as a single instrument and get a bass with a lot of complex harmonics to fill up the bottom of the soundscape. Four FM channels organized as two pairs of instruments for a bi-phonic, bi-timbrel bass patch could be really interesting.

Edited by BruceMcF
Link to comment
Share on other sites

Oh wow I hadn't thought of that, but yes that would be really neat! It's not a competition but it would be cool to do something that isn't as easily done in Deflemask 😉

Eventually having some sort of flexible solution would be nice. Actually Concerto largely "just works" when multi-voice instruments in my brief testing meaning one can mix and match today and it'll work. But there's no clues into if you're out of voices right now and for songs that would be using multi-voice instruments, it would be nice to hide unused channels or something.

One hidden change I didn't mention was I am now using a single ISR. Previously I was using mine plus Concerto's and I think I may have been doing something funky there. This means Concerto lost some precision (10ms vs 16.67ms) but it really cleaned up some timing issues I was running into and hasn't affected the sound quality much that I could tell. When I played my test tune my jaw dropped at that crazy bass haha it's great!

That said though, I really need to sort out some UI issues before I move on to editing instruments and things. That will take some thinking I think as I want named instruments and Concerto doesn't have that concept, and uses multiple indexed arrays (I forget the proper term there). Nothing wrong with that, it's quite efficient, but I'll have to figure out how that will work. Then there's the FM instruments (I'm ignoring those for now but the expectation is, of course, to use both the PSG and FM at the same time).

Before that, I need to track current instrument (should be easy enough) and to figure out cut-paste (not quite as easy). Plus those dern input bugs.

Link to comment
Share on other sites

Posted (edited)

Another quick update. I really wanted to get the demotune working so spent some time working on that after I sorted out keeping track of the last instrument used and squishing a few bugs. It now uses 5 channels! (albeit only for a short bit). The first part is just showing the pattern changes, since you can no longer see those while the song is playing.

 

Edited by m00dawg
  • Like 6
Link to comment
Share on other sites

  • 3 weeks later...

It's been a BUSY few weeks to find time to write code as of late, but hope to start working CT again soon. I was having trouble sleeping last night and was trying to work out the next big push I'd like to do - copy/paste. Having that, plus maybe some channel shift options (delete and shift up, shift entire channel up/down rows, etc.) would REALLY help the usability of the tracker. I was trying to figure out a decent approach for copy/paste and here what I've come up with. Could perhaps use some feedback from folks if there might be a better way:

  • I will use similar keyboard shortcuts as with Impulse Tracker
    • CTRL-A once, selects entire channel, CTRL-A twice selects entire pattern
    • CTRL-B marks start of copy
    • CTRL-E marks end of copy
    • When we press CTRL-E, we evaluate the start/end points, redraw pattern view to show the highlight of what we selected
    • I'm going to assume, for now, the start point will be the top-left point and the end the bottom right (Impulse Tracker lets you do this backwards but for now I was going to avoid worrying about that).
  • Use 2 pages in memory (yes that means the max song length decreases by 2)
    • Use a page of memory to store copied pattern. When user presses CTRL-C, copy entire current pattern to copy buffer
    • Use another page to store the current pattern buffer, such that on a CTRL-V, we copy the entire current pattern to that buffer (this is so we can CTRL-Z if we pasted the wrong thing)
  • The copy block will be stored as ranges in main memory, something like
    • Start Channel #
    • Start Row #
    • End Channel #
    • End Row #
  • So, on a paste, we have to start at the current cursor of the pattern being pasted into (channel/row) and then roll through the copy buffer for the block desired.
    • So if I originally copied say channels 2-3 from row x10 to x20, and I'm on channels 4 at row x00, the result will be channels 4-5 from rows x00 to x10 ends up with what we copied.
    • This happens on the actual pattern so once we've done this, we redraw the pattern into VRAM
  • If we don't like what we pasted, we undo it by pressing CTRL-Z, which simply copies the backup pattern into our current pattern, then we redraw the pattern

These operations would be computationally more expensive than they could be, but the idea is to try and make the code simpler and more flexible. It's not a speed critical part of the tracker so trading speed for simplicity might be worth it here.

Curious if anyone has ideas on how to make this simpler/better? I think once this exists, the tracker will become a ton more useful and I can start then thinking about things like the pattern effects and such.

 

Link to comment
Share on other sites

On 5/1/2021 at 12:08 PM, m00dawg said:

Impulse Tracker lets you do this backwards but for now I was going to avoid worrying about that)

All you should have to do is a quick check when the user hits Ctrl+E is compare the 2 points and if they're backwards, swap them and continue as if they were specified forwards.

  • Like 1
Link to comment
Share on other sites

  • 2 months later...

Quick update, though nothing to show - sorry! It's summer so there's been plenty of other things to do but I also opted to slow down a bit and wait for the next update to the project. I'm not quite sure why the team hasn't posted the update here since it's a big deal I think, but apparently on the FB discussion group, prototype #3 has been shown off whee! I found out about it via the X16 unofficial Discord. That's good news and has me more excited about the project again and so I expect I'll start spending time on CT again in the coming weeks. Next feature is still copy/paste as that's just too big of a necessity before I work on the other stuff (like an instruments UI to configure the Concerto patches and provide a connection to/from it and the tracker).

Link to comment
Share on other sites

  • 2 weeks later...

I don't have much to show for it yet but I did start work on the copy/paste - or more specifically the block selection routines. CMD-B and CMD-E now mark the start/end of the block and I have started work on highlighting the blocks in the pattern view itself. I plan on getting all that working before I tackle operations on the block.

Marking the start/end of the block is easy enough - but drawing the highlighted area is much less trivial. This is partly because a single pattern doesn't fit in VRAM so when moving around channels, the blocked area has to get redrawn depending on what part of the pattern is in VRAM (specifically VRAM can hold all the rows, but not all the channels). To solve this I'll probably have a function that evaluates the start/end areas and highlights any part of that currently in the view which I can call whenever I need to.

This is all to mark a block. Once a block is marked, I'd like to have multiple commands to operate on the block. This will include copy/paste but also can include other things like changing the octave of all the notes in the block, or inc/dec'ing the notes, etc. The copy/paste itself is still a bit of a mind exercise but I'll worry about that once I have block selection actually working.

Another change is I broke the edit_pattern module out into sub-modules of its own, as it was getting pretty hairy having everything in one big file. I like this approach and will be breaking out the other routines into separate files to break up edit_pattern more into bite sized chunks.

  • Like 2
Link to comment
Share on other sites

  • 1 month later...

@The 8-Bit Guy Heya David! I thought I'd point you to here. I saw you were working on a tracker and, while I'm sure you are a far _FAR_ superior programmer than I, you might be able to get some useful tidbits from this one. Notably @kliepatsch's Concerto engine, which I use extensively, may help get you further along on richer synthesis so you only have to concentrate on the UI, file-format, etc. Just a thought! Both are currently open source and you can find them:

https://gitlab.com/m00dawg/command-tracker

https://github.com/biermanncarl/cx16-concerto

Klieptsch is working on merge PSG and FM so you can create patches that use one or the other (or both). I'm still stuck in copy/paste fun since that's a feature I used a ton with older trackers (and still use them on newer ones). My UI will be based around Impulse Tracker largely as I've been fond of that system. Even though the Fast Tracker style kinda won out (it's what Famitracker, Deflemask, and Renoise all seem to be based around), I was never nearly as fast at writing as I was with Scream and Impulse.

I'll continue to work on mine. I took a bit of a hiatus since the X8 kinda made me think the X16 might be delayed longer than I hoped and have had other things going on. But my grand plan is to use the X16 as a tracker solution, optionally with some method of clock sync (even if just pulses on the controller port if not a full MIDI expansion card). Having expansion cards is one of the things I like most about the X16 since it enables these sorts of ideas which is great!

My file format, you will notice, is horrendous. 1 pattern = 1 page in himem. I did it by design so I can focus on the most important parts of the tracker (I think) - the UI. I plan on moving to a sparse format once the tracker functionally works. And I expect those to be much smaller so a simple playback library could be included with games.

CT is currently still using separate FM (not implemented) and PSG voices. Given what Concerto is doing I will flatten this out, I just haven't decided in what way yet. Probably 16 channels. I'd like to make that configurable (at least at song creation) but that's a future feature for now. Since Concerto manages the voices, the tracker just needs to support a reasonable number but doesn't have to support all 24 (ignoring DPCM for the moment). I don't expect composers to commonly use all 16 PSG voices and 8 FM separately given some of the rich features of Concerto. There could be some extreme cases for when wanting to do that (like tons of echo or something) but I think some of what had to be done manually via patterns can be done in Concerto. And what can't I was pondering having a macro solution for (so the Mxx affect might be calling macros - a bit like tables in LSDJ was my idea there).

Link to comment
Share on other sites

  • 2 weeks later...

Integrated the newest Conerto into the tracker! Copy/paste still doesn't work 😜 But I did consolidate down to 16 synth channels (and 1 DPCM) for now. This makes each 64 row pattern a bit over 5k and allows for either perhaps adding more effects/channel down the road or allowing for up to 96 row patterns (for 6/8 timed songs as I tend to prefer using rows of 96 vs 48 for those). This means old songs won't load right. Given the fairly alpha state of CT I'm opting not to worry about that all that much at present.

Of course I still want to get copy-pasta working but it's honestly not my favorite thing to do 🙂 This, plus the timing of the X16 being a bit uncertain has me not in a crazy hurry. On that note though, since @The 8-Bit Guy is working on his tracker, I will be renaming mine since his definitely deserves the CommandTracker title assuming he wants it. To fit with Concerto and the starting-things-with-C idea, I'm thinking of alternatives such as Crescendo Tracker (which I think might already be taken?) or Contra Tracker. But I might do something entirely difference. Maybe Xtreme Tracker (to keep with the 'X" theme) - I dunno. The name is a minor thing.

Anyways huge props to @kliepatsch's work on Concerto there. Well worth checking out as it does basically all the heavy lifting and really shows what you can do with the hybrid PSG + FM sound. Fantastic work!

  • Like 4
  • Thanks 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use