[RELEASE] RASTER Music Tracker, v1.34.00

[Steril707]

Had a go at this..

Feels very nice and capable and I had a lot of fun already..

 

So, anybody and idea what I need to export to get this to play in my own game? Guess .rmt does the trick, no? 

Also, how do I start and run the song once I imported the binary?

 

Thanks!

[VinsCool]

10 hours ago, Steril707 said:

Not that easy, unfortunately.

Seems that this is a huge problem since Mac OS is not capable anymore of running 32 bit code since Mac OS Catalina.

Dumb but true.

 

Guess I will try this on my Windows work laptop then.

Ahh well I see... Didn't really think about this would be a problem.
I'll see if I or someone more comfortable with this kind of setup could make the program build for 64bit sometime later.

 

7 hours ago, Steril707 said:

Had a go at this..

Feels very nice and capable and I had a lot of fun already..

Very nice!

 

7 hours ago, Steril707 said:

So, anybody and idea what I need to export to get this to play in my own game? Guess .rmt does the trick, no? 

Also, how do I start and run the song once I imported the binary?

 

Thanks!

Well, I'm not the best for this kind of explanation, and also a bit of incompatibility currently exists with the exported songs data, but there's at least 2 ways to get things going:

 

The original method is to use stripped .rmt modules exported from RMT, then assembled into source code with the music driver, with the features enabled and disabled for the optimal results.

Unfortunately, as things are going right now, modules that would make use of the features specifically hacked together to work with my patched music driver code won't play correctly with the original RMT 1.28 ASM sources.

Using my own driver version (Patch 16) sources will work however, but it is both going to eat up a lot more memory and CPU, mainly due the fact that I am not a very skilled programmer, and I've come to what is currently used for driving RMT by hacking the original code, to get the results I wanted I would literally have to write a new driver entirely from scratch, which is honestly a monumental task I am not quite ready for, and it probably wouldn't be as good as the current compromised setup anyway.

Another thing to keep in mind is that music notation tables won't be matching if any custom tuning configuration was used, and so things would sound wrong in either case, unless a bunch of extra work to export the tables is done, which might eventually happen at some point, but frankly I've become more and more burned out with all that stuff recently, and felt like not many people really wanted anything I did either, so we'll see as time passes...

 

The alternative method, and also the one I would personally use as well due to the greater amount of flexibility is the LZSS export.

It breaks all the restrictions from the 6502 ASM music driver itself, since pretty much anything can be written to the POKEY registers that way, would use a lot less CPU to play back, and might even save some memory with well optimised tunes, but it's also going to inflate really fast for longer and more complex tunes, which is then going to be a problem if memory requirements for a project is very limited.

But still, that's the method that will yield the much better results, as far as things are going currently.

 

So at the end, it really depends on how you want to use the music data, and what would be used as well  

There's just so much I have been responsible for breaking, and I hate this a lot, it's not fun to deal with the unhappy people stuck with incompatible data, or results that won't match anymore since they tried to run modules with my patched driver into the original RMT 1.28 driver... No surprise things won't quite work as expected, I am the first one to be upset about it, haha 😅

[Steril707]

1 hour ago, VinsCool said:

Ahh well I see... Didn't really think about this would be a problem.
I'll see if I or someone more comfortable with this kind of setup could make the program build for 64bit sometime later.

 

Very nice!

 

Well, I'm not the best for this kind of explanation, and also a bit of incompatibility currently exists with the exported songs data, but there's at least 2 ways to get things going:

 

The original method is to use stripped .rmt modules exported from RMT, then assembled into source code with the music driver, with the features enabled and disabled for the optimal results.

Unfortunately, as things are going right now, modules that would make use of the features specifically hacked together to work with my patched music driver code won't play correctly with the original RMT 1.28 ASM sources.

Using my own driver version (Patch 16) sources will work however, but it is both going to eat up a lot more memory and CPU, mainly due the fact that I am not a very skilled programmer, and I've come to what is currently used for driving RMT by hacking the original code, to get the results I wanted I would literally have to write a new driver entirely from scratch, which is honestly a monumental task I am not quite ready for, and it probably wouldn't be as good as the current compromised setup anyway.

Another thing to keep in mind is that music notation tables won't be matching if any custom tuning configuration was used, and so things would sound wrong in either case, unless a bunch of extra work to export the tables is done, which might eventually happen at some point, but frankly I've become more and more burned out with all that stuff recently, and felt like not many people really wanted anything I did either, so we'll see as time passes...

 

The alternative method, and also the one I would personally use as well due to the greater amount of flexibility is the LZSS export.

It breaks all the restrictions from the 6502 ASM music driver itself, since pretty much anything can be written to the POKEY registers that way, would use a lot less CPU to play back, and might even save some memory with well optimised tunes, but it's also going to inflate really fast for longer and more complex tunes, which is then going to be a problem if memory requirements for a project is very limited.

But still, that's the method that will yield the much better results, as far as things are going currently.

 

So at the end, it really depends on how you want to use the music data, and what would be used as well  

There's just so much I have been responsible for breaking, and I hate this a lot, it's not fun to deal with the unhappy people stuck with incompatible data, or results that won't match anymore since they tried to run modules with my patched driver into the original RMT 1.28 driver... No surprise things won't quite work as expected, I am the first one to be upset about it, haha 😅

Thanks for the thorough explanation, mate...

[Steril707]

Tried out loading the Track I did in 1.27, and it seems to work. Just strange that I can only hear something on one side of my headphones there.

 

There were not "sa_c6502.dll" and "sa_pokey.dll" when starting up, so I copied the ones from the 1.34 version. 
Like I said, it seems to play.

 

Will export this in 1.27, and see if I can get this to run in my game.

[RetroCoder]

The latest RMT version has got an exporter to cr eate relocatable assembler output for the rmtplayr.

Two assembler formats are supported (Atasm and Xasm).

The exporter will generate a section with rmt player features and the relocatable source code.

Cut the features from the file and put them into the rmt_feat.asm/.a65 file

Then its easy to locate your code wherever you find some space.

If continuous memory is a problem then you can easily relocate parts of the RMT song to other locations.

i.e You can move the instruments to a different location than the rest of your song.

 

The attached zip contains two folders, one form atasm, the other for xasm.

The file 'song4rmtplayer.asm' is the exported code.

 

RMT Music Export.zip

[Steril707]

37 minutes ago, RetroCoder said:

The latest RMT version has got an exporter to cr eate relocatable assembler output for the rmtplayr.

Two assembler formats are supported (Atasm and Xasm).

The exporter will generate a section with rmt player features and the relocatable source code.

 

RMT Music Export.zip 23.33 kB · 0 downloads

 

Which of these options is that? *scratching my head* 

Thanks for the help...

 

[VinsCool]

13 hours ago, Steril707 said:

Tried out loading the Track I did in 1.27, and it seems to work. Just strange that I can only hear something on one side of my headphones there.

 

There were not "sa_c6502.dll" and "sa_pokey.dll" when starting up, so I copied the ones from the 1.34 version. 
Like I said, it seems to play.

I can explain the reason this happens.

When using the plugins on older version, or using older plugins on newer versions this strange property where sound only plays in one side occurs.

This is simply due to a few changes to the emulated machine region and Mono/Stereo setup detection procedure in the RMT code I did, which is very easy to fix in any case.

Plugins initialisation and sound output changes are still work in progress, so that's why there is currently not much information regarding this effect.

I've included unofficial builds of the Altirra-RMT plugins in the Github repository with some of the tweaks in question, so those plugins will work with RMT versions 1.31 and above.

I admit I am still unsure how to properly use the plugins , so that's something to clarify later.

 

10 hours ago, RetroCoder said:

The latest RMT version has got an exporter to cr eate relocatable assembler output for the rmtplayr.

Two assembler formats are supported (Atasm and Xasm).

The exporter will generate a section with rmt player features and the relocatable source code.

Cut the features from the file and put them into the rmt_feat.asm/.a65 file

Then its easy to locate your code wherever you find some space.

If continuous memory is a problem then you can easily relocate parts of the RMT song to other locations.

i.e You can move the instruments to a different location than the rest of your song.

 

The attached zip contains two folders, one form atasm, the other for xasm.

The file 'song4rmtplayer.asm' is the exported code.

 

RMT Music Export.zip 23.33 kB · 3 downloads

The latest commit you did yesterday really took me by surprise, and I have to say, this is really awesome!

Lots of this will make exporting music much easier in the future, hopefully!

 

10 hours ago, Steril707 said:

 

Which of these options is that? *scratching my head* 

Thanks for the help...

 

That would be from using the most recent build of RMT from the Github repository.

I've only tested it quickly, but it seems to do exactly what was described in the reply above as far as I could tell!

[Steril707]

Aaah. Awesome news...

Will try out the new export function this weekend and report back...

[Steril707]

Ah, but that's not a "release" yet, is it?

 

Searching here, I can only find the one from Jul 3rd.

https://github.com/VinsCool/RASTER-Music-Tracker/releases

 

 

[VinsCool]

Recent progress can be found here: https://github.com/VinsCool/RASTER-Music-Tracker/commits/main 
So it hasn't yet been released, indeed.

 

[Foster_MSX]

Hello Foster here, a musician from Poland. After a 26-year break from Atari, I'm back to composing. It's nice to see that the Atari community, including the 8-bit one, is alive and well!

 

VinsCool - I would like to thank you very much for the continuation of Radek's work. I appreciate your workload, hours spent coding, consulting and sacrifices that come with it. For everyone involved in the topic - Respect!

Edited September 13, 2022 by Foster_MSX

[tatqoo]

Hi Foster, 

 

Looks like we will have a full Zelax re-activation soon. I am hoping for a great continuation of ZELAX and NG cooperation.

 

Regards,

 

tatqoo/NG/Taquart

 

BTW - VinsCool is a LEGEND!  

[Foster_MSX]

Hello tatqoo,

yes, it looks like it. I believe that the best is ahead of us all!

 

But, to the point

 

In the last century, I used the CMC by Janusz Pelc. The beginning of RMT's work for me was hardcore hahhh. Over time, what RMT 1.34 offers with the current modifications ... it blew my mind. For several weeks I have been tattooing my computer, I have not slept nights etc. So much fun!

 

6 weeks behind me with RMT and I get an export error: rmt + LZSS.xex

 

"Error, Buffer Overflow!"

 

But really? I'm just getting started ...

 

Is it possible to increase the buffer, or maybe I have something misconfigured in RMT itself?

 

I compose with sounds, unstable instruments, using timbre and its "predictable" randomness, modulating with channels in various ways. This applies a creative and different approach to songwriting, unlocks the potential for new POKEY sounds. This is a bit different than when dropping music from other platforms, where we already have certain instrument colors in advance.

 

At the moment, I have a problem with the song tempo and the file export mentioned above.

 

On the track, to get the speed I want, I use a loop:
F02
F03
-
F02
F03
-
F02
F03
F02 -> Loop1
F03
-
F02
F03
-
F02
F03 -> Loop2 ... etc.

 

My guess is that such swings can cause a buffer error, they take up extra memory and CPU time to play.(?)

 

Would it be great to define the tempo as BPM, or is it possible to make such a modification in future relase of RMT?

 

Dear VinsCool, hope you can find a moment for me. Of course I have an .rmt file. The song is not yet used in the game / demo - please do not publish it until it is officially released. I can send you an e-mail or a private message for technical purposes.

 

Regards,
Foster

[Foster_MSX]

Sorry, goes 2 times the same post. Pls, delete

Edited September 20, 2022 by Foster_MSX

[VinsCool]

On 9/20/2022 at 2:02 PM, Foster_MSX said:

In the last century, I used the CMC by Janusz Pelc. The beginning of RMT's work for me was hardcore hahhh. Over time, what RMT 1.34 offers with the current modifications ... it blew my mind. For several weeks I have been tattooing my computer, I have not slept nights etc. So much fun!

Hi there Foster, glad you are having a good time!

I've been working very hard to push the existing possibilities from RMT to the next level over the last year.

 

On 9/20/2022 at 2:02 PM, Foster_MSX said:

6 weeks behind me with RMT and I get an export error: rmt + LZSS.xex

 

"Error, Buffer Overflow!"

 

But really? I'm just getting started ...

 

Is it possible to increase the buffer, or maybe I have something misconfigured in RMT itself?

Darn, that is unfortunate...  

This is entirely my own fault, sadly.

 

Basically, I've done a very poor job handling memory, so if the message appeared, it meant that the LZSS data is too large to fit into the standard 64kb Atari memory (including the LZSS driver itself).

The reason this would happen is one of the following: either the music data is really long before a loop occured (in order of ~30-40 minutes as far as my extensive experimentation went during the making of it), or the Instrument Speed is too fast to fit inside the memory output.

I suppose the second option is the most likely to be what caused this error, there is currently not much I can do for this at the moment.

Here's what will make the files larger, regardless of the song itself: Stereo, which literally doubles the amount of register dumps per frame, and fast Instrument speed (xVBI), each multiple is theoretically likely to nearly double the data dumped in this case.

So if you for example made a Stereo song, which ran at 4xVBI speed, it really wouldn't take much time playing back to fill up the entire memory with the LZSS data stream 😕 

 

I honestly am willing to take the blame for this one.

The 6502 RMT driver is too difficult to maintain by itself, and that is even more problematic for building export binaries.

Each time I was editing the driver trying to add new functionalities or try to fix some problems I created with my additional features, I had to constantly re-write the exported binaries code, including new binaries prebuilt for that purpose, and test all of it to make sure it's correctly playing back once it was exported.

 

I've pretty much got annoyed about it, and the introduction of the LZSS export and LZSS driver really helped solve that issue by itself, since now only the registers dump from RMT, regardless of the driver itself, would be compatible with the exact same export binaries.

So yeah... the only way to mitigate this issue is to re-introduce the 6502 export driver format that used the .rmt modules directly, which is really not a fun task to do over and over, and over.

I can definitely see why Raster spent so much time crafting his music driver, and managed to keep it the gold standard for so many years, until I came into the spotlight and somehow... managed to hurt things more than I was expecting to actually do with my own ideas.

 

I need to mention I did take some time off the project to reconsider what I want to do and what I should improve after breaking pretty much everything that uses RMT one way or another.

Ideally, the 6502 driver export format should be re-introduced, and I hope there is a way to truly make both the original driver and my own patched version to co-exist in a less chaotic kind of balance.

Please don't get me wrong, I absolutely love the ease to use and convenience of the LZSS export format, but it has its own limitations too, which is memory, and that fills up much faster than one would expect.

 

I really want to create a new driver entirely from scratch at some point, and also keep the original for more optimised productions if they are aimed for games and demos, while my own would aim to exploit the soundchip as much as it could be, if that makes any sense.

If you need more help or really need to export a song to integrate to a project, please contact me by PM, I would be happy to try helping you to find a solution with the best of my abilities.

Thank you, and sorry for the inconvenience, I knew that would have been a problem eventually.

[ivop]

29 minutes ago, VinsCool said:

Each time I was editing the driver trying to add new functionalities or try to fix some problems I created with my additional features, I had to constantly re-write the exported binaries code, including new binaries prebuilt for that purpose, and test all of it to make sure it's correctly playing back once it was exported.

That's what a Makefile is for. I assume VS has a mechanism to call external programs and reassemble the proper binary code and include that in the resulting executable each time you make a change.

 

[Mathy]

Hello Vin

 

Stop putting yourself or the work you did on RMT down.  Raster put a lot of work in RMT, but when it comes to the work that's put into RMT, you're the number two.  And everybody I hear talking about you and the work you did on RMT speaks of you with great admiration.  I'm sure Raster would be proud of you.

 

Sincerely

 

Mathy

 

 

[VinsCool]

17 minutes ago, ivop said:

That's what a Makefile is for. I assume VS has a mechanism to call external programs and reassemble the proper binary code and include that in the resulting executable each time you make a change.

 

To be honest, there's a cruel lot of things I have yet to learn still, hehehe... 😓

I've learned to understand how the export binaries are being deconstructed-reconstructed now too, since I've made the bigger changes for the LZSS export format, so I can see where I failed before, and how I can do much better now.

 

It's important to remember the context from which I've come from regarding the binaries from within RMT: it came from literally hacking the .exe itself before even making any actual code back then.

I do know better now regarding some of the "quirks" I remember being stuck with several months ago, and I admit I had gotten so frustrated about this that I've pretty much added the LZSS export format entirely out of spite, while stripping away the original 6502 binaries export format because I no longer wanted to ever spend hours after hours testing them and get stumped with unexplained bugs.

 

I have a much better understanding of all this stuff now, and honestly, I do regret some of my decisions before posting the RMT 1.34 versions alongside the sources.

I was burned out, it was still unclear for a long time if I was even authorised to share the sources at all until the very last days I learned I got the green light for it, and so you can see how everything just got to the point we are today.

 

Despite this, thankfully, I know there has been work in the re-organisation of the exported data, among other improvements, while I was still just doing my things in the other side, so I am pretty sure it's just a matter of time before we get a proper solution for all of this  

 

26 minutes ago, Mathy said:

Hello Vin

 

Stop putting yourself or the work you did on RMT down.  Raster put a lot of work in RMT, but when it comes to the work that's put into RMT, you're the number two.  And everybody I hear talking about you and the work you did on RMT speaks of you with great admiration.  I'm sure Raster would be proud of you.

 

Sincerely

 

Mathy

 

Thank you very much!

And sorry for being so negative against myself, I really try to make things happen a bit too hard, and that really breaks me up sometime  

[Steril707]

Yep, great job, mate.. 

We appreciate everything you do..

[dhor]

Well, am I the only one who can see problems with the player? I mean, new features means new possibilities, new possibilities mean new routine, new routine means new player - and so on.

[VinsCool]

It's a never ending story 😆 

Once it comes full circle, it's time to do it again! Lol

[RetroCoder]

I'm busy rewriting the LZSS / SAP-R export section.  Should all be dynamic and very flexible by the end of the week

[VinsCool]

5 hours ago, RetroCoder said:

I'm busy rewriting the LZSS / SAP-R export section.  Should all be dynamic and very flexible by the end of the week

A more than welcome improvement!

I've truly done a terrible job regarding memory management at the time 😬 

I think it's only around as late as 2 weeks ago, by working on the tuning improvements, and also on a semi-unrelated program, that I've finally learned how to make use of pointers and references properly 😂 

[Foster_MSX]

VinsCool - thank you for the quick reply. I agree completely with the previous speakers. You are one of the few people in the world who have had the will, knowledge and opportunity to devote themselves to this program.

 

Gentlemen! I can only keep my fingers crossed for the future development of RMT and wish you good health.

[DerpDerp3001]

What does command 6 do? I've set the instrument's distortion to 6 and messed around, but there was no difference in sound.

Edited December 19, 2022 by DerpDerp3001