Trying to make some PoKEY music!

[VinsCool]

A few days ago I started doing an experiment related to the tuning itself.
I have noticed RMT uses the same standard Distortion A table for both 64khz and 15khz modes.
While by itself that isn't a big deal, I eventually noticed that almost everything in 15khz mode was out of tune due to this implementation.

So I ran my own attempt at tuning notes directly using POKEY Explorer and a tuner as a reference, then wrote down my own table of notes.
Even if not perfect, it's considerably better compared to the original implementation, making octaves 1 and 2 (bass range) a lot less off I think.

It's not very easy to make use of it manually, but not impossible either, just takes a bit more time to get it to work without having to hack RMT itself.

So here's a quick test I did using one of my own tunes in progress, which was the ideal candidate for that test since it uses mode changes very heavily.
Note that I only applied the changes on the bass itself running in 15khz mode, everything else was left unchanged, so it might still sound a bit off as a result.

Just compare to the recording in the post just above, I hope this could be a useful improvement over the original out of tune bass  

(Edit after reloading the page several times: sorry for posting links to an external place, looks like the site is very slow right now and I'm unable to attach files >.<)
15khz tuning table for Distortion A, NTSC: POKEY Table 15khz (A=440hz) V1.txt -> I also learned a bit later synthpopalooza made one before me, which is also almost identical, haha
Test tune using the improved 15khz bass tuning (without actually changing the normal 64khz mode): Temple of Questions Tuning Test 6.xex
The same tune in progress that was posted in the previous post above, with the lovely 15khz bass being out of tune  Sketch 24 v36.xex

Edited February 21, 2021 by VinsCool
FINALLY was able to attach the files into the post.

[rensoup]

17 hours ago, VinsCool said:

So I ran my own attempt at tuning notes directly using POKEY Explorer and a tuner as a reference, then wrote down my own table of notes.
Even if not perfect, it's considerably better compared to the original implementation, making octaves 1 and 2 (bass range) a lot less off I think.

Although I've converted the RMT player, I'm not 100% sure how that table stuff works ?

 

So do you select a Pokey setting, then play all possible frequencies with Pokey explorer and figure out which ones correspond to a note? Then the table is just a compilation of all the valid notes ?

 

With RMT2LZSS it's pretty easy to add tables and patches and even have them all available together although obviously there's no interface (tracker) to select them so it's kind of useless.

[VinsCool]

2 hours ago, rensoup said:

Although I've converted the RMT player, I'm not 100% sure how that table stuff works ?

 

So do you select a Pokey setting, then play all possible frequencies with Pokey explorer and figure out which ones correspond to a note? Then the table is just a compilation of all the valid notes ?

More or less, yes that's exactly that!
How to use the said table of notes is an entirely different story, however  
In my case, I did all my notes by hand using several instruments to match my frequencies, so that in return remains 100% compatible with RMT 1.28.
Most people seem to prefer hacking RMT directly, which also works a lot better on the long run, but then incompatibilities between modules and RMT versions bothered me so I tried to be a little bit creative with my tunes instead. haha  

 

2 hours ago, rensoup said:

With RMT2LZSS it's pretty easy to add tables and patches and even have them all available together although obviously there's no interface (tracker) to select them so it's kind of useless.

That honestly could be really awesome, actually... To have a way to apply our own set of patches and frequency tables directly into RMT2LZSS, that would make certain experiments infinitely easier!
Something like overriding the original RMT tables with custom ones right in the conversion process ? No idea how that could even work however.
Having a new tracker would be even more for sure, but that might take a really long time, I imagine ?

[VinsCool]

Well speaking of experiments I finally gave a proper attempt at converting my Battle Squadron cover from 100hz to 50hz and got very positive results!
I'd consider this one about 90% identical to the 100hz version, which is really impressive in my opinion  

Battle Squadron Title 50hz Reduced WIP.xex

So how did I achieve it actually? I didn't even try to rearrange my module from 100hz design to 50hz, I actually let RMT2LZSS do all the work for me, and only adjusted the module itself to find out what frames were "skippable" and what shouldn't be, so I was able to make up a direct conversion with barely any losses! Pattern data remained intact, I only had to adjust the instruments themselves, and sacrifice what had to be sacrificed to fit half the amount of frames used to forge the sounds.
It's not perfect yet but I think that speaks for itself just by the sound, I think  I'll try to polish it up a bit more later, but that may be as good as I could make it I think.

[emkay]

8 hours ago, VinsCool said:

Well speaking of experiments I finally gave a proper attempt at converting my Battle Squadron cover from 100hz to 50hz and got very positive results!
I'd consider this one about 90% identical to the 100hz version, which is really impressive in my opinion  

Battle Squadron Title 50hz Reduced WIP.xex

So how did I achieve it actually? I didn't even try to rearrange my module from 100hz design to 50hz, I actually let RMT2LZSS do all the work for me, and only adjusted the module itself to find out what frames were "skippable" and what shouldn't be, so I was able to make up a direct conversion with barely any losses! Pattern data remained intact, I only had to adjust the instruments themselves, and sacrifice what had to be sacrificed to fit half the amount of frames used to forge the sounds.
It's not perfect yet but I think that speaks for itself just by the sound, I think  I'll try to polish it up a bit more later, but that may be as good as I could make it I think.

That's the way to go. Particular the Synth doesn't really benefit from higher frequency update. (But this shouldn't be mixed up with faster pitch correction. 

 

Sounds like a POKEY original . Also the "Bubbles"  sound more fitting now, as there is some fluent change from instrument to instrument. 

 

 

Edited February 22, 2021 by emkay

[rensoup]

16 hours ago, VinsCool said:

That honestly could be really awesome, actually... To have a way to apply our own set of patches and frequency tables directly into RMT2LZSS, that would make certain experiments infinitely easier!
Something like overriding the original RMT tables with custom ones right in the conversion process ? No idea how that could even work however.
Having a new tracker would be even more for sure, but that might take a really long time, I imagine ?

But that means you wouldn't be able to listen to your tunes in RMT right? you'd have to convert them to LZSS every time ?

I imagine you'd want a note table per instrument ?

It may be possible to have a file that contains all the notes (always 61 entries or something, right ? ) and just point to it at conversion time. If an instrument is skipped, it uses the default table

 

Something like this: (anything after ';' is a comment)

Quote

Instrument00

FE ; B-0  30.8
EF ; C-1  32.7

...

00 ; B-8 7849.9

Instrument01

...

 

It's so clunky... but doable.

 

17 hours ago, VinsCool said:

Well speaking of experiments I finally gave a proper attempt at converting my Battle Squadron cover from 100hz to 50hz and got very positive results!
I'd consider this one about 90% identical to the 100hz version, which is really impressive in my opinion

Impressive and disappointing at the same time ?

 

Crazy quality for 50hz, file size is about the same as .RMT (but perhap .RMT could be trimmed down ?) but then I'm a little disappointed that 100hz didn't make that much of a difference!

[VinsCool]

On 2/22/2021 at 6:50 PM, rensoup said:

But that means you wouldn't be able to listen to your tunes in RMT right? you'd have to convert them to LZSS every time ?

 

That really depends on how much changes would be done in the first place too.
If for example it's mostly a tuning improvement, that would still work but most likely sound weird in RMT itself.
If it's a listenable state that would at least give an idea of what happens before conversion.
I've gone to the point where I rely on export/conversion behaviour in Altirra (and now real hardware!) in the first place anyway, so having to convert a couple times between versions isn't truly annoying me  
I personally would totally love this instead of manually tune notes or make hacked up instruments just to get something to work, the only difference would be that it would then become RMT2LZSS exclusive features, haha

 

On 2/22/2021 at 6:50 PM, rensoup said:

I imagine you'd want a note table per instrument ?

It may be possible to have a file that contains all the notes (always 61 entries or something, right ? ) and just point to it at conversion time. If an instrument is skipped, it uses the default table

 

Something like this: (anything after ';' is a comment)

Quote

Instrument00

FE ; B-0  30.8
EF ; C-1  32.7

...

00 ; B-8 7849.9

Instrument01

...

 

It's so clunky... but doable.

Exactly this!!! Yes!
I've been doing quite a bit of tuning and combination of frequency/AUDCTL stuff and they absolutely require very specific set of stuff going, making them work manually in RMT isn't impossible but it's becoming overwhelming when you get 10 extra instruments for a handful of notes, haha
Even worse is that RMT by default does not even have the most optimal tables of notes for most distortions and modes, so a lot of the stuff, if not all of it, sounds out of tune as a result, which probably gave the chip such a reputation for the last few years --for most people, or even myself until I tried to dig a little deeper with that stuff, it starts sounding weird very quickly.
Back to a year ago when I attempted to poorly cover the Prince of Persia tunes (I'm still a bit sad about deceiving you about it...) I didn't actually understand why things just sounded bad (or good), and that was directly related to this. There was a lot of stuff that was just... coded as is and then it was up to the user to figure it out.
Clearly a more experienced person can get away with it, but for those who don't know the chip very well, it made absolutely no sense, and then stuff just sounded that way because of how the note tables were implemented, which clearly contradicts more recent, and better tunes even an idiot like myself was able to do with some (a LOT of) dedication and manual tuning being fed into the projects   
In fact now I totally understand the motivation behind patched versions of RMT, it's pretty much a necessity if you aren't patient to get certain things done manually, and it's also far from being the most user friendly kind of stuff as well.
Having a feature as such would make certain projects INFINITELY easier to manage, seriously ? 

As much as I love using RMT to make Atari chiptunes, there's so many things that could be done better, and it makes me sad to know there aren't many alternatives that don't require a musician to also learn programming or have a workflow made mostly of hacked up instrument and tracking design (the latter applies to myself currently, haha).
Its creator is also no longer with us , and all we can get for now is either a handful of hacked versions that aren't even cross compatible between each others (a module created in one will sound wrong in the other and vice versa), or a lot of patience and a very hacky workflow, which was absolutely necessary for me to achieve some better sounding tunes.

All that bit of rambling to say how much I am thankful for the dedicated people who have helped me a lot to learn new tricks and improve my own skills, and having tools like RMT2LZSS is really awesome to push the elaborate sound design further.
Who knows, maybe we'll get a new tracker someday, and maybe there is still a lot of surprise from the 8 Bit machines awaiting to be found!
 

On 2/22/2021 at 6:50 PM, rensoup said:

Impressive and disappointing at the same time ?

 

Crazy quality for 50hz, file size is about the same as .RMT (but perhap .RMT could be trimmed down ?) but then I'm a little disappointed that 100hz didn't make that much of a difference!

Thanks! I also agree for the disappointing part lol

I knew it was possible to get 50hz design to sound good, but in reality it's only just the 100hz tune with some tweaks that was played back with every other frames skipped, which is surprisingly not that bad after the tweaks!
I'm pretty sure 100hz could produce even better results, but I am not the most skilled to make use of it at its fullest yet  
I believe the .rmt could indeed be trimmed down considerably too, having a lot of instruments (and I mean, a LOT because it was absolutely necessary!), volume/speed commands and unique patterns that cannot be optimised further eat up a lot of memory very quickly.

Speaking of optimisations, how does LZSS work at its core anyway? Is it entire song compression? Or are there some special tricks involved to reduce file size?
I have noticed that just playing a couple identical patterns for a few times can drastically increase the file size, which makes me wonder if there couldn't be a way to literally remove any redundancy by making certain parts (like, patterns specifically) only compressed once, and then having them called into memory each time they are needed instead of adding them up infinitely?
A bit like how the loop point was implemented, except it would then become part of the whole data output, being made up of "subtunes" that can then be loaded each time they're actually required, which would then avoid having any duplicates in the compressed data, similar to the way trackers are made, if that makes any sense  

Speaking of loop point, I was wondering if there could be a way to actually chose how many times a tune would loop, until maybe fading out using a very crude volume change based on the volume offsets?
Actually there would be many things that would be nice to have but I don't wanna start to sound like a nagger so I'll leave that for a better time and thread  

 

[rensoup]

20 hours ago, VinsCool said:

Exactly this!!! Yes!

Alright I'll take a look... It should be simple enough. And if it enables you or anybody else to push the HW a little more, it seems worth it ?

 

20 hours ago, VinsCool said:

Its creator is also no longer with us , and all we can get for now is either a handful of hacked versions that aren't even cross compatible between each others (a module created in one will sound wrong in the other and vice versa), or a lot of patience and a very hacky workflow, which was absolutely necessary for me to achieve some better sounding tunes.

Remember though, your tunes wouldn't be compatible with -any- RMT version if you go that path ?

 

(but I agree it's still worth a shot, if anything, additional tables seem to be a very popular request)

 

20 hours ago, VinsCool said:

Speaking of optimisations, how does LZSS work at its core anyway? Is it entire song compression? Or are there some special tricks involved to reduce file size?

it's pretty simple which makes it fast to decompress. 

 

Basically there is a buffer which remembers the last 256 values (for LZSS16) sent to each Pokey channel. so there are 9 buffers * 256 bytes..

256 values = 5 sec at 50hz (4 sec at 60hz). In other words,  the decompressor remembers the last 5 sec played.

 

So compression benefits occur when the newly played sequences are still present in the 5 sec buffers. If there is, for instance, a 50 bytes sequence that is identical to one that was played less than 5 secs ago, the compressor just writes the offset in the buffer and the byte counter instead of writing the same 50 values.

 

So no, there aren't any tricks to reduce the size in its current implementation.

 

20 hours ago, VinsCool said:

I have noticed that just playing a couple identical patterns for a few times can drastically increase the file size, which makes me wonder if there couldn't be a way to literally remove any redundancy by making certain parts (like, patterns specifically) only compressed once, and then having them called into memory each time they are needed instead of adding them up infinitely?
A bit like how the loop point was implemented, except it would then become part of the whole data output, being made up of "subtunes" that can then be loaded each time they're actually required, which would then avoid having any duplicates in the compressed data, similar to the way trackers are made, if that makes any sense  

Yeah, it's one feature that NRV mentioned, pattern based compression instead of full tune compression. It's something that we all thought about and it's a big unknown. It's an obvious area to research but it isn't high on the priority list unless LZSS becomes more popular... right now it's good enough ?

 

There are 2 caveats though:

 

1. As mentioned above, the LZSS decoder remembers the last 5 secs but every time you start a new tune, the 5sec buffer is empty so the beginning of a tune will in theory not compress as nicely.

It's ok if you have 2 song parts (intro+loop) but if you have 50 patterns and as many song parts ?

 

2.My optimized player takes a few more scanlines when a new song part starts (you'll notice it if you enable raster time), which is ok if it occurs every minute or so... but again with patterns, it could occur every couple of seconds and that means you can pretty much consider you've lost that CPU time permanently).

Dmsc wrote his own version of the optimized player which is pretty much the same speed but uses a bit more of the precious zero page memory. But on the other it may be faster to start a new song.

 

 

A new tracker would be a better investment ?

 

20 hours ago, VinsCool said:

Speaking of loop point, I was wondering if there could be a way to actually chose how many times a tune would loop, until maybe fading out using a very crude volume change based on the volume offsets?
Actually there would be many things that would be nice to have but I don't wanna start to sound like a nagger so I'll leave that for a better time and thread  

Well I guess it's possible to modify the player to override the volume commands but that would bloat it and then it would just remain silent ?

It's also possible to to create a 3rd song part which would only last as long as the fade out time and play it at the right time, but it just seems useless ?

 

[VinsCool]

Doing some custom tuning is slowly paying off, but there's still a lot of things I need to figure out.
Maybe I'm crazy or maybe I'm onto something but I hope I can fully get most notes to sound better between each others.

For now I only changed the Distortion A in 64khz mode tuning table, where the actual pattern of notes being "in-tune" appears to be around 444hz in NTSC, running the same frequencies in PAL is a near 440hz pattern ?
For the moment I had to make my own patched RMT version to actually be able to test what I have figured out without having to make an instrument for literally each note, but that did work well I believe.

A few notes may still sound a bit wrong but otherwise most do sound pretty good together, there is a nice resonance going with the distortion bass now :3c 

 

To make that RMT2LZSS conversion I had to be a little creative but thankfully that did work well, haha

In short I exported a .xex from the patched RMT version I made currently, recorded as SAPR in Altirra and then threw it into RMT2LZSS.
The song looping twice then fading out was actually done manually, couldn't be bothered to manually make the "loop" out of a SAP dump  

The RMT version itself is actually nothing too special, it's just the Distortion A table changed to my own table, which is still not perfect so I wouldn't recommend using this one seriously, in fact I do not like having to rely on a hacked version at all, but it made my tests a lot easier to do  

The .txt file is mostly a dump of ramble, ideas, and guesswork, so again I do not recommend taking anything from it too seriously, but maybe it could be useful, it's definitely something I want to improve later.
 

Corridors of Time Alternate Tuning.xex Rmt Vin Tuning Patch V1.exe POKEY Table 64khz (A=443hz) WIP14.txt

Edited February 26, 2021 by VinsCool
typo

[+MrFish]

Sounds amazing.

 

[_The Doctor__]

Like any fine instrument, tuning is always needed before it can join with the orchestra and commence playing... Nice job getting all the sections in order!

You are indeed a conductor!

Thank you for reminding and showing folks the way again.

[emkay]

The funny part here is that some accidental find in LZSS that RMT has a playback bug. 

Then there finally VinsCool understood my intentions very well. 

What a big progress in the last months.

[ivop]

1 hour ago, emkay said:

The funny part here is that some accidental find in LZSS that RMT has a playback bug. 

Yeah, it's not just the sub-par emulation of pokey.dll. Could also be the 6502 emulation it uses. It emulates the true 6502 rmt player routine. Perhaps it's the glue code around both DLLs, and that's where the timing is off. Or it's the downsampling from 1.79MHz to 44.1kHz.

Quote

Then there finally VinsCool understood my intentions very well. 

What a big progress in the last months.

?

Edited February 26, 2021 by ivop

[+Philsan]

Awesome! PAL version please! ?

[VinsCool]

1 hour ago, Philsan said:

Awesome! PAL version please! ?

There you go  
Corridors of Time Alternate Tuning 50hz.xex
It sounds a bit different since I only really adjusted the tempo, nothing else was changed.
Tuning may be a bit off as well, but I plan to look into PAL later as well  

Oh yeah might as well post the modules. They rely on the tuning of my custom notes table in the RMT version I posted earlier in the thread, but otherwise they might still work fine in Vanilla RMT 1.28 (1.30)
Corridors of Time Alternate Tuning Final Loop Adjusted.rmt Corridors of Time Alternate Tuning Final Loop Adjusted 50hz.rmt

Edited February 26, 2021 by VinsCool
Addendum, typo

[ivop]

11 hours ago, VinsCool said:

444hz in NTSC,

Here's something I'd wanted to do for some time after I did pokey-explorer. This is a spreadsheat with all 16-bit and 8-bit tunings for distortion 10, both PAL and NTSC. You can fiddle with the clocks (these are 800XL clocks), but you can also change the frequence of A4. If you change it to something else, all values automagically change. Everything from Handel's tuning fork at 422.5Hz, Beethoven's fork at 455.4Hz, and everything in between should work

 

All tables are tunes towards 12-TET (12 Tone Equal Temperament). It could be nice to replace the 12-TET column with a different tuning. For example, if you know your song is in D Major, you could put a D Major just intonated table in place, and let the spreadsheet do its magic, and return to pre-Bach just intonation. Like a breath of fresh air. On a G string

Atari Tuned Notes A4=x.ods

Edited February 26, 2021 by ivop
forgot to attach the ods file :)

[VinsCool]

8 minutes ago, ivop said:

Here's something I'd want to do for a time after pokey-explorer. This is a spreadsheat with all 16-bit and 8-bit tunings for distortion 10, both PAL and NTSC. You can fiddle with the clocks (these are 800XL clocks), but you can also change the frequence of A4. If you change it to something else, all values automagically change. Everything from Handel's tuning fork at 422.5Hz, Beethoven's fork at 455.4Hz, and everything in between should word

 

All tables are tunes towards 12-TET (12 Tone Equal Temperament). It could be nice to replace the 12-TET column with a different tuning. For example, if you know your song is in D Major, you could put a D Major just intonated table in place, and let the spreadsheet do its magic, and return to pre-Bach just intonation. Like a breath of fresh air. On a G string

That would be pretty damn cool! especially considering how the POKEY tuning is limited, it would help a lot on some tunes to achieve the best possible harmonisation  
The values I theorised here were based on as many notes as possible I could get in-tune to each others, and I believe the same principle also applies to distortions since I got my Distortion C bass to suddenly sound "in-tune" as well, as a side effect, which was unexpected but really welcome.

There's still a lot of improvements and most likely more alternative tables that could come into living from this concept, and I do plan to experiment with these for sure, hahah.
hopefully I can get a finalised table for $A in both 64khz and 15khz modes that are compatible, so far I was at least able to get a preliminary 15khz table that has the 2 first octaves in-tune to A-4=440, but it will be complicated to use since (at least, RMT) can only use the same table regardless of the mode used.
And doing the fine tuning manually in the tracker itself is technically possible, but it's painfully slow and very easy to mess up lol

Edit: by the way, I am so thankful for POKEY Explorer, it has helped me so much figuring out tuning and combinations of sounds as well as many more tricks I am starting to use more and more  

Edited February 26, 2021 by VinsCool

[emkay]

That the PAL notation is somehow wrong, one might hear it the 1st time when played. 

The whole thing sounds better on PAL, if the pitch plays the next higher frequency. 

 

For some timespan I did some Generator 2 examples. 

Generator 2 is really useful to add a channel to the 4 voices. But it needs a separated frequency table. 

 

You know this? It's using gen 2 as build in RMT. But the main voice is "lifted"

 

 

[+Pat Brady]

1 hour ago, VinsCool said:

There's still a lot of improvements and most likely more alternative tables that could come into living from this concept, and I do plan to experiment with these for sure, hahah.
hopefully I can get a finalised table for $A in both 64khz and 15khz modes that are compatible, so far I was at least able to get a preliminary 15khz table that has the 2 first octaves in-tune to A-4=440, but it will be complicated to use since (at least, RMT) can only use the same table regardless of the mode used.

 

I have a bunch of key-specific tables you are welcome to use:

 

https://docs.google.com/spreadsheets/d/148aza1TfSvlUZeSx6haHcU4IKwpYF8N7BxPbGRDA_f8/edit?usp=sharing

 

Each table is based on either 15 kHz or 64 kHz but also provides the closest values using the other clock.

 

If you need a key that's not there, let me know and I'll see what I can do.

 

[VinsCool]

1 hour ago, Pat Brady said:

 

I have a bunch of key-specific tables you are welcome to use:

 

https://docs.google.com/spreadsheets/d/148aza1TfSvlUZeSx6haHcU4IKwpYF8N7BxPbGRDA_f8/edit?usp=sharing

 

Each table is based on either 15 kHz or 64 kHz but also provides the closest values using the other clock.

 

If you need a key that's not there, let me know and I'll see what I can do.

 

Thanks a lot! That could be really helpful for what I'm trying to achieve.

[rensoup]

14 hours ago, VinsCool said:

Doing some custom tuning is slowly paying off, but there's still a lot of things I need to figure out.
Maybe I'm crazy or maybe I'm onto something but I hope I can fully get most notes to sound better between each others.

nice! Level up again ?

[rensoup]

14 hours ago, VinsCool said:

In short I exported a .xex from the patched RMT version I made currently, recorded as SAPR in Altirra and then threw it into RMT2LZSS.

I could make another selectable patch in RMT2LZSS once you have a final version, then you wouldn't need to go through the SAPR malarkey!

[VinsCool]

@Pat Brady wow I just took a look at your tables in the google docs... holy fuck this is awesome stuff, it's all exactly what I was looking for and what I was attempting to do with my own set of frequencies as well!
 Thank you so much, this will totally save me a lot of time trying to calculate everything by hand and by ear  

In fact, from what I could tell, I got really darn close to a mix of your Major 64khz tables, which looks like I had kind of "combined" based on the notes I was able to find resonating nicely together, so I really was on the right track!
Seriously, thank you so much!

[+Pat Brady]

9 minutes ago, VinsCool said:

@Pat Brady wow I just took a look at your tables in the google docs... holy fuck this is awesome stuff, it's all exactly what I was looking for and what I was attempting to do with my own set of frequencies as well!
 Thank you so much, this will totally save me a lot of time trying to calculate everything by hand and by ear  

In fact, from what I could tell, I got really darn close to a mix of your Major 64khz tables, which looks like I had kind of "combined" based on the notes I was able to find resonating nicely together, so I really was on the right track!
Seriously, thank you so much!

 

I am glad you find it useful.

 

It's all based on formulas. There are formulas to figure out what frequency each note should be, and formulas to calculate the AUDF value closest to each frequency. Now that all of that stuff is established, adding tables is much much faster than doing it by hand.

 

For now it is just distortion A (16-bit and both 8-bit clocks) and distortion C (3 different pattern lengths). I think my formula for distortion 2 is incorrect, so I need to sort that out. Then I hope to eventually add some of the more esoteric settings.

[tane]

Regarding patching RMT, are these files the best version available?:

 

rmtplayr.a65

rmtinclude.asm

rmt_feat.a65

 

 

Raster Music Tracker.7z