VinsCool

That is best visualised when all channels are mixed together, mono output style! In that case, I agree with you

Took me a bit to figure out, but I think I managed to find how to make use of the custom table feature... it was a lot of trial and error but now it worked. I managed to identify what table belongs to what distortion setting, thankfully, and wrote my own comments. It really wasn't the order I was expecting, it's a little messy but at least it works. I only added tuning for $20 and $40, as a test, both require 1.79mhz, but other than that it behaves as expected. Replacing the distortions in the first line also works exactly as expected, I left it unchanged for now. I used the notes from synthpopalooza's tables spreadsheet to get the Distortion 2 and 4 notes for this test. Distortion and Tables Test.obx CustomNoteTables Vin V1.txt Distortion and Tables Test.rmt

I know, this is why I used RMT2LZSS to extract his tune, and be able to run it in Altirra as well It's awesome how it just works, I've used the same method to rip .rmt modules out of executables too, lol But yes, we will see it if it's actually properly emulated/exported? 🤨 That's literally what I explained in my previous message in the thread. "Adding up 2 audio channels and show as 1 due to a rendering error vs show the resulting tone properly in each channel" are 2 entirely different things. The high pass filter modulation is the most obvious in that regard, Pulse width modulation is shown in action instead of showing up 2 channels doing 2 totally different things. The video of Things on a Spring was inaccurately emulated, and actually looked wrong as soon as a note switched down to 16-bit, it made everything following up wrong and copying what the other channels did, visually. Here's an example of inaccurate high pass filter effect visualised in separate channels based on what I explained: It looks like a normal square wave, because when it was exported, all channels are literally disabled, and so anything such as frequencies and AUDCTL bits are omitted, so listening to individual channels will expose everything wrong Here's an example of 16-bit turning the entire visual in channels 2 of each POKEY side wrong in a few parts: The latter, this video, was exactly the same side effect that happened in the visualisation of Things on a Spring, due to the fact that disabling a channel entire really mess up everything depending on the other channels. The best way to counter that is to simply set volume 0 on the channels that should be muted, but allow it to keep doing its thing, which was what I used for my own oscilloscope videos. 😜

I knew the tuning work wasn't a waste of time after all! Gonna be really useful just for that alone. 15khz and 1.79mhz corresponds to the POKEY frequency divider clock, so each modes provide different pitches, and as a result, different tuning. 15khz is much lower, and 1.79mhz is much higher. Something that works for 64khz (the normal mode) may not work for one another, and vice versa. We are lucky to get relatively good consistency with 15khz in the Distortion A, being about 2 octaves (and a bit) lower, because between distortions, modes and other AUDCTL settings (Joined 1+2/2+4, High Pass Filter, Poly9, combinations of several, etc) may not be as nice in that regard. So essentially, a table for nearly every possible combination may be required, it really depends on a lot of things. That could work incredibly well regarding what I just posted above ? I think what emkay means is regarding high pass filter, there is way, way more than "SID-like" sounds that could be done, and so I agree about it, 1 channel being a certain table, as a "Carrier", and the other using a different one, as a "Modulator" could make a LOT of things really easy to do. High pass filter combinations and possible notes is something I have been experimenting a lot with recently, and I plan to properly document one of these days in the future, I can say for sure, there is a LOT of things possible with that alone. So the "fixed" and "editable" statement is regarding the possibility of being able to have custom settings (something I believe was already mentioned in this thread anyway). I think it is regarding how certain modulations require manual instrument envelopes, something that can be done for the most part already, and also have the ability to have specific tables loaded in memory for specific things, for example, 7 semitones apart the 2 channels create some distortion guitar tones at 1 octave lower, and the highest possible frequencies produce something much closer to actual high pass filtering... even I get lost trying to explain any of this, but I believe I understand the reasoning. Could be summarised to: "Power to the user, allow them to have anything editable, and let them make their own tables for their own instrument design!" At least, I hope I understand correctly, lol You mentioned that already... no idea what you mean... you'd to find a different way to explain it Seems like something such as effect commands in tracker patterns could handle incredibly well. For example, Famitracker uses the command Pxx (xx being the value of fine tune up or down) for that exact purpose, making all the fine tuning a simple command instead of several instruments edited for that purpose, even if they are used only once. Honestly, effect commands alone could add a LOT of possibilities without requiring to bloat the instrument editor with hacked up instrument design to get shit working at all (and this is where I sit currently with my RMT usage LOL) This post pretty much says what I meant in the reply above, that is also something most tracker programs usually support by design. Some even support several commands at once, Famitracker, Deflemask, LSDJ to name a few.

Ohh right, I understand now! That should be pretty easy to do, a short demo using as many combinations as possible, of course, I'm dumb lol That alone could make a lot of things faster for the statement above! haha Thank you very much for implementing the idea, it might not be the ideal solution, but a patient musician won't have problems exporting files often to hear their sounds as the song progresses. Yes, Distortion is pretty much already doing it, and with the new RMT2LZSS features that would turn this into something a lot better as well. AUDCTL changes in the instrument envelope would be the only thing missing now. Having extra parameters would be exactly what we need to improve a lot of things, but then it will make most things incompatible with RMT as a result. So a format based on RMT, but improved in a potential new editor could turn a lot of annoying things into something relatively easy for the musician. Even better, if a future format actually sees the light of existence, and was based on the RMT format, that could also make features such as "import RMT" something nearly painless to implement, only what was not supported would be missing since it wasn't used in the first place.

Awesome! Let's see how I could make use of this new feature soon 👀

I had a lucky guess... for some reason Altirra refused to run your SAP files from the ASMA archive, but there was actually a RMT header inside, so I was able to convert it with RMT2LZSS to see it in action. I was correct, there was inaccurate emulation, there are some notes that switched to 16 bit mode, and it looks like ASAP doesn't like it, because now all channels looked correct in Altirra. Just for fun it uses my Alternate Tuning too... Sounds pretty good to me! Thing_on_a_Spring.xex

This is true, especially with inaccurate emulation, or changing the content of the channel, instead of the volume. Disabling a channel entirely creates a lot of weird effects with the ASAP sound emulation. Altirra gets it right when it mutes channels to isolate the resulting waveforms, and the same also works with the RMT2LZSS volume offset changes, or manually editing a RMT to force the content of a channel to output volume 0 while keeping the frequency. It also obviously works as expected on real hardware, very easy to see in the Amberstar cover, the Pulses are modulated exactly as expected. This is simply wrong... That's not how it should look like. It's like 2 channels were mixed into 1, then output in a different channel. That's inaccurate emulation for sure.

I pretty much record the tune in 5 passes, from 5 different executables, then assemble the oscilloscope video from them. RMT2LZSS makes it incredibly easy since I can use the volume offset setting and mute channels by setting negative 15 on them, so I make 4 different files using that method, 1 per audio channel, then record the full version as well as the master audio file. Then i record the sound from my Atari, and assemble the files using Audacity to splice and amplify the sound, and make everything synced up for the visual part. It's slow but incredibly satisfying to get authentic hardware recording in action

It always happens in this thread for some reason, lol I hope I didn't break the site

It always happens in this thread for some reason, lol I hope I didn't break the site

Recorded from my PAL 800xl Sounds great [PAL] Emkay - Dachlatte (Hardware).ogg

Recorded from my PAL 800xl Sounds great [PAL] Emkay - Dachlatte (Hardware).ogg

Sure, I'll just need executable for that.

Oscilloscope video is up now! Amberstar - Ode to Schnism (Atari PoKEY Cover, Recorded from Real Hardware, Alternate Tuning)

Thank you! Nice tune, I don't see why it couldn't work, seems very much in the range of POKEY capability to sound nice. Speaking of which, while the oscilloscope video is rendering, here's the real hardware recording of the Amberstar tune! I recorded it from my PAL 800xl Might just upload the video tomorrow, it's pretty late already lol Amberstar - Ode to Schnism Alternate Tuning.ogg

Yep, I agree with that Raster really did a good job, it's just a bit disappointing how limiting some things were implemented, because the POKEY chip can produce some really amazing sounds. Not lying here, when I did not understand the chip as much I can today, I thought many things were much more limited due to the way RMT was handling them. I assumed high pass filter muted the modulator channel, same with 16-bit, or that the notes available were the only ones possible (and I think I was able to prove there was way more possibilities using custom tuning tables!). So once I could actually know the secrets of the chip, I was pretty much facing a wall of hard coded limitations, that could be worked around manually using AUDCTL settings in instruments and manually playing the frequencies needed using commands 1 and 2, for example, or relying on Speed 1 patterns (Famitracker style!), Or custom tables, as shown by Analmux in RMT patch8, or even my own for tuning purposes, which was only intended as a personal use first but now I think there may be more stuff that could benefit from that, etc having a new tracker which handle do everything RMT could do, but better, with LZSS, means we could do nearly anything, and hopefully having more control over the sounds would make certain things much easier as well, despite being a lot more complex on the get go. note tables for example, are not an exaggeration for that alone, having support for more than 3 hardcoded tables would unlock a lot more power without relying on manually making instruments for 1 specific frequency, and would also avoid having to resort on using hacked versions as well. so if instruments could also change more things on the fly, such as distortion, or AUDCTL alone, plus having support for custom tables, would mean quite a lot of things could be done, and once the hard work is done once for a certain thing (eg, a table of notes for a special setting), that makes things much easier to do once they are available. POKEY Explorer has been incredibly useful for these experiments, so having a tracker that could let the user do nearly the same amount of stuff on the fly to make an instrument could make a huge step forward in creating really impossible sounding POKEY music, I believe

RMT currently only has 3 tables, and 1 16-bit table. The 3 main tables are Pure tone, used for 0, 2, 4, 8 and A (which is very much incorrect, since they all need their own tuning to even work nicely), and 2 bass tables, these 2 are only used for Distortion C and "E" setting (E in reality is simply C with different tones on certain frequencies), Bass Table 1 is also used in "Distortion 6", the 16-bit bass setting, as a fallback when used on a unsupported channel. 16-bit is made of 1 high order byte table, and 1 low order byte table, one in each channel used for it. The tone is very much what "Distortion E" sounds like, but in reality way more 16-bit settings could be done, and they also need their own tables. More than that, actually, 15khz, high pass filter modulation (not just SID-like sound, but many combinations!), and different combinations of several settings, AUDCTL bits, and most likely more, they really do need their own tables to get some very solid tones and notes being in-tune together. I like to call all that high pass filter stuff "cheap FM" for the same reason, lol And you lost me here, lol

Hardware recording coming a bit later I really like how this cover turned into now. Amberstar - Ode to Schnism Alternate Tuning Final.rmt Amberstar - Ode to Schnism Alternate Tuning Final.xex

Yeah, that's what I'm saying, same for any other mode and combination. The only way to get certain things to work is either rely on the hardcoded method provided by RMT (which is pretty much very limited, but "just works", or manually... by creating a new instrument for every setting, and manually chose the frequency if it needs to be adjusted. In what way exactly, however?

Thanks! I appreciate the offer but I got all my hardware needs covered now I was lucky enough to get a 800xl of each region, so no issue there! Hardware will come sometime soon... maybe tonight? 👀 I'm so happy this tuning adventure really paid off after all, I really thought I was wasting my time... I'm glad I was too stubborn to give up just yet! Honestly the Distortion C frequencies (any timbre minus the unstable/muting ones) are about as good as I could get them... There are a few notes that turned out to be debatable... and happen to be directly related to the A ones I was hesitating with, but overall, I'd say about 90% of them are nicely in-tune with a relatively consistent amount of cents off... which is honestly a lot better compared to how the notes were originally. Hopefully, my efforts may be useful for later projects :3

Played a little bit in a cover of a tune I really like, and I combined some ideas emkay added some time ago with some tiny improvement I did today I think it wouldn't take much more to call it done, and replace the original version I did, that isn't as good anymore, now used the custom tuning tables btw Amberstar - Ode to Schnismmk VinEDIT12.rmt Amberstar - Ode to Schnismmk VinEDIT12.obx

I like this version better personally. It sounds a lot more pleasant.

Are you sure about that? I've tested about as many tunes I as I could and everything sounded exactly like intended, in both region. This is the only reason why something would run at a different speed on some tunes. If a tune was made with NTSC in mind, but runs in the tracker in PAL, it will indeed play slower, and the opposite is also true.

By the way if anyone is interested, here's my own edited version of RMT, using the Alternate Tuning tables I posted in this thread. Rmt Vin Tuning Patch V9.exe I also edited RMT2LZSS the same way, it actually was how I was able to test most of my tunes en masse easily, otherwise it would have taken at least 3 eternity to even get something lol It replaced the table for RMT 1.28, the other ones were not touched. RMT2LZSS Vin Tuning Patch A and C and E V9.exe I hope you are okay with that rensoup? 😶 If there's anything I shouldn't have posted I'll delete upon request. There is 1 particular change in the Bass 1 table however, in order to get proper notes below G#1, it uses the "Distortion E" bass timbre for those notes. This is only a personal preference, but otherwise everything should be virtually compatible with tunes made in 1.28(1.30). Hopefully I did not break as many things as I tried to improve a bit