rensoup

1.6 is available: -attempt at fixing some VU-meters edge case bugs -can now launch emulator with last output obx -can now redo the same conversion without having to reselect the files -custom instrument files (.erti) @VinsCool I managed to get started with the custom instrument file, it's only the dist setting for now but it means that there's no limit to the number of 8 bit tables anymore! so you can add as many 8 bit tables as you want in the table file and override the envelope dist parameter in the instrument file... It's untested but your example .RMT didn't break! I've also made your table file the default one. Hopefully those new buttons will help with workflow... @emkay it is also possible to customize the initial filterFrequencyShift value... not sure how useful that is but I did it as a test anyway.

I can't remember but I think I may adjust the timing between each Pokey update for NTSC, so there is less time between them, and as I was totally sloppy when implementing the VUmeters, the CPU time it takes has to be less than the time between 2 Pokey updates 😏

yes (I posted it above) // 6 Add $XY value to FILTER_SHFRQ. (Whenever the new note in track is getting started, FILTER_SHFRQ is initialized to $01, so that default join filter generator frequency is higher by 1.) case MRTState.cmd6: { m_songRuntime.CurrentTracksFilter[channelIdx] += envelope.CommandArg; So yes that can be initialized to any value (with the help of that extra file containing extended instrument info)

I see! ...I think? Being able to switch between 8/16bit would give a bigger range of frequencies for a single instrument (at the cost of a channel) Well I don't have a tracker editor sitting in my code library, so we'd have to try with a text file 🤪 There would be a set of 16bit tables just like there is for 8bit tables @VinsCool you mentioned that 8 bit table 6 was actually used even for 16bit... I hadn't realized it before but it seems that when dist 6 is set, the note is processed normally with any effect set (using the 8 bit table) then the resulting note is used to look up the final note into the 16 bit table, I guess that's what you were saying ? I guess that would work the same for all 16 bit tables ? Basically every 8bit table would have a corresponding 16bit table ?

I'm not sure what you mean... this ? m_songRuntime.CurrentTracksFilter[channelIdx] = 1; m_songRuntime.CurrentTracksTablespeeda[channelIdx] = instr.tableSpeed; m_songRuntime.CurrentTracksAudctl[channelIdx] = instr.audctl; m_songRuntime.CurrentTracksEffdelay[channelIdx] = instr.delay; m_songRuntime.CurrentTracksEffvibratoa[channelIdx] = vibtabbeg[instr.vibrato]; m_songRuntime.CurrentTracksVolumeslidevalue[channelIdx] = 0x80; m_songRuntime.CurrentTracksNewInstrIdx[channelIdx] = 0x80; m_songRuntime.CurrentTracksInstrreachend[channelIdx] = 0; m_songRuntime.CurrentTracksShiftfrq[channelIdx] = 0; m_songRuntime.CurrentTracksEnvelopeIdx[channelIdx] = 0; m_songRuntime.CurrentTracksTablea[channelIdx] = 0; m_songRuntime.CurrentTracksTablenote[channelIdx] = instr.noteOrFreqTable[0]; This is what happens when a new track line is read and new instruments are setup... m_songRuntime.CurrentTracksFilter[channelIdx] = 1; You'd want that to be customizable instead of 1 ?

So that currentTracksFilter comes from command 6 // 6 Add $XY value to FILTER_SHFRQ. (Whenever the new note in track is getting started, FILTER_SHFRQ is initialized to $01, so that default join filter generator frequency is higher by 1.) case MRTState.cmd6: { m_songRuntime.CurrentTracksFilter[channelIdx] += envelope.CommandArg; note = m_songRuntime.CurrentTracksNote[channelIdx]; Not sure what it all means though...

Wow... there's a lot to discuss... just going to reply in random order... Nope... There are 2 parts to the source code: -The tracker editor: Raster only published the source code for v1.01. -The player: There's only one player and it's written in 6502 asm. The source is included with every RMT release so that people can play tunes in their own project. The player xex is also included in the tracker editor along with the ASAP player so that the editor can play sound on the PC. What I did is take the player ASM source code and converted it to C# code which means I now have a much more readable version of the player. I can also modify it easily...

Nice! Those sawtooth (teeth?) in the middle of the song sound much better than the squares right after them... and there's no extra cost...

Damn users, always breaking things in unexpected ways 😅 It's just the VUmeter code that isn't fast enough to update at 240Hz, It worked fine at 200Hz but I forgot about NTSC!

I don't know if follow but the only AUDCTL settings that RMT seem to change are if ((m_songRuntime.CurrentTracksEnvelopeCD[0] >= (byte)Envelope.Mask.Filter) && ((m_songRuntime.AudC[0] & 0x0f) != 0)) { m_songRuntime.AudF[2] = (byte)(m_songRuntime.AudF[0] + m_songRuntime.CurrentTracksFilter[0]); if ((m_songRuntime.AudC[2] & 0x10) == 0) m_songRuntime.AudC[2] = 0; tmpAudCtl |= AUDCTL_HP1; // audctl } More or less clearly: if filter is set on instrument envelope played on CH1 and CH1 volume is non zero CH3 AudF = CH1 AudF + some filter value if CH3 AudC is not Volume Mode Clear CH3 AudC Set AudCtl HiPass1 if no filter is set: if (((m_songRuntime.CurrentTracksEnvelopeCD[1] & (byte)Envelope.Mask.Distortion) == 6) && ((m_songRuntime.AudC[1] & 0x0f) != 0)) { byte outNote = m_songRuntime.CurrentTracksOutNote[1]; m_songRuntime.AudF[0] = frqtabbasshi[outNote + frqtabbassloOffset]; m_songRuntime.AudF[1] = frqtabbasshi[outNote]; if ((m_songRuntime.AudC[0] & 0x10) == 0) m_songRuntime.AudC[0] = 0; tmpAudCtl |= AUDCTL_CH1_FASTCLOCK | AUDCTL_CH1CH2_LINK; // audctl if CH2 distortion = 6 and CH2 volume is non zero put note from 16 bit table in CH1 and CH2 AudF if CH1 AudC is not Volume Mode Clear CH1 AudC Set AudCtl 1.79mhz(?) and 16bit mode Like I said I could add a AUDCTL parameter in the envelope and remove the above code (at least the 16bit mode code) but does it make sense to change between 8bit and 16 bit at every envelope step ? Alternatively I could just do: if Instrument AudCtl on CH2 is 16bit put note from 16 bit table specified by Dist in CH1 and CH2 AudF And get all the settings from the RMT instrument editor: 8/16 bit mode, 8/16 bit table from envelope dist, 15KHZ /1.79mhz That'd be some pretty tight control...

? 🤨 Like I said the extra instrument data would be in a text file. You'd have BattleSquadron.rmt and BattleSquadron.instr. The .instr would contain values that would override those in the .rmt. For instance it would be possible to override the distortion parameter which is limited to $0-$e with $0-$fffe (yeah that'd be 32768 tables) So no more 7 tables limit but an extra text file per tune would be required to take advantage of it. still muddy ?

I remember now vaguely that I tried different settings last year when I was adding sound to PoP, in my case because it's all RAM (128KB) it never made sense to use the smaller playback buffers... I have lots of small tunes tunes so it's better to just use the best compression with the biggest buffers as all the tunes benefit. Yes I think it's because it's not purely a bit stream where the 7bits offset is followed by the 5bit length... if you look at the compressor for the case where the total bits is between 8 to 12, the offset is output as a byte with 1 bit from the length, then the length is combined with some bits of the next(previous?) length... This allows the decompressor to read full bytes all the time, it'll read the control byte which tells what the next 8 "items" are (single new bytes or buffer copies). If it's a copy, it'll read the offset byte + 1 bit from the length then read the length byte and combine it with the unused length bits from the previous length byte (nib_data) Or something like that I believe... But yeah it'll be a little messy to change it to 6/6

so in layman's terms, 15khz sound provide lower frequency sounds than 64khz and 1.79mhz higher frequency ones ? The AUDCTL settings are a little confusing: from https://en.wikipedia.org/wiki/POKEY any way of rephrasing that more simply ?

So looking at the source, there's a AUDCTL setting per instrument which never varies... you're saying it should also be part of the envelope, same as dist ? I also see, that each instrument's AUDCTL value is mixed into the final AUDCTL value, right ? Yes that's mostly what I mentioned in the first post... But I'm thinking a simpler (crappier too) solution may be possible: a text file that would override/ extend instrument parameters Let's say I want to extend DISTORTION. Right now it's limited to 8 but I want a big number like 1024. let's say the envelope length is 10, there could be something like: [instrument0] EnvelopeDistortionTable = $0028, $0196, $0214... (10 values) it could be possible to specify the table format too (8 or 16bit) EnvelopeDistortionBitFormat = 8,16,8,... (10 values) the instrument text file would have the same name as the RMT file with a different extension and be loaded automatically when converting (if custom table option is selected) The custom table file would contain all the tables ?

That part I understand (I also remember from the Amiga mods that effects are parts of the tracks and not instruments) That part's not that clear... ...But I get it that track effects would be nice... In theory it's easy to do because whenever RMT reads a new trackline, it reads all the instruments and sets up the effects based on the instruments... so there's nothing that prevents effects from coming from the track line itself instead of the instrument... Again, that's the theory... In practice tracks effects may clash with instruments effects, I don't know... The main problem is that a new editor is absolutely required for that (or an existing one from a different platform but that means throwing away the RMT player)

Not sure when you say $60, you mean dist $6 right ? You're right... I think ? I totally forgot about channels... 16bit table is only used when channel 1/3 have dist $6, for channel 0/2, dist 6 would use the 8bit table. (I tend to number channels from 0 to 3, not 1 to 4... well not always!) I don't understand what you mean with dist $C though... Nice! yeah like I said I don't really know how to test them 😏 but I can use your table for the next release if you want.

Nice! Weird, Shouldn't bits_moff = 6; bits_mlen = 6; bits_set |= 8; do that ? I've not really played much with custom settings though

I guess the way I ordered the tables was totally confusing 😃. And to make things worse I just noticed that the Dist value is actually multiplied by 2 just so that it's more convenient to use inside the 6502 player... I also understand your comment in your table: "//frqtabbasshi --- high byte order, uses the AUDC setting used for $60?" which is actually right... when dist 6 is used, the player switches to AUDCTL_CH1_FASTCLOCK (1.79mhz) and AUDCTL_CH1CH2_LINK (16bit) for channel 1 (same with channel 3) This means there aren't 8 8bit tables available but 7. So when I previously thought I could easily have a different 16bit table for 1.79mhz and 15khz, that's not actually possible unless I lose another 8 bit table Hopefully I didn't miss any other sneaky code... This is the original order (the index being the envelope distortion parameter) frqtabpure frqtabpure frqtabpure frqtabbass1 // sneaky 16bit override frqtabpure frqtabpure frqtabbass1 frqtabbass2 but the tables are actually stored in the following order in memory: frqtabbass1 frqtabbass2 frqtabpure So I simply added new tables names like this frqtabpureA frqtabpureB frqtabpureC frqtabbass1A // sneaky 16bit override frqtabpureD frqtabpureE frqtabbass1B frqtabbass2A and added new tables data after the original ones in memory frqtabbass1A frqtabbass2A frqtabpureA frqtabpureB frqtabpureC frqtabpureD frqtabpureE frqtabbass1B so envelope dist 0 is actually table 3 envelope dist 2 is actually table 4 envelope dist 4 is actually table 5 envelope dist 6 is actually table 0 ... envelope dist C is actually table 7 envelope dist E is actually table 1 That allowed me to remain compatible with the original RMT and made it easier for me to test that it actually worked... I've changed it for v1.51 (grab it from the usual spot) so that the tables match the envelope dist param. and I've removed the names in the comments because they don't really make sense anymore. envelope dist 0 is table 0 ... envelope dist E is table 7 I believe this should work but I don't really have a way to test it... Usually when making a change I just compare the newly output Pokey data with old known valid pokey data but in this case there's none (Guess that happens when breaking new grounds 😁)

I didn't know that 😮

Well you have 8 now so go on, impress us again 😀 But if distortion is part of the envelope, it should already be the case ? Better instrument support doesn't seem very difficult it's just that there's no editor for it... It may be possible to have a very simplistic external instrument editor (which would be totally incompatible with RMT though). Or perhaps have extra parameters coded in the instrument names ????

yes, the new RMT2LZSS should address that. I'm not sure what all the frequencies mean... Every time I see 15khz mentioned, I know its the duration of a scanline but how does that relate to Pokey ? same with 64khz and 1.79mhz (yes I know it's the CPU frequency but again what does that have to do with sound ?) That I could actually do... If AUCDTL has linked channels and AUDCTL is 64khz -> use 16bit table A If AUCDTL has linked channels and AUDCTL is 1.79MHZ -> use 16bit table B ? ? You mentioned that already... no idea what you mean... you'd to find a different way to explain it

Well I was hoping for something that showed clear differences between the settings but I guess that's not absolutely required and I can remain blissfully ignorant 😀

The sap file always contains the tune in its original format as well as the corresponding 6502 player, I added that option specifically to rip all the RMT tunes out of their sap format, you can point to whole asma sap archive and it will extract RMT tunes from those that contain one.

By popular demand: custom note table! Untested too! From the doc The table file is loaded every time the version is selected so to reload for testing purposes, just switch between that version and any other. There are 3 8bit note tables in the original RMT which I have extended to 8. If I understand correctly they are selected with the distortion parameter of the envelope command (which supports a 8 values max). I have also exposed the AUDC value for each of the envelope values. 16bit not table is also exposed but I couldn't have more of them because there's no parameter in RMT. If there was any editable parameter it would be a piece of cake of course. Let me know if/how that works...

here's the thread where LZSS originated: I actually tried RLE and yes the results were worse... Wouldn't LZSS12 be a reasonable compromise ? A perhaps interesting variation would be to compress each channel separately and use different buffer sizes ?