Jump to content
IGNORED

RMT2LZSS: convert RMT tunes to LZSS for fast playback!


rensoup

Recommended Posts

16 minutes ago, Stephen said:

I hate in game music. 

What you hate.... what you like....

 

 

About Pitfall, well there is the use of the "always the same"  dooo.doooo.d.doo.dooooooooooo ...

There is an other point of how POKEY could be used in games for music replay, but "as always" no fitting tracker there...to make the needed demonstrations. It's the "sound colors" that makes POKEY sounding nice, if used. 

 

It is possible to create "one melodic tune" with very low CPU usage that actually CAN sound like music and changes the style in a controlled way. 

Also, every level a new tune makes things more interesting. And, if the musician is really advanced, he could do transitions, to make the soundtrack sounding like a medley. 

Using 2 times VBI or higher replay speeds, might be interesting to listen "what is possible" . 

But there should always be a "basic" version for software development. (if there is any further) . 

 

It's a shame that someone like rensoup is converting a game to the Atari and has literally to write almost all conversion tools himself for the game ... in 2021.

Sound and Graphics simply have to fit to any aimed project, and have to be adjusted for the usable Code. 

Simple but hard truth ;)

 

Link to comment
Share on other sites

9 hours ago, VinsCool said:

i have to say most of these Amiga tunes are fantastic, and a lot of fun to transcribe on the Atari 8 bit, they let me explore experimental sounds really nicely.

Let us know if you need any suggestion on what other great Amiga tune would make for a nice A8 cover ;)

 

 

  • Like 1
Link to comment
Share on other sites

7 hours ago, emkay said:

I always have the available CPU power in mind. It's not much inside a game.  

 

There are still  ((and it gets worse) too much gaps in the development for games . 

Doing tunes that even need more advanced programming achievement , is not really helpful. 

 

How many gamy do you know that show fluent parallax scrolling, a lot moving objects on the screen, and use some real PWM in the tune during gameplay. 

My coarse answer is "none" . 

 

rensoup did help me to patch my special playable demo of Super Fly, to have the Noisy Pillars tune in. 

Actually, this time the tune is not playing correct due to some RMT player version issues....

 

But in this case, Vinscool's 100hz version of BS takes less CPU with LZSS than the Noisy Pillars tune played with RMT @ 50hz.

 

That's the whole point of LZSS: play complex tunes without taking much CPU time. The tradeoff being memory... 50hz tunes are ok but for 100hz ones it's a bit more complicated but at 9KB, I'm pretty sure that BS tune is a lot smaller than the original Amiga version.

  • Like 3
Link to comment
Share on other sites

8 hours ago, Stephen said:

I hate in game music.  It gets old no matter how nice it is.  Give me good music in a title screen, fine.  Anything else, you better let me turn it off else I won't hear the sound effects.  The first game I did not despise the music in was Tempest 2000.  there's nothing on the A8 that I would want to hear long enough to finish a game.

 

Pitfall 2, OK, good music.  Neat they used extra hardware for the 2600 to do it.  Make me listen to it for 30 minutes without a break - I'd rather be deaf.

 

7 hours ago, _The Doctor__ said:

I like in game incidental music, that is to say it only comes on for certain events, accomplishments, or even spread out randomly for small periods of time. Just not continuously!

 

I don't think there's a rule for that... the in-game tune in BS is also pretty good, so is the one in Hybris... same for those in Z-Out (to stick with the shooter category).

The ultimate example would probably be Castlevania... it achieved cult status in no small parts thanks to its ingame music.

Link to comment
Share on other sites

9 minutes ago, rensoup said:

 

But in this case, Vinscool's 100hz version of BS takes less CPU with LZSS than the Noisy Pillars tune played with RMT @ 50hz.

 

That's the whole point of LZSS: play complex tunes without taking much CPU time. The tradeoff being memory... 50hz tunes are ok but for 100hz ones it's a bit more complicated but at 9KB, I'm pretty sure that BS tune is a lot smaller than the original Amiga version.

Right. 

My point is just to push the "hardware" to the real limits, so the software developer can adjust the aimed project more relaxed ;)

Using several playback points on the screen , is a "dream" after some nifty game engine is working, allowing the use of a game maker program.... is doing the rest ... cough .... cough... ;) for colorful graphics .... cough ... cough...  

 

If the point of maximized usage is reached, why not adding faster playback and/or a 2nd Pokey ... then... 

In short: There is a real line of development missing on the Atari. 

Link to comment
Share on other sites

  • 3 weeks later...

Nice to see this thread again :D 

Worked a bit on the Battle Squadron cover again tonight, and damn I just finished transcribing another section that seriously made me curse every possible words I knew.
However, I am pretty happy of the result now! It's almost finished now, I need to transcribe a few more patterns, and thankfully it's mostly a recycle job since they will use many patterns I already have done.


The RMT2LZSS conversion was once again flawless, still runs at 100hz, and I also confirm this executable works perfectly on real hardware in its current form! :P 
So if everything goes well I should be able finish it by tomorrow, unless something else eats my free time away, hahaha

Battle Squadron 2x V49.xex

  • Like 2
Link to comment
Share on other sites

6 hours ago, VinsCool said:

Worked a bit on the Battle Squadron cover again tonight, and damn I just finished transcribing another section that seriously made me curse every possible words I knew.

Nice! Seems perhaps there are a few hiccups with the some of the new patterns but WIP I know!

 

What's not soo good is that you seem to have defeated LZSS compression ?... at 27KB, you must have done some serious manual editing! It's also twice longer of course... 

I noticed version 45 was also much bigger than your initial version even though both had the same duration... Hopefully the final iteration will still fit in 64KB!

Edited by rensoup
  • Thanks 1
Link to comment
Share on other sites

3 hours ago, rensoup said:

Nice! Seems perhaps there are a few hiccups with the some of the new patterns but WIP I know!

Thank you! I know too well ? 

It's surprisingly difficult to get working without sounding like dying cats.

 

 

3 hours ago, rensoup said:

What's not soo good is that you seem to have defeated LZSS compression ?... at 27KB, you must have done some serious manual editing! It's also twice longer of course... 

I noticed version 45 was also much bigger than your initial version even though both had the same duration... Hopefully the final iteration will still fit in 64KB!

Yeah I also noticed the massive output... I have indeed done quite a bit of manual edition, and used a pretty large amount of instruments, but many patterns were recycled, plus I have not yet cleaned it up and optimised either, so I hope there will be some space saved when it's done.

 

Relatively speaking I only have roughly 8 more pattern phrases to do, which like half of the patterns used in these will be copied from earlier parts, so I don't think it will be considerably larger at this point.

 

Having 32kb maximum would be a goal, and theoretically reducing it to 50hz should make the binary half the size of that, which would pretty much match the size of my biggest tunes.

Table Manuscrite was a 50(60)hz tune and I think the final executable after conversion was just above 19kb, and was considerably more complex than this one, so we'll see!

 

I can say for sure it's pretty amazing that everything I seem to do sort of break something due to unintended methods :D

 

 

 

Link to comment
Share on other sites

4 hours ago, VinsCool said:

Yeah I also noticed the massive output... I have indeed done quite a bit of manual edition, and used a pretty large amount of instruments, but many patterns were recycled, plus I have not yet cleaned it up and optimised either, so I hope there will be some space saved when it's done.

Not sure the number of instruments would make a difference, LZSS compresses well when the raw pokey data for each channel is identical from one frame to the next one (and for as many frames as possible)...

 

I doubt you'll see any improvement on the file size but no worries, it takes what it takes and the fact that the tune will be larger than any other one in the ASMA archive (relative to its duration) tends to demonstrate that you've pushed Pokey! (I'm curious it'll be possible to do a faithful 50hz conversion)

 

Remember from an earlier post that: 

Quote

Longest LZSS16 tune from the ASMA archive: Sloppyjones_Fuck_the_Cold 29310 bytes (RMT 4935 bytes). The tune lasts for 3mins and plays @200hz !

It may mean that LZSS could evolve and perhaps use pattern compression instead of whole tune compression but it's not that important at this point.

 

  • Thanks 1
Link to comment
Share on other sites

  • 1 month later...

By popular demand: custom note table!

 

Untested too!


From the doc

Quote


Version: 
    The RMT version the tune was created with. It is important to select the right version because there's no marker for it inside the RMT file (otherwise the tune will sound wrong).
    If 'RMT 1.28 Custom Tables' is selected, the default note tables are replaced with those contained in customNoteTables.txt.

 

 

The table file is loaded every time the version is selected so to reload for testing purposes, just switch between that version and any other.

 

There are 3 8bit note tables in the original RMT which I have extended to 8.

 

If I understand correctly they are selected with the distortion parameter of the envelope command (which supports a 8 values max).

I have also exposed the AUDC value for each of the envelope values.

16bit not table is also exposed but I couldn't have more of them because there's no parameter in RMT. If there was any editable parameter it would be a piece of cake of course.

 

Let me know if/how that works... 

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

Took me a bit to figure out, but I think I managed to find how to make use of the custom table feature... it was a lot of trial and error but now it worked.
I managed to identify what table belongs to what distortion setting, thankfully, and wrote my own comments.

It really wasn't the order I was expecting, it's a little messy but at least it works.


I only added tuning for $20 and $40, as a test, both require 1.79mhz, but other than that it behaves as expected.

Replacing the distortions in the first line also works exactly as expected, I left it unchanged for now.
 

I used the notes from synthpopalooza's tables spreadsheet to get the Distortion 2 and 4 notes for this test.
 

Distortion and Tables Test.obx CustomNoteTables Vin V1.txt Distortion and Tables Test.rmt

  • Like 2
Link to comment
Share on other sites

14 hours ago, VinsCool said:

Took me a bit to figure out, but I think I managed to find how to make use of the custom table feature... it was a lot of trial and error but now it worked.


I guess the way I ordered the tables was totally confusing ?. And to make things worse I just noticed that the Dist value is actually multiplied by 2 just so that it's more convenient to use inside the 6502 player... 


I also understand your comment in your table:

 

"//frqtabbasshi --- high byte order, uses the AUDC setting used for $60?"

 

which is actually right... when dist 6 is used, the player switches to AUDCTL_CH1_FASTCLOCK (1.79mhz) and AUDCTL_CH1CH2_LINK (16bit) for channel 1 (same with channel 3)

 

This means there aren't 8 8bit tables available but 7. 

 

So when I previously thought I could easily have a different 16bit table for 1.79mhz and 15khz, that's not actually possible unless I lose another 8 bit table

 

Hopefully I didn't miss any other sneaky code...


This is the original order (the index being the envelope distortion parameter)

            frqtabpure
            frqtabpure
            frqtabpure
            frqtabbass1 // sneaky 16bit override
            frqtabpure
            frqtabpure
            frqtabbass1
            frqtabbass2

 

but the tables are actually stored in the following order in memory:

frqtabbass1
frqtabbass2
frqtabpure


So I simply added new tables names like this 

            frqtabpureA
            frqtabpureB
            frqtabpureC
            frqtabbass1A // sneaky 16bit override
            frqtabpureD
            frqtabpureE
            frqtabbass1B
            frqtabbass2A


and added new tables data after the original ones in memory

 

frqtabbass1A
frqtabbass2A
frqtabpureA
frqtabpureB
frqtabpureC
frqtabpureD
frqtabpureE
frqtabbass1B

 

so 

envelope dist 0 is actually table 3
envelope dist 2 is actually table 4
envelope dist 4 is actually table 5
envelope dist 6 is actually table 0
...
envelope dist C is actually table 7
envelope dist E is actually table 1

 

That allowed me to remain compatible with the original RMT and made it easier for me to test that it actually worked...

I've changed it for v1.51 (grab it from the usual spot) so that the tables match the envelope dist param. and I've removed the names in the comments because they don't really make sense anymore.


envelope dist 0 is table 0
...
envelope dist E is table 7

 

I believe this should work but I don't really have a way to test it... Usually when making a change I just compare the newly output Pokey data with old known valid pokey data but in this case there's none

(Guess that happens when breaking new grounds ?)

 

  • Thanks 1
Link to comment
Share on other sites

1 hour ago, rensoup said:


I guess the way I ordered the tables was totally confusing ?. And to make things worse I just noticed that the Dist value is actually multiplied by 2 just so that it's more convenient to use inside the 6502 player... 


I also understand your comment in your table:

 

"//frqtabbasshi --- high byte order, uses the AUDC setting used for $60?"

 

which is actually right... when dist 6 is used, the player switches to AUDCTL_CH1_FASTCLOCK (1.79mhz) and AUDCTL_CH1CH2_LINK (16bit) for channel 1 (same with channel 3)

 

This means there aren't 8 8bit tables available but 7. 

 

So when I previously thought I could easily have a different 16bit table for 1.79mhz and 15khz, that's not actually possible unless I lose another 8 bit table

 

Hopefully I didn't miss any other sneaky code...


This is the original order (the index being the envelope distortion parameter)

            frqtabpure
            frqtabpure
            frqtabpure
            frqtabbass1 // sneaky 16bit override
            frqtabpure
            frqtabpure
            frqtabbass1
            frqtabbass2

 

but the tables are actually stored in the following order in memory:

frqtabbass1
frqtabbass2
frqtabpure


So I simply added new tables names like this 

            frqtabpureA
            frqtabpureB
            frqtabpureC
            frqtabbass1A // sneaky 16bit override
            frqtabpureD
            frqtabpureE
            frqtabbass1B
            frqtabbass2A


and added new tables data after the original ones in memory

 

frqtabbass1A
frqtabbass2A
frqtabpureA
frqtabpureB
frqtabpureC
frqtabpureD
frqtabpureE
frqtabbass1B

 

so 

envelope dist 0 is actually table 3
envelope dist 2 is actually table 4
envelope dist 4 is actually table 5
envelope dist 6 is actually table 0
...
envelope dist C is actually table 7
envelope dist E is actually table 1

 

That allowed me to remain compatible with the original RMT and made it easier for me to test that it actually worked...

I've changed it for v1.51 (grab it from the usual spot) so that the tables match the envelope dist param. and I've removed the names in the comments because they don't really make sense anymore.


envelope dist 0 is table 0
...
envelope dist E is table 7

 

I believe this should work but I don't really have a way to test it... Usually when making a change I just compare the newly output Pokey data with old known valid pokey data but in this case there's none

(Guess that happens when breaking new grounds ?)

 

Awesome!
So I was not mistaken, the order really was weird lol

Thanks for rearranging it, this should make it a lot easier now.
If it weren't from trying out random order to find which table belonged to which, I wouldn't have been able to at least get my test to work at all :D 
I really was confused at first lol

  • Haha 1
Link to comment
Share on other sites

Also $60 is not actually useless.
When used in channel 1 or 3, it falls back to whatever was assigned to it, and by my tests I was able to get 2 unique tables whenever C or 6 was used, 6 would simply use the 16bit tables when the supported channels are used, being 2 or 4

Edit: I can also confirm the new order now works exactly as expected :)

I only have 1 tiny nitpick, the default values used in these tables are not the correct one, but at least they can be changed :D 
I reused my test tables for $20 and $40 in this .txt file, and also wrote the real tables used by default in RMT 1.28, so at least it won't be weird when only 1 single table actually gets custom.

CustomNoteTables Vin V2.txt

Edited by VinsCool
Addendum
Link to comment
Share on other sites

44 minutes ago, VinsCool said:

Also $60 is not actually useless.

Not sure when you say $60, you mean dist $6 right ?

 

44 minutes ago, VinsCool said:

When used in channel 1 or 3, it falls back to whatever was assigned to it, and by my tests I was able to get 2 unique tables whenever C or 6 was used, 6 would simply use the 16bit tables when the supported channels are used, being 2 or 4

You're right... I think ?

 

I totally forgot about channels... 16bit table is only used when channel 1/3 have dist $6, for channel 0/2, dist 6 would use the 8bit table.

 

(I tend to number channels from 0 to 3, not 1 to 4... well not always!)

 

I don't understand what you mean with dist $C though...

 

44 minutes ago, VinsCool said:

Edit: I can also confirm the new order now works exactly as expected :)

Nice!

 

44 minutes ago, VinsCool said:

only have 1 tiny nitpick, the default values used in these tables are not the correct one, but at least they can be changed :D 
I reused my test tables for $20 and $40 in this .txt file, and also wrote the real tables used by default in RMT 1.28, so at least it won't be weird when only 1 single table actually gets custom.

yeah like I said I don't really know how to test them ? but I can use your table for the next release if you want.

Edited by rensoup
  • Thanks 1
Link to comment
Share on other sites

9 minutes ago, rensoup said:

Not sure when you say $60, you mean dist $6 right ?

Yeah. When I mention Distortions by their number, I mean the ones used in RMT, so Distortion 6 is this one, Distortion E is Bass Table 2, etc

 

11 minutes ago, rensoup said:

You're right... I think ?

 

I totally forgot about channels... 16bit table is only used when channel 1/3 have dist $6, for channel 0/2, dist 6 would use the 8bit table.

 

(I tend to number channels from 0 to 3, not 1 to 4... well not always!)

 

I don't understand what you mean with dist $C though...

Yeah that's what I mean. in RMT, Distortion 6 uses the bass table 1 when it is used in the channels that cannot output 16-bit, and switches back to the 16-bit tables on the compatible ones.

I compared 6 and C because both use the Bass Table 1, and in the .txt file, 6 and C can have their own table, that's what I was saying regarding that.

It's not useless :P 
 

14 minutes ago, rensoup said:

yeah like I said I don't really know how to test them ? but I can use your table for the next release if you want.

That's the reason I made a test .rmt module, it uses all distortions every pattern, so I can easily identify what is doing what, and was also able to get my table changes tests as well :) 

  • Like 1
Link to comment
Share on other sites

9 hours ago, VinsCool said:

did some more tests, credits to synthpopalooza for the additional tables, now I finally have a somewhat reliable method to generate sawtooth waveforms :D 

Nice!

Those sawtooth (teeth?) in the middle of the song sound much better than the squares right after them... and there's no extra cost...

Link to comment
Share on other sites

2 hours ago, rensoup said:

Nice!

Those sawtooth (teeth?) in the middle of the song sound much better than the squares right after them... and there's no extra cost...

Even better, both use my own Distortion 6 configuration, so technically I managed to turn a "useless" setting into a very useful one, depending on what channel it is being used :D

 

Sawtooth in channel 1 (and 3 with a finetune offset) and 16bit square in channel 2 and 4

  • Like 1
Link to comment
Share on other sites

1.6 is available:

 

    -attempt at fixing some VU-meters edge case bugs
    -can now launch emulator with last output obx
    -can now redo the same conversion without having to reselect the files
    -custom instrument files (.erti)

 

@VinsCool I managed to get started with the custom instrument file, it's only the dist setting for now but it means that there's no limit to the number of 8 bit tables anymore!

 

so you can add as many 8 bit tables as you want in the table file and override the envelope dist parameter in the instrument file... It's untested but your example .RMT didn't break!

 

I've also made your table file the default one.

 

Hopefully those new buttons will help with workflow...

 

@emkay it is also possible to customize the initial filterFrequencyShift value... not sure how useful that is but I did it as a test anyway.

 

 

  • Like 2
  • 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.
Note: Your post will require moderator approval before it will be visible.

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.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...