rensoup

In somewhat related news I've taken a look at Fox's ASAP library (its pokey core is used in RMT as well). It use its own variation of the C language which can be translated into C# (or C++, Java,...). So I was able to plug the ASAP Pokey core in into RMT2LZSS and turn a RMT tune into a WAV without the need of a 6502 emulator (C# RMT player raw data directly fed into C# Pokey emulation). That means the 6502 player is gone! https://sourceforge.net/projects/asap/ http://cito.sourceforge.net

🤨 Can you clarify that a little? I've hardly ever used RMT 😀. If you have a 8 bit instrument, do you switch to 16bit manually with AUDCTL ? wouldn't it sound completely different ? Any chance of making a very simple test which would demonstrate the various AUDCTL modes?

That's almost criminal... time to put some anti-hacking measures in... just kidding of course 😄 Wow... great sounds!

@NRV mentioned a bunch of things a while back 1 I'm really not a RMT user so that could be a dumb question but I guess you can't play a single instrument without writing it to the pattern ? 2 That could in the future as for now LZSS is the job 3 That's been mentioned a few times, and Analmux did a bunch of patches which involved mostly table hacking. And so has @VinsCool. So that'd be a really useful feature I guess? With LZSS and a new tracker it would be a pretty easy feature to add. 6 can anyone explain this ?

What kind of sampling rate would work though ? the idea with LZSS would be to able to go above 200hz (on all 4 channels), 400 and perhaps 800 but it's not really possible to go beyond that unless you have 3 channels at 50hz and the 4th one at higher frequencies. Now's the time to mention the "other" missing stuff again!

Also, what are new effects people are interested in ?

Several people have mentioned that RMT isn't the panacea anymore... so perhaps it is time to start discussing how to move beyond RMT. So I'm creating this thread because nobody else is willing to (Doesn't necessarily mean I want to get involved into any kind of coding!) One thing that is critical I think is to use Dmsc's LZSS player, as I mentioned many times, its main advantage is its speed no matter how complex the sound effects are. Its second advantage is that it already exists and doesn't require upgrading if new sound effects are implemented (because it just replays raw Pokey data). Possibilites from a tech POV: 1.Upgrade RMT ? It is a possibility, even though Raster's not with us anymore, some people seem have to have the source code. ( The source code for one the very first releases is actually available from Raster's homepage: http://raster.infos.cz/atari/rmt/rmt.htm : 2003/01: RMT 1.01 beta - rmt101b.zip (105 kb), rmt101b_src.zip (170 kb)) The PC tracker is written in C++ but the sound is actually played with the 6502 ASM player through emulation of the 6502 and Pokey which means implementing new effects require modifying the 6502 player which would bloat it/slow it down, not exactly ideal since it is also used on the A8. Since I have a compatible player (RMT2LZSS) written in C#, it could be possible to remove the 6502 emulation from RMT, replace it with the C# player and leave the Pokey emulation to be able to still play the tunes inside the tracker. The tunes could then be exported to LZSS for playback on the A8. It should then be possible to easily add new sound effects to the C# player. 2.Start from an existing tracker ? This means getting a functional UI but non working player. The player and all its effects would have to be adapted for Pokey. Is there a tracker for a different platform that has enough bits in common with Pokey? I like https://famistudio.org because its interface seems really user friendly and if you watch the demo video, it seems pretty easy to create tunes with it. 3.Start from scratch ? A mammoth task... A slightly different proposition would be to reset RMT by just starting from the C# player and rebuilding a new UI around it. And using Fox's ASAP, the Pokey emulator that's powering RMT. 4.Update RMT with patches ? That's a dead end since adding a feature means removing another one. What's needed is a tracker than handles all the patches at once (and more). To reiterate, this doesn't mean I want to get involved in the coding or implement every feature request that may pop up but at least let's get the ball rolling!

That would be another patch and a pretty complex one too... modifying the RMT code (beyond replacing tables) isn't a good idea for all the reasons mentioned previously. Don't want to prevent anybody from trying of course, I just think it'd be a wasted effort.

All that music theory is flying way over my head 🙂 I tried those latest tunes and while they sound good I didn't notice any difference (but I'm not very familiar with them) So I checked aurora and SAPRed both the original and your version, and while there lots of differences, all the values vary by a single unit, surely that can't have a big impact ? I'm curious if you may have been wandering for too long and gone back to your starting point 😶 ?

Time to start a new thread regarding a new tracker 😏

https://famistudio.org/ seems nice too 🤪 I don't know if converting a tracker for a different machine is doable but It wonder how fast it would be compared to rebuilding something around RMT in C#. In the end it's all about being able to modify frequencies and volumes in various ways I guess ?

That's what I said, just not in so many words 🙂 Why would you want to do RMT C# player->LZSS then UnLZSS-> Pokey when you can do RMT C# -> Pokey... a Pokey.dll would be more useful 😉 Of course... nobody's working on that though 😏 I did, thanks 👍

Some real nice sounding tunes! I can't say I hear much difference between your updated frequency table and the regular one, at least not with Ivop's noisy pillars (still using shitty headphones/speaker though) 😶

http://raster.infos.cz/atari/rmt/rmt.htm 2009/05: RMT 1.28 2003/01: RMT 1.00 beta About 6 years then... Not quite of course... When did RMT become functional ? After 1 year ? 2 years ? The problem is the 6502 RMT player is the core and it's hardest part to update because of memory/speed restrictions. It's the same issue with any retro tracker I guess but even a PC only tracker takes a while to develop. It's always possible to get something working in a few weeks but for it to be usable/stable and become a standard, it would take a lot longer.

Piece of cake, no source needed... Well, I'm not sure what it all means 😎 but obviously you wouldn't want to upgrade the 6502 RMT player because any change to that is perilous... but it's probably easier to change my C# RMT player.

double post??? @VinsCool you really broke AA with that post, it won't even let me like it 😀

Sure I'd like to meet some hardcore Atari users! I already considered coming in 2019. I don't know if it'll be possible though... Regarding the RMT source, is that real or just wishful thinking ? I wouldn't want to use it personally because LZSS is the future... but I'm curious

It's because LZSS is included, and dmsc released it under the MIT license... Code's not available but perhaps in the future... The C# RMT player started pretty much as 6502 assembly looking C# code ( with stuff such as m_regA = GetMemory(offset) ) and while I've cleaned it up a lot it still has parts where it accesses the 6502 memory at runtime (instead of just during init), for setting up instruments and getting tracklines mostly. I used 2 textfiles which contained reversee engineered info about the RMT format, one of them from 2012 by a certain Ivop dude 😀... can't believe you did that and then... nothing with it ! Now if you were going to rip out Altirra Pokey, perhaps I could let you have a peek 😎

The proof's in the pudding and you've produced quite a bit of tasty pudding lately 😃 so it's good to hear where improvements are required and possibly figure out a way of implementing them...

Well I was told it was to prevent a bunch of incompatible versions from popping up... Like I've said before: Good job on that front because we now have a bunch of patched versions which aren't compatible... The only reason we don't have more is because Analmux passed away as well 😑 I'm not sure LZSS is snappy enough for that... I'm thinking that my C# rmt player/converter could be turned into an actual native PC rmt player with the help of Pokey.dll, or even better Altirra's pokey emulation... Didn't you mention you wanted to rip out Pokey out of Altirra 😀? Then bolt on instrument editing features which aren't available in RMT and that player becomes the new RMT play command 😎 yeah that sounds like a dead end 😏 (you still need to be able to edit those extra parameters from the editor) The problem is between RMT or an exported player.xex and RMT2LZSS ( which has all features enabled too). Supposedly RMT2LZSS produces more stable sounds 🤔

Great sounds! (but somewhat out of tune ?)

it's just 64(62?) bytes per table (because that's the 3 octaves supported by pokey, right ? ). RMT 1.28 patch 8 has more but shorter tables in the same space... it's not massive but it adds up. I'm going to guess Raster did those things to save some space, because a lot of the design seems to be geared towards that (the rmt_feat.a65 file being a good clue, where every player feature not used for a particular tune can be turned off to save some bytes). The more features you add, the messier it gets though... Fiddling with the player is a dead end because you'll always have to balance between features and speed+space. Doing that -without- the tracker source is probably 🤪. With the tracker source it's possible to just give up on space saving and have shitloads of tables (at the risk of not being able to load the tune though) then rely on LZSS. (The better solution being to use LZSS from the beginning of course but that's a bigger project) Hmm... yes 3 tables but I'm not sure what instrument types are. The table above is indexed with the dist parameter from the instrument envelope. The first parameter is the table, the 2nd one value that's fed into AUDC (If I'm reading the source correctly)... so that'd be those 5/17bits polynomials, so I guess those are the instruments type ? Say that loud enough and maybe the guy who's sitting tightly on the source code will hear you 😏. (but again: LZSS rules!)

That I really don't know! I am not too advanced in hacking RMT around in the first place, and really don't want to be for many reasons, however these files will be incredibly useful to have around, so thanks for sharing! This is the RMT player code which is located in the source folder of every RMT release... (I converted it to C# for RMT2LZSS). There's no 'best' version really... 1.28 is the last version, the patched versions are just different. Although adding new tables to the player isn't that difficult, the player is embedded in the RMT editor (I'm 99% sure) and it's quite messy to follow because it is optimized for space (just have a look at rmtplayr.a65 !). So even after modifying the player you'd have to reinject it into RMT, that could be very messy...or not but I'm guessing that since Analmux didn't do it, it's probably the latter. Then you'd have to modify the editor interface to be able to select those tables and pass that back to the player... Without the editor source code, that would probably take a good chunk of time. The editor source code is the minimum requirement for making any significant modification and even then, it's a completely custom GUI 🤢 but seeing that someone other than Raster made v1.30 with the larger editor window, it may not be that bad... (but I don't want to touch C personally...) Perhaps @pseudografx can help ?

Looks like more folks are using LZSS on the A7800 than on the A8... how ironic considering Pokey isn't standard on the A7800 😏

I could make another selectable patch in RMT2LZSS once you have a final version, then you wouldn't need to go through the SAPR malarkey!