[RELEASE] RASTER Music Tracker, v1.34.00

[pseudografx]

To set the record straight, Bob!k wanted to release the source code of Raster's works (not only RMT, but also his other projects) already this summer, but for technical reasons this has not happened yet. It turned out that the source files were quite cluttered and needed to be reviewed and organized in order to be placed in an online repository, but there was some hardware glitch that complicated everything, along with the time-consuming nature of the procedure. So the release of all the source code is still on schedule, but it's not yet clear when that will finally happen.

[ivop]

20 hours ago, VinsCool said:

to compute tuning tables in real time, if you see what I mean  

Yes, basically convert the spreadsheet to C++

 

It would be nice if once the key of the song is determined, you can generate tuning tables for pure major/minor diatonic tuning, 12-TET, or your compromise mixture that also sounds good.

 

Loadable/savable tables would be cool, too.

 

[VinsCool]

3 hours ago, ivop said:

Yes, basically convert the spreadsheet to C++

Ayup!

That's exactly what I did do for the real time notes and pitches visualisation, I used my spreadsheet formulae and made up some new ones for this purpose, like the Distortion C periodic pattern that uses one or the other formula.

There's still a bunch missing, and I simply calculated the number of cents off from a pitch of 440hz, but the core is fully functional already.

3 hours ago, ivop said:

It would be nice if once the key of the song is determined, you can generate tuning tables for pure major/minor diatonic tuning, 12-TET, or your compromise mixture that also sounds good.

I absolutely agree with you there!

A far fetched goal is to essentially to provide a base pitch/ratio reference for tuning, and let the program generate the best possible values automatically if I want to use them in the songs.

That would save me a ton of work over making the tables by hand in 6502 ASM.

3 hours ago, ivop said:

Loadable/savable tables would be cool, too.

I already have a rudimentary concept of that in place, actually. in the file 'RMT Tables.obx', located in the RMT Binaries folder.

ORG to $B000, which is where I planned to put all the tables I make. Currently, that is the file that is loaded into the exports, by stacking pieces of everything together, and from the player point of view, use offsets to load the appropriate tables needed.

The idea was to use most of the same approach from the Registers Viewer, to compute the tuning into arrays of memory location, and save it all into tables that can then be loaded or saved without any penalty.

I also have plans to add a new instrument byte to set that offset directly, saving a lot of work when it's time to load tables in memory at execution time, but that's still a theory more than things I tried yet.

 

But before I go crazy for some more time, I am back to square one.

I must remake my entire patch 16 hack before I do anything else, just to at least, have a much less bloated version of it, and benefit from conditional assembly compilation, since it is a pain to really make use of my code in its current state.

I had that idea of going "all out" and have as many features as possible, but that is really against the point if you're not only making music for the sake of it.

 

So anyway...

 

Here's a new version before I do anything else:

 

Changes in RMT 1.31.22
-------------------
- Tweak the NTSC timing hack, should be a little closer to the actual thing now
- Fix the step size of 0 to force a movement of 1 when movement keys are used, to prevent getting stuck (thanks Ravancloak for pointing this out!)
- Force a .ini file write if no config is found when RMT.exe is launched, setting the default configuration (thanks again Ravancloak!)
- Added one of my own tunes I missed last time (Stranded on the Surface of Io Final.rmt), and updated a tune upon author's request (ilusia.rmt)

rmt131.22.zip

 

What I am going to work on next is the driver itself, and with the functional binaries loader without the memory limitations that fucked me up before, this will be a shit ton easier to test as well.

[VinsCool]

Proof of concept: load tuning tables using the unused 12th instrument byte.

So yep, I was able to prove this can indeed be done  

That may be a huge game changer when combined to even more advanced manipulations like LZSS compression.

de la bonne compote unused instrument byte test.obx

[_The Doctor__]

Now that certainly has made a world of difference! XOXOXOXOXOXOXO loving it!

[ilmenit]

Hmm... Export to LZSS? ?

[emkay]

About the vibrato #3

 

Have your own opinion. 

In this tune , I used the vibrato "3" often.

But every time when the vibrato is used, I set the value on the envelope to "command 2 ff" . It's a pitch higher, as you know. 

 

 

[_The Doctor__]

3 hours ago, emkay said:

About the vibrato #3

 

Have your own opinion. 

In this tune , I used the vibrato "3" often.

But every time when the vibrato is used, I set the value on the envelope to "command 2 ff" . It's a pitch higher, as you know. 

 

 

posting this without the pitch higher as well would allow for a real comparison

 

[emkay]

8 hours ago, _The Doctor__ said:

posting this without the pitch higher as well would allow for a real comparison

 

Well... I could do a different version this evening. 

Edited January 10, 2022 by emkay

[emkay]

 

[VinsCool]

I edited a 2019 module I made to balance the mix a little better.

Charge Man.rmt

Edited January 11, 2022 by VinsCool
Forgot to link the video

[+MrFish]

4 hours ago, VinsCool said:

I edited a 2019 module I made to balance the mix a little better.

Charge Man.rmt 3.31 kB · 9 downloads

Sounds great.

 

[emkay]

Vibrato 3 is definitely not correct. 

 

Here is some changing.

The goal is to let POKEY tunes sounding "unclamped". And after a listen to the original, I'm right here

 

 

Charge Manmk.rmt

[emkay]

The original notation is weird in RMT. 

As it seems to be close to 880 Hz in higer notes, but 432Hz in lower notes. 

The correction clearly was possible, to have 110, 220, 440, 880, 1760, 3520...  on the closest pitch dependency, to have the octaves right. 

The command 3 for vibratos seems to do some quirk inbetween. 

As the lower notes no really were at the correct 440Hz range, the higher pitch for vibrato 3 makes sense. 

[VinsCool]

3 hours ago, emkay said:

Vibrato 3 is definitely not correct. 

I can see what you mean I suppose:

	IFT FEAT_EFFECTVIBRATO
vibtabbeg dta 0,vib1-vib0,vib2-vib0,vib3-vib0
vib0	dta 0
vib1	dta 1,-1,-1,1
vib2	dta 1,0,-1,-1,0,1
vib3	dta 1,1,0,-1,-1,-1,-1,0,1,1
vibtabnext
	dta vib0-vib0+0
	dta vib1-vib0+1,vib1-vib0+2,vib1-vib0+3,vib1-vib0+0
	dta vib2-vib0+1,vib2-vib0+2,vib2-vib0+3,vib2-vib0+4,vib2-vib0+5,vib2-vib0+0
	dta vib3-vib0+1,vib3-vib0+2,vib3-vib0+3,vib3-vib0+4,vib3-vib0+5,vib3-vib0+6,vib3-vib0+7,vib3-vib0+8,vib3-vib0+9,vib3-vib0+0
	EIF	

In my opinion, all the vibratos sound okay for the ease to use purpose, but starting the frequencies on 1 (here, that's pitching down by 1 unit) may be related to that.

Vibrato 3 is especially odd here-- the pitch is less often on the 0 (no shift) than it should be, which probably contributes to the feeling.

I think Vibrato 2 is the best sweet spot for typical tunes, but in any case, Vibrato 3 does the job, so I don't really mind it for now.

Regardless, I want to touch up the vibrato code in a near future, but that's low in the priority, using the Table of Freq mode in instruments does a fine job for manually tweaking the vibrato.

3 hours ago, emkay said:

The original notation is weird in RMT. 

As it seems to be close to 880 Hz in higer notes, but 432Hz in lower notes. 

The correction clearly was possible, to have 110, 220, 440, 880, 1760, 3520...  on the closest pitch dependency, to have the octaves right. 

The command 3 for vibratos seems to do some quirk inbetween. 

As the lower notes no really were at the correct 440Hz range, the higher pitch for vibrato 3 makes sense. 

That's precisely my motivation for editing the tuning tables, and make up new ones for as many things as possible, including proper 16-bit mode (still work in progress as I speak).

The really disappointing observation is not about how it was not on the right pitch, but more about how the documentation used as reference from the 1980's was simply wrong.

They had examples of tuning, but they all exhibited the same flaw: the interval between notes was much more wrong than it needed to be, just because they tried too hard to be on the A-4=440hz range, which itself was intended to be used on NTSC hardware!

The solution was simpler than even I had thought at first: The intervals are what gives the perception of tuning being well.

So all I had to figure out was the pattern where the amount of cents off between notes was as small as possible, and that's pretty much what my tuning is right now.

It's not perfect at all, it will get further improvements sometime soon, but it certainly helps a lot in most situations compared to what was available before.

Now back to the vibrato: I agree, it could get some improvements. But like I said, that's not my priority at the moment.

[VinsCool]

Anyway, here's another module I unhacked just for fun.

Pinky - Xmas Edition - Overworld 1 Final.rmt

For some reason I'm unhacking my modules because they don't need to use RMT2LZSS anymore.
At least not until that program gets an update based on my patch16-2 code changes.

 

The Laxity cover will be a nightmare however, so I doubt I will waste my time on it lol
Also 15khz tuning sucks above C-3 ?

 

Edited January 11, 2022 by VinsCool
Linked the video

[emkay]

7 hours ago, VinsCool said:

Anyway, here's another module I unhacked just for fun.

 

 

What is the "Original" of this tune?

[emkay]

12 hours ago, emkay said:

What is the "Original" of this tune?

OK. Found it. 

So here some edit using 1.31 and a try to resemble the main voice. And some simulated bass pwm

 

 

 

 

lng.xex

[emkay]

And some video

 

 

[VinsCool]

Nice, but your edit introduced several wrong notes.

 

I have been at work a bit after I posted my file, and found a easy way to re-introduce the sawtooth wave my first version used, since it was made with RMT Patch8 at that time.

 

It was simple enough, but I need to re-tune all my sawtooth table for now so I'll post more about it later.

 

All I had to do was to add 2 extra instructions in the 1.79mhz jump code I made for my Patch16-2 improvement, and there check if also the hipass filter bit was enabled, as well as the other 1.79mhz channel at the same time.

 

From there I jumped to a new table pointer I added for the occasion, and voilà, sawtooth easy to go, for now I locked it under Distortion A, otherwise this will be ignored.

 

Not perfect for now, but it does the job as a proof of concept, so just like 16-bit and all the other additions, the key for it to work is to make sure I set the branching correctly

[emkay]

2 aspects seem to work perfectly now:

1. notation correction

2. AUDCTL setting

 

 

 

[VinsCool]

Just wait for the driver update I am currently cooking... It will get even better ?

[emkay]

On 1/20/2022 at 3:17 AM, VinsCool said:

Just wait for the driver update I am currently cooking... It will get even better ?

I'm not missing things yet. 

As additional features need to be tested. 

Still real 4 channel usage + some filter

You know, I name it 6 channel mode

 

 

[emkay]

Another one... not perfect, but...

 

 

To every video I should add some "thanks Vin" 

[VinsCool]

I like the last one! very nice and smooth sounds.

 

Speaking of smooth sounds... I've come close to get done with some of my recent driver changes, and earlier today I got hit by a eureka moment, which means I may get a drastic performance boost with the code I've been tweaking for the last couple days now.

As a result, I'm still in the process of working on it for the week end (and I mean, woohoo, it's Friday, I have the time for it!), but I have really good optimism about this.

It's possibly going to be my best iteration of the driver hack so far, featuring multiple new features, optimisations, and some bug fixes that I had introduced in the process...

 

So I cross my fingers to have something to show today, because I can say with confidence this really will make a big difference compared to the handful of stand alone tracker binaries revisions I posted recently.

Think of those wip versions, throw them in the trash, because I really was making junk, compared to what I am experimenting with this time.

It took me a lot of thoughts outside the box, but that's going to be worth the headache!

 

I just hate that my week long progress is essentially worthless... because I've literally done much better than that just tonight, when I had a moment, before getting back home and have dinner ?

I'll come back with more updates soon!