Trying to make some PoKEY music!

[VinsCool]

[Original] Stranded on the Surface of Io (Atari PoKEY, Recorded from Real Hardware)

So here's a original tune from me, for once in a Blue Moon (see what I did here?  )

This is also the first tune I made that is exclusively using my hacked RMT version.
Enjoy!

Stranded on the Surface of Io Final.rmt Stranded on the Surface of Io Final.xex

[emkay]

Seems, it will never change that people will end in a "soundtrack" with the bass as the hook of the tune.

But this time it is not getting boring after a short time, by the used FX . 

Very good. The ambient keeps also to be stable.

Now imagine to be stranded on the surface of planet Io in a 3D field, exploring the unknown aera, encountering enemies... 

[+Philsan]

13 hours ago, VinsCool said:

[Original] Stranded on the Surface of Io (Atari PoKEY, Recorded from Real Hardware)

So here's a original tune from me, for once in a Blue Moon (see what I did here?  )

This is also the first tune I made that is exclusively using my hacked RMT version.
Enjoy!

Stranded on the Surface of Io Final.rmt 4.39 kB · 1 download Stranded on the Surface of Io Final.xex 6.5 kB · 2 downloads

Cool!

It recognizes PAL/NTSC isn't it?

[VinsCool]

1 hour ago, Philsan said:

Cool!

It recognizes PAL/NTSC isn't it?

Yes. This one was made in PAL/50hz but also runs fine in my NTSC/60hz setup  

[VinsCool]

10 hours ago, emkay said:

Seems, it will never change that people will end in a "soundtrack" with the bass as the hook of the tune.

But this time it is not getting boring after a short time, by the used FX . 

Very good. The ambient keeps also to be stable.

Now imagine to be stranded on the surface of planet Io in a 3D field, exploring the unknown aera, encountering enemies... 

I tried to make it catchy, mostly!
I wanted it to be something ambient, but also groovy, with a sense of unease floating on top of the tune, which was thankfully achieved with the minor keys, the odd time signature, the thick bass, and hopefully the right amount of detuning.

I think that worked well because it honestly grew on me, the Distortion 2 ostinato got me addicted to my own tune... which is honestly an exploit because I usually dislike what I compose myself.
I think I am also falling in love with the Distortion 2 timbre... It sounds really good when it's tuned well, in my opinion.

[ivop]

23 minutes ago, VinsCool said:

the odd time signature

I loved that, where the open/closed hats got in and out of sync with the groove!

 

[emkay]

29 minutes ago, ivop said:

I loved that, where the open/closed hats got in and out of sync with the groove!

 

You means that dshgrm, dshgrm, dshgrm, dshgrrsg... Yes, it's very cool.

[VinsCool]

1 hour ago, ivop said:

I loved that, where the open/closed hats got in and out of sync with the groove!

The groove was mainly done through syncopation of speed commands, and I think that worked especially well for keeping everything together with surprising stability.
50hz Speed 7 was the intended speed going through the entire thing, but careful changes to 8 then 6 then back to 7 every beat sold it for me. I was first experimenting with a 16 rows loop and I thought "oh fuck yes that will work"
That went along with my signature transition style of slowing down everything then start the new section, I can't say it's getting too gimmicky but man do I love that sort of design when I compose all sort of experimental tunes  

[VinsCool]

A test tune for my new hijack method.
Can you tell when it's running at 15khz and when it's not? This new hijack will automatically use the appropriate tuning table between modes, something I wanted to be able to use for a while now!

 

[+MrFish]

36 minutes ago, VinsCool said:

A test tune for my new hijack method.
Can you tell when it's running at 15khz and when it's not? This new hijack will automatically use the appropriate tuning table between modes, something I wanted to be able to use for a while now!

I was wondering if somebody would get around to implementing this type of thing.

 

Sounds good, but I think something a little more demonstrative is in order. The tune here is a bit understated when comes to melody.

 

Edited July 13, 2021 by MrFish

[VinsCool]

3 minutes ago, MrFish said:

Sounds good, but I think something a little more demonstrative is in order. The tune here is a bit understated when comes to melody.

Thanks
Yeah well I only really wanted to test out the 15khz/64khz switching so that was really not a first thought lol
I don't think I have a tune that is melodic enough right now for a better demonstration... I'll try to find something I have saved around lol

[+MrFish]

2 minutes ago, VinsCool said:

Yeah well I only really wanted to test out the 15khz/64khz switching so that was really not a first thought lol

 

Yeah, I figured that. You had to start somewhere with it.

  

2 minutes ago, VinsCool said:

I don't think I have a tune that is melodic enough right now for a better demonstration... I'll try to find something I have saved around lol

 

You'll come up with something. Trust me.

 

[VinsCool]

1 hour ago, MrFish said:

You'll come up with something. Trust me.

 

Bah I sure have a pattern or 2 from a revisited sketch doing that design specifically but now it's like 5:00 am and I'm like welp guess I overshot this one lol
Mr. Tinnitus' Super Special Jukebox has some promising ideas at least  

[VinsCool]

Phat Phuk (RMT Patch 16 Beta3 Test Tune)

NTSC, 60hz, Requires RMT Patch 16 Beta3 to play correctly.
 

Phat Phuk.xex Phat Phuk.rmt

[_The Doctor__]

4 hours ago, VinsCool said:

Phat Phuk (RMT Patch 16 Beta3 Test Tune)

NTSC, 60hz, Requires RMT Patch 16 Beta3 to play correctly.
 

Phat Phuk.xex 4.67 kB · 1 download Phat Phuk.rmt 2.51 kB · 1 download

I've just been to a rave gone deep trance...

 

[VinsCool]

Sorry for posting the same thing in 2 different threads but I wanted to make sure this was also in here  

Xenon - In Game Music #1 (Atari PoKEY Cover, Recorded from Real Hardware)

 Recorded from my PAL Atari 800xl, 50hz.

Xenon Final.rmt Xenon Final.xex

[rensoup]

27 minutes ago, VinsCool said:

Sorry for posting the same thing in 2 different threads but I wanted to make sure this was also in here  

I made sure to like it in both threads, totally captures the spirit!

[VinsCool]

Been learning how to code in 6502 ASM and slowly making my own music player routine, still heavily based on existing code, for now.
The base code for the RMT player visuals was borrowed from Pigu, now edited heavily, and merged with my own RMT Player code.  

 

I really like where this entire project is going now  

[VinsCool]

This is a really rough implementation of Two-Tone Filter for now but hey it works for sure!  

This is currently done by hijacking RMT Distortion 6, with the same table of notes from Distortion A assigned on it.

music.obx

Edited July 21, 2021 by VinsCool

[rensoup]

20 hours ago, VinsCool said:

I really like where this entire project is going now  

Another 6502 asm player ? it's headed in the wrong direction for sure ? but I get that the learning process is enjoyable!

 

So it's a player that plays RMT? tell us more ?

[VinsCool]

5 hours ago, rensoup said:

Another 6502 asm player ?

Yeah... Still heavily based around the RMT code, but I'm trying to make use of it in ways that would do things currently not possible in the tracker itself. Right now my code doesn't fit the limits of the .exe itself, but it's nice concept to attempt anyway  

5 hours ago, rensoup said:

it's headed in the wrong direction for sure ?

Thanks for the encouragement! My direction is the wrong one for sure, so I suppose I'm on the right offtrack.
For now I'm just trying to be able to use this code as a RMT + extras output, and it's still way easier to make music with a tracker, so custom player + RMT module is comfortable enough for me.

May I ask, why is it wrong anyway? I am not trying to go into demo or game production, at least, not right now, so making use of everything I could use just for music production is currently what I am trying to do.
Mostly for proving a point or something I suppose? lol. If I can do it myself now, I would be even less likely to ask about something I want but couldn't do it with existing tools, hahahaha

5 hours ago, rensoup said:

So it's a player that plays RMT? tell us more ?

Right now, this is pretty much it yeah. (spoiler alert, wall of text incoming...)

The original visualisation code was altered quite a lot compared to the version I started from, it seems like the coder really intended to use this for the tune it was coming with, and nothing else.
So it was limited to only Stereo RMT modules, and the RMT 1.28 player, which only had a few changes to display the Pattern and Row values on the screen.
I first started by using my hacked Player, be able to at least assemble it for the first time despite anything I could have broken, then continued from there.

 

I must first say a big thanks to Pigu, who made the original code for the visualisation part, the things I wanted to see and a solid groundwork for being able to push it further!

This is the version I started from, which was for this tune:

It probably doesn't look like I have actually changed many things yet, but I swear I did, and thankfully everything mostly works still!
If you are reading this Pigu, thanks again! It's helping learn a lot more how to code.

This time I am not as limited as I was since right now I am not trying to fit into a arbitrary file size, just to prove things work, optimisations will follow latr while I get more experience at this,
So what I am trying to do right now is to hopefully turn it into a easy to use RMT player, similar to the simple player used for XEX exports, but with cooler visuals.

At the moment this makes use of:

- My custom RMT Player (the same one I had been hacking into RMT.exe, currently it will not fit that arbitrary space lol)

- Register values visualisation, and hopefully more detailed stuff like Note values and Frequencies (thanks to my spreadsheet for the computation!)

Currently this is pretty badly coded, I know, but I will try to make my code a lot less bloated as I find better tricks to achieve it.

- Since now I can actually fuck around the player more without worrying about the RMT.exe compatibility (for now), I can finally move things around, so more Tables from different memory pages will be available.

- Hacked together a "Dual Mono" mode, so 4 channels RMT modules will work on a Stereo setup, else things would either play incorrectly or only on the left channel. STEREOMODE==4 is what is required to define be able to use it.
This is a rmtplayr.a65 exclusive code for now, however I think this is pretty cool feature!
- Added a very rough method to manipulate the SKCTL register, into the RMT Distortion (Slot) 6, so each time it is used, $8B is written into SKCTL, enabling the Two-Tone Filter. It could have done in a cleaner and better way but I'll try to improve it later.
This was also a rmtplayr.a65 exclusive code, but other than that it's still virtually the same as the Patch16 Beta3.
- Added a very simple "song title" line that could very easily be edited into anything within 32 characters long.

My goals for the future, be it possible, or very difficult, or be very CPU+Memory hungry, will depend on a lot of things, but I will still try to do them anyway.

- More information displayed on the screen, such as several useful registers, frame counter, RANDOM, etc, as well as Notes and their actual frequencies, because I'm a nerd and I love to see numbers on the screen.

Could also be really useful for more complex sounds in the future.

- Clean a lot of the things I added, or implement them better. There are numerous things that were redundant while the original code to display infos line by line is there, I just haven't figured out how to fully make use of it yet.

For example, the SKCTL code in the Visualiser part is very bloated, and even has its own duct taped method to "clear" the screen when an actual routine for that purpose already exists in the code and would only need a few changes to achieve the same thing...
There is also the AUDC and AUDF registers that ate a lot of memory and CPU cycles just to display, because I went above the same code I mentioned above just as a POC, hopefully things will be cleaner later.

- Add several IFT ELS EIF statements so I could easily assemble the code without certain features, or different code, without too much trouble.
For now only the STEREOMODE==1 and STEREOMODE==4 have their exceptions, but many more things would need it if I plan to use this code in a more optimal way (basically stripping away everything I don't need to use at assembly time)

- Separate all the RMT tuning tables into a different set of memory pages, with matching mapping for them, so that way I could use the available space the most efficiently possible, and have access to a lot of extras without sweating about running out of bytes.
I might also consider moving the RMT modules to a different spot as well, $4000 is currently what is assigned for it.
- Basically move everything around, I hope I could do it in a functional way

Right now it's something like: 'RMT Player, Start of Visual code, Module, Remaining part of Visual code', and I don't feel too comfortable doing it in that order, especially when large RMT modules overwrite sections of the memory (I had to move the ORG twice already because I tried to use very large RMT modules each time, lol).
I have not tried to do any big changes like this yet, but ideally, I would make the Player begin execution at $3300, with the Visualiser code on top of it, and finally the Tuning tables at the end of this order.

Then, load the RMT module, ideally I could fit everything within $5000 before the module, using the remaining space. 

Hopefully I never go beyond that and overwrite more things by accident, lol

- Make even nicer graphics once I learn how and if the CPU hasn't died under the shitload of work it may end up doing, hahaha

- More far fetched but I hope I could find how to expand RMT.exe in order to fit more of my hacks into it, because being able to play and make the music in real time is fun!

Turning this into a native music making program would be even cooler but I seriously doubt I would be able to do something like that so forget about it for now lol

In the mean time, all of this is just for fun, and for learning, so I really don't want to pretend making a revolution of POKEY music creation with this stuff.
It's also not very optimised so Demos and Games won't benefit from what I am attempting to do, if low memory usage and low CPU usage is the requirement.

I guess that's about it for now lol
Sorry for getting into a ramble again, I just have a lot of fun with this right now.

Edit: oh and btw rensoup I have sent you a message on the Discord a couple days ago, I don't know if you have seen it yet, but I thought you would be interested  

Edited July 22, 2021 by VinsCool
remembered I forgot to mention something after my nerd ramble

[VinsCool]

[Original] Sieur Goupil (Atari PoKEY) + Dual Mono Experiment

NTSC, 60hz, Stereo optional  

Sieur Goupil.obx Sieur Goupil.rmt

[rensoup]

18 hours ago, VinsCool said:

May I ask, why is it wrong anyway? I am not trying to go into demo or game production, at least, not right now, so making use of everything I could use just for music production is currently what I am trying to do.
Mostly for proving a point or something I suppose? lol. If I can do it myself now, I would be even less likely to ask about something I want but couldn't do it with existing tools, hahahaha

 

I mentioned it in the "moving beyond RMT" thread but to sumarize...

 

The concept of having an ASM 6502 player is outdated but that's IMO of course. Unless it can do things that LZSS can't do (like updating registers at specific cycles), it's redundant.

To edit a tune, the editor has to have that xex in memory and do that messy emulation thing like RMT -or- it has to have a high level version of the player (in C or whatever) and modifying one means updating the other which is a longer and error prone process.

The better solution is to only have the high level version of the player and send the data to Pokey directly... that solution doesn't exist of course ?

 

So even though it's not right to write an ASM player, it is addictive... to a point ?. Hell that's why I started PoP! But after spending so much time doing the "implement feature, run out of memory, optimize for memory" loop and making the code more fragile with each optimization, I finding myself cursing at the MOS engineers a little too often ?

 

18 hours ago, VinsCool said:

Right now, this is pretty much it yeah. (spoiler alert, wall of text incoming...)

Ouch!

 

That feature list is scary! But you're learning ASM which is great, so even though it may not end with an ideal solution, I totally understand how exciting this is. A lot of the great musicians were also coders so you're following their tracks ?

 

[VinsCool]

20 hours ago, rensoup said:

I mentioned it in the "moving beyond RMT" thread but to sumarize...

 

The concept of having an ASM 6502 player is outdated but that's IMO of course. Unless it can do things that LZSS can't do (like updating registers at specific cycles), it's redundant.

To edit a tune, the editor has to have that xex in memory and do that messy emulation thing like RMT -or- it has to have a high level version of the player (in C or whatever) and modifying one means updating the other which is a longer and error prone process.

Ahh yeah I see where you are going with this, I agree with you in this case.
My goal is a different one, having real hardware compatibility and by speculation, a RMT version with these features was the reason for starting my experiments.

Even if this is very pointless, to me, it is still something I learn from, and would make use of, if I can!

20 hours ago, rensoup said:

The better solution is to only have the high level version of the player and send the data to Pokey directly... that solution doesn't exist of course ?

yet... right?
Unfortunately I won't be the one for this task, unless we all wait for another decade, hahaha

20 hours ago, rensoup said:

So even though it's not right to write an ASM player, it is addictive... to a point ?. Hell that's why I started PoP! But after spending so much time doing the "implement feature, run out of memory, optimize for memory" loop and making the code more fragile with each optimization, I finding myself cursing at the MOS engineers a little too often ?

This is nice! It shows how much dedication can prove things to be possible!

I personally began fucking around the code directly for a different reason, but now I got addicted to it!

It's so fucking satisfying to be able to get something work the way I want, without making everyone take a guess from "what if" or "is it possible to", or just make no sense at all with video examples of what could be done and not sharing any files for the matter.
I also curse at myself instead because I know I did something wrong when it doesn't work like I wanted lol
But hey that's part of learning, I simply learn the hard way about what to NOT do, in most cases hahahahaa

20 hours ago, rensoup said:

Ouch!

I warned you hahahaha  

21 hours ago, rensoup said:

 

 That feature list is scary! But you're learning ASM which is great, so even though it may not end with an ideal solution, I totally understand how exciting this is. A lot of the great musicians were also coders so you're following their tracks  

Thanks! Again, I fully acknowledge everything I do currently is "ideal", it's mostly to prove what could be done, by doing it myself as much as I could!
I'm aware I relied heavily on the code from Raster, Analmux and Pigu to achieve this so far, but it still proves to be functional in this state regardless.
Plus I also have proven several things could be done differently in the RMT tracker, and I will definitely keep pushing that until I really make the whole CPU and RAM overloaded, because if making music is my goal, nothing else really matters  
Just thinking of LSDJ on the Gameboy for example, this is a Music focused program, so it barely has any room to fit a game or demo along with it, and that's why it's awesome: you can do a fuck ton of audio things a Gameboy was never designed for!

 

I do not consider myself to be a great musician, but I really appreciate the compliment! A lot of the people in the scene were a big inspiration for me, and I hope I can do very cool things of my own too  

[VinsCool]

I forgot to post this experimental tune the other day, mainly because I was busy with different A8 projects...
I thought some of you would find it interesting, and hopefully I will get some ideas for it later too

 

This is running with the exact same RMT Player code I hacked a little while ago, the only difference is the handling of the 16-bit output to produce the 'Clarinet' sound.
The visual player also has gotten a bunch of improvements since the other tune I shared in this thread too  
Also this runs at NTSC speed. I did not yet edit the code to accommodate when a tune runs from one region in another, and vice versa.

Sketch 57.obx

Edited July 29, 2021 by VinsCool
Addendum