rensoup

I'm going to check the vibrato and portamento code but a simple example of the limits of either of these commands would be nice whenever you get the chance.

Sure is, but that's a regular sample playback routine on one of the channels, meaning high frequency so not very useful for use with anything but a static screen

yes but we've been there before, and lots of those tunes don't sound that different when played back at lower frequencies, it's super easy to test with RMT2LZSS with the "Output frequency option" You could perhaps try some of those tunes at 50hz and check if you hear major differences with your audio setup ?

Glad you're always able to clarify 🙂 Yes but for that you would need 16bit input on those parameters as well right ? Right now the RMT command argument allows for 8bit only, so with 8bit as input you can't get 16 bit precision 🤔 if the inputs are changed to 8bits+8bit fixed point, then should be pretty easy in the code to support that kind of precision (basically change all the "byte" to "int16" and >>8 when looking up the note in the note tables) That way you'd get 16bit precision even in 8bit mode too. Another thing: In 16bit mode, the final 16bit frequency is looked up in the 16 bit table from the 8 bit note but if you have 8bit fixed point precision, would it make sense to do a bilinear interpolation between the 2 closest 16 bit frequencies ? or would that sound totally wrong ? One thing I noted is that 16bit mode is perhaps not as used as the filter for instance ? So is it really worth it ?

Possibly but I don't know if there would be any advantage... I'm thinking LZSS can be modified to output all 4 channels at different frequencies so it would be very similar ( in terms of efficiency and code simplicity ) That could be interesting and a nice space saver... But are there any combo that are invalid ? It seems that those registers can be abused in all sorts of ways... Vinscool mentioned that you can use Volume only and still use AUDF for different purposes. If you're talking about redundant dist modes, they're taken care of by the spacing saving code that dmsc added to LZSS. I'm also waiting for that killer tune that proves 200+hz updates are actually useful 😀

There's the possibility that for a volume of 0 (and without 16bit nor Highpass) on a given channel the frequency could indeed be set to 0, I tried automating that and while the processes finds lots of values to reset to 0, it doesn't produce a better compression or even makes it worse 😐 Would have been nice to save some bytes but it's not a big deal... You're saying you can use the filter on a channel to filter frequencies on the other channel yet output sound with the filter value ?? Wouldn't that be quite random ? Any explanation on that ? Can you explain what the filter does in simple terms ( What kind of effect it gives you on the sound) ? yeah it should be 0.0625... if you have a simple example that doesn't work, I could take a look.

Well it's not obvious from this test but I'll take your word for it 😃

Ok, you got it... SampleStep <= 0 means SampleStep of 1 without taking AUDF into account... how's that for a birthday gift 😃 ? (1.73 is available!) I also fixed the sampleStep formula above, so hopefully a sampleStep of 0.5 and AUDF=0 should still be 1... let me know... Weird... are you saying you can save space for pretty much every tune even if it doesn't use samples ? Space saving related question: when using the HP filter for let's channel 1 & 3, shouldn't it be possible to discard AUDC3, since only AUDC1 is used ? I tried with your BS tune and that didn't really work... Did you get the chance to try it because envelope speed should affect everything envelope related: basically if the envelope index hasn't moved this frame, no command or envelope effect gets processed. like I said above, hopefully this should work better now ? Aren't you taking this a little too far 😀 ? That formula I made up for the frequency was just a test !

You could describe the problem more accurately perhaps? I'm guessing 16bit here has nothing to do with AUDCTL linked channels ? Are You talking about command parameters having a finer accuracy than 1 step per update ?

new bugfix release ! 1.72 May 2021 -bugfix for 400/800hz playback not updating the tune at the right frequency -inverted sample playback note frequency

exo-area2 from @Synthpopalooza LZSSed... exo-area2_lzss.obx

I had to LZSS it! works pretty nicely with custom SKCTL... (DOH can't even attach files either in this thread...)

You mean RMT command support in 16bit ?

😏 it's all experimental stuff, I'm not into music technology nor a musician so I don't know what's useful or not... I'm not going to write editors for every feature I add because that'd be a lot of wasted time... So you're stuck with text files and a crap workflow... (for now at least)

sample rate is whatever you want, then you adjust the base playback frequency with the SampleStep, just like the previous 1.7 revision but now you're also able to adjust the playback frequency by using the note in RMT with 128 being 1 and 255 being 1.5 and 0 being 0.5: double freqMul = AudF ; // 0-> 255 freqMul / 255; // 0-> 1 freqMul + 0.5f; // 0.5 -> 1.5 sampleIdx += SampleStep * freqMul; The SampleStep is multiplied by the note Frequency. Yes AUDF didn't matter but I thought if I took into account you'd be able to play various notes just like regular trackers. So there was no need to create an individual instrument for each note... But Ivop's tests show that it's better to create a new sample per note. Not sure which way to go... and if it's actually worth it at all... I'm bit reluctant to add arbitrary rules like that especially since you can just set your SampleStep to 1 and AUDF to 128 to get the same thing. I have no idea 😀 I guess the frequency is actually a divisor so it would make more sense indeed. hmm... I guess that makes sense since the sample plays much slower resulting in identical AUDC values which would help compression ? hmm.. bug I think... I added values 5 and 6 but really I should have converted them internally to 8 and 16 ! So while the A8 player plays 8/16 updates per frame, the RMT player only does 5/6... That needs fixing! envelope step is for every kind of envelope, I split it in 1.71 since the sample isn't stored in the envelope anymore but it's still there: EnvelopeStep and SampleStep are just 2 different things now. So you could have a 15 step envelope playing very slowly and changing AUDF which would affect a sample's playback speed. Honestly the sample playback is more of an afterthought... I was more interested in 400/800hz playback frequency for regular Pokey, I just figured maybe it would be possible to shape sounds more finely and get digi like sounds...

You keep mentioning LFOs, so I checked on https://en.wikipedia.org/wiki/Low-frequency_oscillation Aren't LFOs part of RMT already (as effects) ?

hmm... with 4 channels updates, maybe 1200Hz... with a 3channels at 50hz the 4th could perhaps go as high as 3-5Khz

Well I was never able to download those files, instead of showing the download count, they're now in a permanent "fetching info" state

And here's the same sampletest as before updated with the new features sampletest2.zip sampletest.obx Oh yeah, the AUDC dist part is not cleared anymore with this latest release (for that tone generator)

I just posted a new release: 1.71 May 2021 -sample playback now takes into account channel volume as well as frequency (in a simple linear way) in the .erti example should be I'd put the sample data into the envelope but it wasn't really necessary, just somewhat convenient. I decided to store the sample data in its own buffer with this latest release so the envelope should be available as usual. I now take into account the track volume to modulate the sample volume. And I also take into account the track note to modulate the playback frequency... just like a regular tracker but in a crappier way. So you can apply regular envelope effects (and still update the envelope pointer with steps < 1) to the note then the final note will alter the sample playback frequency. I just grab AUDF, with value 128 being regular playback frequency (= 1), 255 = 2(so twice faster), 0 = 0(that would play the same value forever). I should of course change the playback frequency to real note's frequency for correctness but I'd need a table for that...

the wave is pretty nice in that version but it's still quite chunky, especially compared to your sawtooth at 50hz which was much steeper. Would there be a way to use regular Pokey sound at higher frequencies to be able to play sounds that are close to samples ? (ie convert sampled sound into regular pokey sounds) interesting that the filesize is okayish at 800hz !

I'm guessing you meant $f and $0 | VolumeOnlyBit ? here's a test I did with just a single $f and $0 (128 was way too long to sound interesting) and varying volumes as well as frequencies... wouldn't say there's any improvement... I added the source in the latest release, it' just VCount so it's not super accurate indeed but I doubt that it's going to make much difference... it's fixed point so sometimes it's on the right scanline, sometimes on the scanline before. You could just set the increment to 13 for that 650hz playback. sampletestsquare.obx

Wonderful 🤪 It's not sounding very good but it's entertaining 😀

I added an EnvelopeLoop command in the .erti file to try looping samples I also left the dist setting in AUDC instead of setting it to 0 even though it doesn't seem to make any difference I also modulated the sample volume with the RMT volume table just like regular Pokey sounds so the sample volume can be set in the editor volume column. Sounds meh 😑 so I'm a bit reluctant to package yet another release just for that... sampletest.obx

Sure, but right now it's all LZSSed so... I tried forcing the pure tone generator but it made no difference to the sound ? Or should a regular Pokey sound be played with $a0 then switch to volume only + $a0 to get some better sound ? I tried generating some super short sine waves with audacity (200+ bytes) and low pass filtered it and it still sounds crap 😃 tried lowpass filtering that bass... still crap 🙂 (but I had the volume normalized before though I don't think it would have made any difference)