Jump to content
VinsCool

[RELEASE] Raster Music Tracker, Unofficial version 1.33 BETA by VinsCool

Recommended Posts

Let's talk about "Absolute" Pulse Width Modulation using AUTOFILTER 👀

This was a feature that always felt awkward to use for some reason, but I think I might have figured out the solution.

 

I only had to change a couple things in the 6502 driver code, and this is what I have got so far:

 

That's not a lot, but right off the bat, here's the obvious differences:

- Offset starts at 0, and can be manually set using CMD6, where it would NOT actually stack up, but become an absolute offset

This one was actually something that bothered me for a really long time, so here I did change that, and at the end, this gives more control over the sound modulated.

- The generated sound is now pretty stable, no more random pulses, or "wobbling" if you allow me to use this term

Entirely related to the first statement. This was not "bad" POKEY emulation, or weird RMT quirks, this was entirely related to that same default offset of 1, which just made things unpredictable!

- It is not necessary to mute the other channel when the PWM sound is output

That was actually something that I did change a long time ago, but yeah, having the modulation underneath greatly enhance the sound, so there's no reason to artificially limit the features, right? :D 

 

This will definitely change the feeling I have about using that AUTOFILTER personally, now that it went from "annoying to use" to "Insanely good" in not that much work, surprisingly.

I especially disliked the "all over the place" nature of the pulses that were output before, and manually doing all the modulation was frustratingly slow when multiple instruments were necessary.

This might bring a lot more fun in the near future when a SID-like lead is needed in a tune ;) 

 

Coming soon in a future update, which will also include a LOT of improvements in my hacked 6502 ASM driver, I hope this time I will have fixed all the things I did wrong so far! haha

 

  • Like 6

Share this post


Link to post
Share on other sites

what the fuck am I doing anymore lol

I think there is no doubt anymore, there is no "wobbling" as far as I could tell, things are always very consistent in this one, usually pulses would to be all over the place, and often muted!

  • Like 6
  • Thanks 1

Share this post


Link to post
Share on other sites

Tonight I finally addressed an issue that was known for a while, but not actually a problem until recently.

The frequencies overflow bug when the Vibrato/AUTOFILTER/CMD2/Tables of Freqs are going lower (higher, so confusing!) than #$FF, resulting in an overflow to high pitched noises at the worst times!

I remember having noticed this a long time ago, and I remember some people actually asked me about taking a look at it, so I figured this was a good time to give this a shot :) 

 

The tuning generation being involved, this issue actually became incredibly bothersome, so I had to do something about it in the driver code.

I gave an attempt to at least mitigate it as much as possible, so now the worst that would now happen is simply a High B-/Low C- note that may be a little off-tune, instead of playing dog whistle sounds!

While this was specifically obvious for the low range, overflowing from 00's to higher will not be accounted, simply because the tuning gets so ugly up there, there's no point to doing that.

I could be wrong about the last statement, however! :D 

 

So anyway, I have done some progress in that regard, and while I am well aware my current patch around the issue isn't very good at all, it did give a good enough indication about why it happened in the first place, and I was able to prove it was possible to fix it for a bit, thankfully!

That makes using Vibrato+CMD+anything detuning a note to NOT go beyond its lowest possible pitch, which currently has been worked around by using the last "valid" frequency offset before overflowing.

It's essentially just a couple of instructions (and frankly the code I did there is definitely not very good so it could be a lot better!), but it provides some extra checks around things, and that incidentally prevents having high pitched wrong notes coming at the worst moment!

 

With the AUTOFILTER, I got a little bit more creative.

What I did was to process the same addition operation as before, BUT with the bits of extra verification I copied from the code I described above.

Then I figured, all I can do is to simply offset the pitch in the reverse direction using a subtraction instead, whenever an overflow occurred!

That's an incredibly dumb approach, but this actually worked a lot better than I expected, so that's a nice one for me I think :D 

At the end the pulses would sound nearly identical as the opposite offset, but become upside down, which may still be nice to use I think.

 

There is 1 last thing I have then noticed, but have yet to fix in hopefully a similar way: It turns out the Portamento code has a few things that could indeed get from this to fix a few issues.

But what really surprised me is the lack of CMD2 support in the frequency generation!

I am really surprised I have not realised it before!

That means when we noticed something was wrong about using the combination of both, it *really* was broken, after all!

And just like the Vibrato issues, the exact same fix could also be applied, so this is yet another small but significant improvements done on this.

 

There is also another important issue that has bothered me when Portamento: Initialising a tune where the first note *is* using the portamento would *always* pitch down from #$00!

This one, also, is a mind blowing one to me, but I hope I can find a simple method to work around it.

I imagine I could there is a way to initialise the player like normal, BUT in case the Portamento feature is also built in the driver binary, to make sure the very first note either do not apply Portamento at all, or set the frequency being pitched from to be the same that is also in memory.

But I have not yet thought about the solution about it in much details since, well, it's easy to NOT use the Portamento at the first note anyway.

 

Anyway, rambles aside, a video example of what I am talking about would make a lot more sense, so here is it, I also tested some more things like SAP-R dumper, enjoy the experiment!:

 

Unfortunately, here comes the bad news related to what I wrote above: while this *does* effectively help solving some issues, this also breaks a bunch of things as well!

For example, pitching from #$FF to #$00 or from #$00 to #$FF in 1 should would not work properly because of the very thing I did!

Fortunately, it's only specifically going from the Negative range (#$FF to #$7F) to the lowest that is caught by my "overflow prevention", so if the notes are pitched at the highest range, like #$00, and overflow to #$FF, and then go up, or start from 0 and go down all the way to #$FF, there will be no problem since again I had specifically targeted the overflow *from* the low #$Fx range, not the opposite!

 

That's the part I am currently conflicted about, and I hate this! lol

 

Should I keep the vibrato/detune fixes,, or should I avoid breaking compatibility?

What do you guys think about it?

 

In any case, there's good chances for a new test version to be released soon, if everything goes well!

Stay tune for more progress report later :) 

  • Like 5

Share this post


Link to post
Share on other sites

Employ what makes the best music as whole. Whichever method gets the larger portion correct as well as direct should be the main inline code, the prevention code should be for the smaller of the portions as that will help keep speed and efficiency up.

Edited by _The Doctor__
  • Like 2

Share this post


Link to post
Share on other sites

Hello Vin

 

18 hours ago, VinsCool said:

Should I keep the vibrato/detune fixes,, or should I avoid breaking compatibility?

What do you guys think about it?

 

As usual, I don't understand (at least) half of what you are saying, but... since you know exactly when it happens, can't you just find a way to only fix when fixing doesn't cause trouble?

 

Sincerely

 

Mathy

 

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, Mathy said:

As usual, I don't understand (at least) half of what you are saying, but... since you know exactly when it happens, can't you just find a way to only fix when fixing doesn't cause trouble?

Hi there, you are right, that is precisely what I am doing right now.

I do as much as I could to apply improvements, while also avoiding breaking other things in the process.

 

I can find some compromise acceptable, but I want to not cause too much incompatibility either. I would keep it as minimal as possible, obviously.

I found some of the things I did were also not quite correct  bit later after that long post, so I will eventually find a solution, one way or another, I hope :) 

  • Like 1

Share this post


Link to post
Share on other sites

Done some more progress this evening on the Raster Music Tracker SAP-R dumper :) 

 

 

I got the dumper code to work from any play position now, only the Selection Block play mode is not yet fixed (to detect when to actually stop lol).
So, dumping subtunes is just as easy now.

 

In summary:
- Full song playback - Done
- Pattern loop playback - Done
- Playback from anywhere (and detect when a loop point is encountered) - Done
- Selection Block playback - Partially functional, loop point not detected, but it does work otherwise.

 

Not bad for a single evening.  
I know why the last one fails anyway: I coded the detection at a song line level, but since I never cross any in a selection, it simply assumes it runs infinitely lol

 

I also fixed a off-by-one error in my (pattern) loop point detection, making it to miss 1 frame in the looped recording, a not very obvious one but I could totally notice it, using data comparison to prove I did not imagine things.

 

That's all I have to show today, I hope I can get more done soon!

 

Oh yeah, I also finished the Tuning Dialog Box code now!

All of its parts are functional, including the buttons Test, Reset, as well as Cancel, the last 2 simply revert the parameters to the ones used before opening the Dialog Box.

I did not think it was worth demonstrating this time, since it's pretty much self explanatory :D 

  • Like 5

Share this post


Link to post
Share on other sites

I have a general question about RMT.

Are there any instructions/tutorials on how to use it? Looking for general info on how to copy parts from one song to another?

Share this post


Link to post
Share on other sites
9 hours ago, RetroCoder said:

I have a general question about RMT.

Are there any instructions/tutorials on how to use it? Looking for general info on how to copy parts from one song to another?

Rmt128.zip contains docs/rmt_en.htm

 

Share this post


Link to post
Share on other sites

I also have an updated version of that manual in my latest unofficial version.

 

Truth to be told, I will need help someday to make a more indepth tutorial, because unless most people are already familiar with music trackers such as Famitracker, it's a pretty steep learning curve to figure out how to use this tracker, and i have not found the motivation to write a tutorial, since I am also working on many things that depend on many variables that aren't definitive for now.

Share this post


Link to post
Share on other sites

Well, this took me a lot of work, but I finally have got the LZSS compression algorithm to work directly from RMT, making use of my SAP-R dumps!

As shown in the screenshot, the reference output from RMT2LZSS and the one I got from RMT are a perfect match!

I also have got the SAP-R recorder code quite robust, it is perfectly capable of dumping full song, split intro+looped parts, dump patterns individually, and even Selection Block length if wanted!

The registers dump, combined to the newly added LZSS output from them, will become incredibly useful soon, I hope :) 

 

1650186650921-png.306518

  • Like 5
  • Thanks 2

Share this post


Link to post
Share on other sites

Generated from RMT using only the data it had produced itself, and a hacked version of my crappy music player that integrated rensoupp's unrolled LZSS driver + some modifications I added for timing and cosmetic purposes.

Press spacebar and enjoy.

Also, works perfectly fine in NTSC too.

Looping is also supported, but I have not finished the exporter code, it was a memory addresses nightmare.

Assembling with MADS (and the hacked XASM data slapped together because syntax reasons) with 2 .lzss files or more (!) does work perfectly fine otherwise.

Now excuse me I think I forgot to cancel the Canadian-Dutch resistance movement or something like that

VUPlayer_LZSS_Export_Test.xex

  • Like 3

Share this post


Link to post
Share on other sites

Sorry for potato quality (thanks youtube) but here's a testrun of my full SAP-R to LZSS to XEX binary driver, all of which has been running great through the whole time!

So finally, it has been done!

a functional, LZSS export straight from RMT itself!

And the most amazing thing about that? despite being such a primitive implementation, it works incredibly well already!

I am really proud of myself, and even more excited for more later! 

Stay tuned for more sleep deprivation rambles later! :D 

  • Like 9
  • Thanks 1

Share this post


Link to post
Share on other sites

Please, don't forget us coders, we want to be able to play back the music in our own pieces of code.

Stand alone xex is good for musicians, who want to present their tunes fast and easy, but coders need pure data plus some playback routines in addition, if not already there. 

  • Like 5

Share this post


Link to post
Share on other sites
1 hour ago, pps said:

Please, don't forget us coders, we want to be able to play back the music in our own pieces of code.

Stand alone xex is good for musicians, who want to present their tunes fast and easy, but coders need pure data plus some playback routines in addition, if not already there. 

yes, in Agenda group we are exactly now having discussion - "great improvements, but how can we use it in our game or demo?". Is that the player to be used? https://github.com/dmsc/lzss-sap/tree/main/asm

  • Like 3

Share this post


Link to post
Share on other sites
1 hour ago, ilmenit said:

yes, in Agenda group we are exactly now having discussion - "great improvements, but how can we use it in our game or demo?". Is that the player to be used? https://github.com/dmsc/lzss-sap/tree/main/asm

same here in our group. we stick to original version because cant use it. please provide stuff so we can use music from new RMT;)

  • Like 5

Share this post


Link to post
Share on other sites
2 hours ago, ilmenit said:

yes, in Agenda group we are exactly now having discussion - "great improvements, but how can we use it in our game or demo?". Is that the player to be used? https://github.com/dmsc/lzss-sap/tree/main/asm

I have some working code for replaying 50 Hz LZSS tunes correct even on 60 Hz machines and the optional dual POKEY output.

I have created a song in RMT 1.32, converted it to LZSS with RMT2LZSS (with setting '1.28 custom tables'), then used the .lz16 file with my adapted lzss player code.

 

Code is here: rmt2lzss_new.zip

But beware it is a very dirty hack - but it works for me.

 

EDIT: And be aware that 1.28 patched version might not have all of the new features inside, but as far as I understood the most of actually public available new things are there.

EDIT II: my source is for MADS

EDIT III: I put the files on my github space: rmt2lzss_new + I added the atari.hea as appendix here: atari.hea

Edited by pps
added some words + things
  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

You know you've reached the level needed when the masses are clamoring to use it, perhaps it's time to use this particular point in the development to clean it up and make it a formal revision, getting together with coders to mold things a bit, making it more easily deploy-able in games/demos/applications.

 

This can be difficult, and you may be hit with certain requirements from this or that, but it is necessary for the project to reach ultimate success. Waiting to do this later may be harder than a person could bear to handle at that later time.

 

Congratulations on this milestone and the successful achievements!

You knew it was coming, and it has! Awesome.

Edited by _The Doctor__
  • Like 3
  • Thanks 1

Share this post


Link to post
Share on other sites

Hey guys, thanks for the support!

 

So right now I do have pretty much everything I want in functional state, and I will release a new version soon, with all of the features I have been working on lately.

 

Currently, I am facing several issues that have made me reluctant to post a new version:

 

- Licensing limbo

As you may know, currently I do not have the permission to share the RMT sources, and on top of that, I have modified the Altirra plugins source code to make them work even better with my RMT fork.

As such, I am not fully certain of how I can distribute anything while also not breaking any legal and/or moral condition involving my work.

I have contacted Phaeron regarding the plugins situation, and for now I think it will be alright to share my modified version as an exceptional conpromise, so I am not too worried about this right now.

 

- 6502 RMT driver is not optimal currently with all the changes I did in the driver

However, with the introduction of the SAP-R and LZSS export code, this may not be a problem anymore for immediate use :D

This now leads me to the next point.

 

- My version of rensoupp's unrolled LZSS driver is currently a massive hackjob I made to slap my VUPlayer code on top of it

I have planned to fix that later to make the sources fit together properly.

The driver is written in MADS Assembler syntax, whereas my player was written in XASM syntax, and was designed around the RMT driver, specifically.

This shouldn't be too hard to re-organise, thankfully, it's just a matter of adjusting my code + adjusting his modified driver routines that I have also modified to make it compatible with the RMT timing for my own player interface.

My plan here is to just clean up my player routines code merged into his modified driver to then become fully functional in stand alone code that would call it, and this won't be too difficult, thankfully :)

 

- The SAP-R and LZSS code is very primitive, and doesn't even have a proper dialog/class for it yet

But I have a bunch of functions that I was able to build and call with some hotkeys and hardcoded parameters, which I think will be acceptable to leave as is for the next RMT version, as it is intended to be for testing purpose currently.

In an ulterior revision, I will clean that code up to make a proper menu/dialog for all of that stuff ;)

I also have to give thanks to DMSC for the LZSS-SAP code I have been borrowing for my own implementation of the LZ16 compression straight from RMT, so I hope this is okay since, again, i cannot share the actual RMT sources if I am required to...

 

 

So, in short, I have everything I want in a functional state, and I am really close to release a new RMT version, once I manage to improve the 6502 driver a little more, and also cleanup the LZSS driver code I made use of to also let programmers be able to use the new features as well :)

I hope this clarifies a bit what is the current situation.

 

I am really excited to share everything I have been working on soon.

It was a lot of work, so much I quite literally spent all my free time from the last few weeks just to work on add all these cool features, that I hope you will find interesting to try out! 😺

 

  • Like 6

Share this post


Link to post
Share on other sites
On 4/19/2022 at 4:01 PM, pps said:

I have some working code for replaying 50 Hz LZSS tunes correct even on 60 Hz machines and the optional dual POKEY output.

I have created a song in RMT 1.32, converted it to LZSS with RMT2LZSS (with setting '1.28 custom tables'), then used the .lz16 file with my adapted lzss player code.

 

Code is here: rmt2lzss_new.zip

But beware it is a very dirty hack - but it works for me.

 

EDIT: And be aware that 1.28 patched version might not have all of the new features inside, but as far as I understood the most of actually public available new things are there.

EDIT II: my source is for MADS

EDIT III: I put the files on my github space: rmt2lzss_new + I added the atari.hea as appendix here: atari.hea

Thanks of @Heaven/TQA I fount a little error in this code. STEREO detection is wrong if you forget to stop all interrupts before calling init_song. So better adapt the code:

	sei
	jsr init_song
	cli

Sorry for the mistake, I had the routine working in my 80s intro for NYD and there all interrupts are set off way before the init_song, so I forgot about this here :(

  • Like 2

Share this post


Link to post
Share on other sites

Raster Music Tracker 1.33.00 BETA:


rmt133.00BETA.zip

 

- Added tuning calculations dialog, ALL known POKEY modes that was programmed to use a lookup table in the driver code will be generated on the fly, automatically!
Exception for the Sawtooth tables, it will not be generated due to not having figured out an optimal way to compute it yet.


- Added SAP-R Dumper, LZSS Compression, and new Export format: XEX-LZSS
VUPlayer coded by myself, now powered by rensoupp's unrolled LZSS driver! LZSS compression code by DMSC, which I have ported to C++ for use within RMT itself!


- Fixed several memory leaks, and fixed several bugs related to the UI and scaling


- General performance improvements, related to improved plugins communication, faster and better Tuning calculations, and improved bitmap usage for Registers View code


- Tweaked plugins communication, fixing Stereo detection, PAL/NTSC detection and making the timing hopefully more stable and accurate
Note that for the plugins improvements, I modified the Altirra plugins to make them work properly after my changes in the RMT code.
This also means the older sa_pokey.dll and apokeysnd.dll plugins won't work properly unless they also get updated accordingly.


- Many 6502 driver changes, fixing 16-bit generation, changed the way AUTOFILTER behaves, and attempted to fix several issues such as the vibrato underflow bug.
The driver changes be for the best, or may be not! Feel free to try and see what was potentially broken in the process!
I am aware some of the Portamento/Vibrato changes I did were not bugfree, and I apologise for that, this will be fixed another time.
Most tunes should work properly, otherwise.


- Temporary disabled SAP/XEX export
Since I am in the middle of the exporter code rewrite, and it's been a huge task so far, I haven't finished fixing it, but I know people wanted a new RMT version for a long time now.
So I decided to not take the risk and make sure the feature was temporarily taken away, but don't worry, the LZSS exporter is currently a much better option to use ;)

 

---

 

That being said, this is a BETA version, so it's very likely I broke more things and did not realise it. Please tell me if anything is wrong!

 

---

 

How to use the SAP-R/LZSS exporter from RMT's main screen:

CTRL+F5 -> Play Song from Start, loop point automatically detected
CTRL+F6 -> Play Current Pattern (Loop)
CTRL+SHIFT+F6 -> Play Selection (Loop)
CTRL+F7 -> Play from cursor position, loop point automatically detected
ESC -> Aborts the SAP-R dump if pressed during the process

 

--- 

 

How to use the Tuning dialog:

Simply edit the base frequency, base key, and chose the tuning temperament if desired!
You can also edit the Ratio tuning values, if you feel adventurous.
Note that a few of the temperaments are non-12 notes octaves tuning, and are a bit weird to use, but they do work, as far as I could tell.

Feel free to experiment! I have worked incredibly hard to make this feature alone!

 

---

 

You can find the current progress on my patched RMT driver here: https://github.com/VinsCool/RMT-Patch16
And the VUPlayerLZSS progress here: https://github.com/VinsCool/VUPlayer-LZSS

 

Other than that, RMT should behave pretty much like it was since the last "official unofficial" version 1.32.06 :)
Enjoy!

 

~Vin 💜

 

---

 

[warning: what follows below is a half-rant, half-ramble, I apologise if any of this doesn't make any sense, and I hope I am not shooting in the foot by posting that]

 

I want to stress that this is an unfinished release, and the only reason I posted it now was because I am currently feeling burned out with this stuff, and I really need a break from (poorly) coding.

 

The reason I added all the LZSS export stuff so early was simply because I was recently asked for making the music for a game (which I will focus on for the next few days/week).

For that game, as soon as I heard the mention of LZSS, more specifically RMT2LZSS, I got PTSD from Prince of Persia, Tuning Tables and RMT2LZSS's ease to use, especially.
No joke, my reaction was something that sounded like "fuck this shit, I'll first add LZSS export DIRECTLY from RMT, then I will make the music knowing I will HEAR and GET exactly what I EXPECT from the CONVERSION.", except I was screeching incoherently, then I took the next few weeks to work on all that stuff because I refused to experience another Prince of Persia.


It really was a pain in the ass to get most things to work, so far, in fact it's still incomplete, but it's now good enough for a BETA version! :D 

On top of that, I was really unsatisfied by the lack of features the 6502 LZSS drivers offered, so I spent a lot more of my time to try to work around that, and thus VUPlayerLZSS was born!

This newer version was made specifically for allowing a handful of extra features, such as subtunes index, looping, fadeout, and basic music player subroutines, which I also tried to split for easily allow developers to use my version of the driver/player combo into their projects as well.

The newer VUPlayer was essentially made out of spite, too, because I was still upset about being told I was not able to do things myself, or was flat out told certain LZSS driver features were not possible, apparently.

 

--- 

 

I also want to clarify why I took so long before posting a new version:

 

I was basically stuck in a licensing purgatory, because as you know, I do not have the permission to share the RMT sources despite the huge amount of changes I have done inside of it, and I also needed to change the way plugins communicated with RMT's code, which also was a can of worm, due to the way the Altirra license worked in this case specifically.

And let's not forget I also am powerless if I ever needed to borrow any code from something else, and could not share it, especially!

 

Thankfully, I was able to ask @phaeron for more details about this, and this was thankfully solved with an exception for allowing the use plugins and emulation code without any legal risk (as far as I understand, I think what I just posted above, bundled with the plugins I modified is now okay), Phaeron if you read this message please confirm I have the permission to share this, and if I also need to share the modified sources I will do immediately, and if I should not post any of this I will immediately take my post down and admit I an an idiot!

 

Also, there was even more stress due to the fact I managed to get the LZSS compression to work by using @dmsc's code, which I ported from C to C++ and incorporated it directly into RMT (I think you guys can see why I was worried, again), but thankfully I think the license actually authorised me to use the code without any worry, so dmsc if you read this post, please confirm I did not do anything illegal, I will eat my socks otherwise!

 

I think that goes without saying, all of this was a bit of a disarray to me, and I was really frustrated about it (still am), but I won't start to rant about this and risk destroying my reputation, especially when I know I am literally a "nobody" around here, it's just not worth it.

I will still respect the wishes and request to not share any sources, if that's what I should do, I must oblige, but I can't say I am not getting more and more anxious about everything related to that.

I still do believe I should not be forced to keep anything I have written from scratch and added, private, so that's the reason why this repository exists in the first place: https://github.com/VinsCool/POKEY-Frequencies-Calculator

It was code I literally have created for RMT, specifically! I know it's shit, but who cares, it does what I want it to do.


---
 

Anyway, as far as the entire journey has come to, I'm glad I finally was able to prove my point!

It was a lot of coffee, sleepless nights, and very frustrating C++/6502 Assembly lessons learned on the field, and I most likely have lost all my sanity (or whatever was left from it), but it absolutely was an amazing journey!

I learned a fuck tonne of new concepts, ideas, and I am now even more motivated to try more ambitious/crazier projects!

 

But! Not before I take a long break from programming, I really want to make the music, for now! 😸

Thank you for reading, and more importantly, thank you all for the support! I hope I won't disappoint you this time!

Also, I want to profusely apologise in advance if I said or did anything wrong! I really am getting heartburns with all of this lately...

 

 

  • Like 8
  • Thanks 5

Share this post


Link to post
Share on other sites
Posted (edited)

Hello Vin

 

18 hours ago, VinsCool said:

... risk destroying my reputation, especially when I know I am literally a "nobody" around here, ...

 

You're far from a nobody here!  Most of us are roughly twice your age.  You didn't even exist when the Atari 8 bit computers were made.  Yet you seem to like our computers at least as much as we do.  You are doing a great job improving RMT.  You are well respected in the Atari 8 bit community for that.  Keep up the good work and stop talking yourself or the work you do down.  You don't have to apologize.  We understand that even VinsCool isn't absolutely perfect and always willing to work and doing that without making mistakes.  I personally hope you will keep working on RMT, but I do understand that you can't do that all the time.  Take time for yourself if you need and/or want that.  I'll personally probably never use RMT, since my talents are clearly not in the field of creating music.  But I know others who are, will.  And they will be able to do so, because of you.  And I will be able to enjoy their work, because you gave them the instrument to do so.

 

Sincerely

 

Mathy

 

Edited by Mathy
  • Like 7
  • Thanks 1

Share this post


Link to post
Share on other sites

@VinsCoolI second Mathy's message. The Atari scene is all the better for your work and dedication and I am sure I speak for many that if you want to continue after a break we'd all welcome it. 😁 No need to apologise for anything. 

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites

Hi!

 

On 5/6/2022 at 1:28 AM, VinsCool said:

Raster Music Tracker 1.33.00 BETA:

Thanks for all your work!

 

On 5/6/2022 at 1:28 AM, VinsCool said:

Also, there was even more stress due to the fact I managed to get the LZSS compression to work by using @dmsc's code, which I ported from C to C++ and incorporated it directly into RMT (I think you guys can see why I was worried, again), but thankfully I think the license actually authorised me to use the code without any worry, so dmsc if you read this post, please confirm I did not do anything illegal, I will eat my socks otherwise!

 

I put the LZSS code under MIT license exactly to allow this kind of use, so it is "good and legal" :) .

 

But I'm a little sad about the state of the RMT code, I feel you are trapped by having given access to that code without permission to release it, as it limits what can you do with it and what others can do yo help with this huge effort. Hope it resolves in the near future, before all of us are dead and Raster is forgotten.

 

On 5/6/2022 at 1:28 AM, VinsCool said:

I think that goes without saying, all of this was a bit of a disarray to me, and I was really frustrated about it (still am), but I won't start to rant about this and risk destroying my reputation, especially when I know I am literally a "nobody" around here, it's just not worth it.

You have my greatest respects, and you are hardly "nobody", yo are one of the recognized names in this little retro-corner of the internet :) 

 

Have Fun!

 

  • Like 5
  • Thanks 1

Share this post


Link to post
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...