RMT2LZSS: convert RMT tunes to LZSS for fast playback!

[VinsCool]

Yeah I know that was a shit output lol
I was mainly testing the sample playback feature, and see how to get a predictive pattern going more than anything.
No way I was going to make a tune with that, at least not until I get a more robust conversion process making full use of the low quality output.

[ivop]

Tried different waveforms:

 

GENWAVEFORM    .macro mem, label, x
    org :mem
.def waveform:label = *

; SQUARE
::x dta $1f
::x dta $10

; SAW
;::x*2 dta $1f-(#*16/(:x*2))

; SINE
;    dta sin($18, 7, :x*2)

; TRIANGLE
;::x dta $10+(#*16/(:x))
;::x dta $1f-(#*16/(:x))

.def len_waveform:label = * - waveform:label
    .endm

 

Note that this uses a 48 byte waveform, or less, down to 26 bytes. Replay rate is 975Hz (PAL). All maximum volume.

 

Square wave: sounds pretty good. Could also be used as a subwoofer channel.

Saw wave: similar, but you can still hear some aliasing.

 

Sine wave: horrible bass IMHO. Slightly higher, it still might be useful.

Triangle wave: see sine wave

 

main.s main-saw.xex main-sine.xex main-square.xex main-triangle.xex

Edited May 2, 2021 by ivop

[emkay]

17 minutes ago, ivop said:

Tried different waveforms:

 

GENWAVEFORM    .macro mem, label, x
    org :mem
.def waveform:label = *

; SQUARE
::x dta $1f
::x dta $10

; SAW
;::x*2 dta $1f-(#*16/(:x*2))

; SINE
;    dta sin($18, 7, :x*2)

; TRIANGLE
;::x dta $10+(#*16/(:x))
;::x dta $1f-(#*16/(:x))

.def len_waveform:label = * - waveform:label
    .endm

 

Note that this uses a 48 byte waveform, or less, down to 26 bytes. Replay rate is 975Hz (PAL). All maximum volume.

 

Square wave: sounds pretty good. Could also be used as a subwoofer channel.

Saw wave: similar, but you can still hear some aliasing.

 

Sine wave: horrible bass IMHO. Slightly higher, it still might be useful.

Triangle wave: see sine wave

 

main.s 2.71 kB · 1 download main-saw.xex 5.44 kB · 2 downloads main-sine.xex 5.44 kB · 2 downloads main-square.xex 5.44 kB · 1 download main-triangle.xex 5.44 kB · 2 downloads

It's exactly what I'm about. 

The power at that speed is not really impressive. The voltage changes don't create powerful pulses.

But this isn't needed, if the software allows to control the volume and the wave creation to use "LFO"s , and to build better music. 

[VinsCool]

I'm a little confused right now.

What should be the expected sample rate to be fed in? and most importantly, at what speed?
The newer sample "pitch" system really makes me confused right now. outputting on a frequency 00 plays too slow, and FF plays too fast, but I could have sworn I had figured out the speed in version 1.7, which I manually provided the output at step speed 1, and the content of AUDF didn't seem to matter, it was simply kept in memory, so I was able to sort of manipulate other channels from the frequencies it carried that way.

 

I just don't know anymore lol

My samples were saved as 16-bit, bit-crunched to 4-bit for less quality loss during conversion, and played at 800hz (or 32000hz with its content played 40x as fast for the same effect), and then those were playing exactly as expected using a step of 1 when I did my test tune the other day, currently I am still unsure which setting plays better, and it's also easy to change the speed in the .erti, but I prefer not having to do that for the tests I am making. Is it possible to simply have a check to values of 00? and not change the pitch when it's detected? or something as such, so it won't be altered and require to be adjusted using steps, or manually edited prior to conversion.
That being said, it's not a really big deal, I know it's very experimental features so I'll do my best to adapt, so far I seem to be able to get the expected playback using 00 and envelope step of 2 using the same samples I tested the other day, so as long as it works I'm cool  

Something else I observed was that frequency FF seems to be the highest point, then incrementing makes the sample pitch go lower in a linear way. I don't see any problem about linearly changing it, but wouldn't it be more logical to do it the in reverse?
00 being the highest (default) and gradually going to FF using a predefined division of the sample playback speed would work a little more intuitively, in my opinion. Tuning doesn't really matter currently, so that is out of the way at least  
It also helps avoiding getting corruption pitching it down, if I try to pitch up (by using higher sample step values), it eventually gets outside of the possible output pitch (400hz), resulting in lots of (really cool!) overtones, but may be unwanted in most cases, unless they are purposefully done, again, using the sample step values to multiply the output.

I imagine there may be a way to get a pretty constant method in place, so don't worry about it, I am fine with how it works currently, as long as something works, it will do the job.

 

Another observation I made is, playing a sample stream at frequency 00, and convert to executable using RMT2LZSS, seems to output a much smaller file size, without any loss other than the pitch related things I mentioned above, so that's another important point to consider if saving space is crucial  
 

-------

I don't know if the following observations are bugs, or intended features, but there are a few things I noticed since version 1.7:

Playing a hacked module to speeds greater than 200hz seems to literally make everything run faster, unlike the way RMT was coded from 50hz to 200hz, where only the instruments ran faster envelopes, keeping the patterns at the same original speed matching 50hz playback.
I don't really have a problem with that, I could simply adjust the speed values in the tracker pattern in a multiple of 2 (400hz) or 4 (800hz) to compensate, but I thought it was worth pointing out.

Also regarding the envelope speed recently implemented, I am not sure if I was doing something incorrectly, or if those were intended only to samples, any confirmation about this?
I was under the assumption this was for any instrument, which really would have helped adjusting a song playback to still sound correct at higher speeds like 800hz, but it seems to not be the case?
If that was a misunderstanding from my part, nevermind this, hahaha.
I have only really tried that feature first in 1.7, not yet 1.71, and saw it was changed once again, so I need to try that again anyway.

There was nothing else I did try so far other than the samples tests, so I probably have missed a bunch of things.

I'll try to see what else may have changed in a good or bad way later, unless a new version gets dropped improving anything I may be attempting to work around (hehe, pretty much like the song sketch I made with my bass sample in 1.7), so I'll make sure to keep an eye on the thread more often  

 

[emkay]

rensoup was laughing at my test tune 

But it produces basses that sound like the "beeper basses" produced at 15kHz , using 800Hz digi plus available generator tones "between the sampling steps". 

It is working at 64kHz POKEY clocking. 

The problem is that RMT allows to have the speed 6 , but the tune runs like speed 4 in the editor. 

It's all a big mess. 

In RMT 

-timing incorrect

-note values incorrect

-filter setting incorrect

-volume setting incorrect

...

...

...

.......................................................

....

 

You cannot shot with a gun into a forest , waiting for a "roast venison" meal turning back. 

This simply doesn't work....

 

[emkay]

 

@VinsCool 

I see you're "confused" . Why?

My post makes 100% sense. 

Could you ask for the special parts that confuse you?

 

 

 

Edited May 2, 2021 by emkay

[rensoup]

2 hours ago, emkay said:

But this isn't needed, if the software allows to control the volume and the wave creation to use "LFO"s , and to build better music.

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) ? 

[rensoup]

2 hours ago, VinsCool said:

What should be the expected sample rate to be fed in? and most importantly, at what speed?
The newer sample "pitch" system really makes me confused right now. outputting on a frequency 00 plays too slow, and FF plays too fast, but I could have sworn I had figured out the speed in version 1.7, which I manually provided the output at step speed 1, and the content of AUDF didn't seem to matter, it was simply kept in memory, so I was able to sort of manipulate other channels from the frequencies it carried that way.

 

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...

 

3 hours ago, VinsCool said:

Is it possible to simply have a check to values of 00? and not change the pitch when it's detected?

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.

3 hours ago, VinsCool said:

Something else I observed was that frequency FF seems to be the highest point, then incrementing makes the sample pitch go lower in a linear way. I don't see any problem about linearly changing it, but wouldn't it be more logical to do it the in reverse?

I have no idea ? I guess the frequency is actually a divisor so it would make more sense indeed.

 

3 hours ago, VinsCool said:

Another observation I made is, playing a sample stream at frequency 00, and convert to executable using RMT2LZSS, seems to output a much smaller file size, without any loss other than the pitch related things I mentioned above, so that's another important point to consider if saving space is crucial  

hmm... I guess that makes sense since the sample plays much slower resulting in identical AUDC values which would help compression ?

3 hours ago, VinsCool said:

Playing a hacked module to speeds greater than 200hz seems to literally make everything run faster, unlike the way RMT was coded from 50hz to 200hz, where only the instruments ran faster envelopes, keeping the patterns at the same original speed matching 50hz playback.
I don't really have a problem with that, I could simply adjust the speed values in the tracker pattern in a multiple of 2 (400hz) or 4 (800hz) to compensate, but I thought it was worth pointing out.

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!

 

3 hours ago, VinsCool said:

Also regarding the envelope speed recently implemented, I am not sure if I was doing something incorrectly, or if those were intended only to samples, any confirmation about this?
I was under the assumption this was for any instrument, which really would have helped adjusting a song playback to still sound correct at higher speeds like 800hz, but it seems to not be the case?
If that was a misunderstanding from my part, nevermind this, hahaha.

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...

 

 

 

[rensoup]

3 hours ago, emkay said:

In RMT 

-timing incorrect

-note values incorrect

-filter setting incorrect

-volume setting incorrect

...

?

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)

[rensoup]

exo-area2 from @Synthpopalooza LZSSed... 

 

 

exo-area2_lzss.obx

[rensoup]

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
 

[VinsCool]

4 hours ago, rensoup said:

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.

Ahhhh there we go! Now that explains it all about the 00 playing too low; I suspected this was indeed what happened there, and I resorted using a step value of 2 on 00 to achieve the same results.

4 hours ago, rensoup said:

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 really depends on the use intended for the instruments/samples in question, I believe.

I've come to similar conclusions regarding the necessity of making new samples for certain notes, too, which was the reason I wondered.

 

Maybe an additional line in the .erti such as "PitchedByAUDF=" with a value of 0 or 1 could be a fair compromise? 

 

At least that could allow the Frequency being kept in memory while a sample plays at the same time at a fixed pitch regardless of the note, except it could still update it at any time, I noticed in 1.7 this was only working from a note played prior to a sample to be held in memory, seems to be fixed in 1.71 due to the nature of pitching the samples based on AUDF, so that may be really useful, I can just imagine the potential of playing 16bit notes or high pass filtered tones at the same time that way

 

4 hours ago, rensoup said:

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.

yeah that is fair, actually the suggestion I just wrote above would make a lot more sense to implement as a compromise instead of hardcoding what I asked earlier.

4 hours ago, rensoup said:

hmm... I guess that makes sense since the sample plays much slower resulting in identical AUDC values which would help compression ?

As far as I could tell it's related to having all 00s in memory, I tried with any other values, regardless of instruments, samples or effects, and those would throw some interesting verbose text in the converter, then make considerably larger files, while 00 would simply be compressed really well, and for some reason it looks like 00 is assumed to be "empty" so that could be related.

 

In any case, if you try to play large samples, playing through a AUDF value of 00, will save several kilobytes, which really surprised me because other than that the speed was adjusted to make the sound output 100% identical.

 

This also gives me a few clues for further optimisations in tunes... If a pattern is empty, or its frequency not needed, I could keep using my "null" instrument forcing Distortion 0, volume 0 and AUDF 00 to save a considerable amount of space, since when a channel is mute, usually its frequency remains carried over, which can fill up the memory really quick as a result.

5 hours ago, rensoup said:

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.

I thought as much, however I wonder why this didn't seem to do any difference for me, regardless of the 1.7 and 1.71 versions, I could only get the samples to play at different speed with these values, other instruments would still remain updated at the constant speed, which was a tad annoying, especially at 800hz where it gets overwhelming.

 

What exactly would this envelope speed affect? I kinda expected volume, and commands, at least, to be able to keep the same instrument sound from 50hz to 800hz easily, but again I probably just tested that poorly so it's possible this is my own errors lol

I'll make sure to try that out properly next time now that samples is mostly figured out now.

 

1 hour ago, rensoup said:

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
 

Yay birthday release!

 

2 changes that are very appreciated! 

 

I have not got that much time today testing this stuff but I'm glad these improvements came along very quickly after my post earlier today :3 

[VinsCool]

hah I did it lol
pitch control probably won't be very good though

It was just a little experiment I wanted to do with very tiny samples, technically that could fit in the volume values, but then there wouldn't be much control over it, so who knows what becomes possible with this kind of design soon  

I did it with RMT2LZSS 1.72 and I noticed an important issue for this design: I absolutely need to use a frequency of 7F to get the proper sample step of 1, trying to use anything else becomes choppy, so 00 being 2 I assume will play back the waves wrong, even if I then make sure to force 0.5 in the .erti, for some reason.
Not that this is a really big problem, but that's worth mentioning to avoid any unpleasant surprise.

 

I'll attach my files for this example below.

 

Tiny PWM Test.xex Tiny PWM Test.zip

[VinsCool]

Figured some values that do work for pitch  

This used the same 16 samples long waveforms, tested with a square wave, at frequency 7F again for sample step of 1.

// Notes and approximative frequencies, calculated using a simple square wave sample, PAL (800hz) 
// Intervals are picked up as the first number that does change the pitch
//
// SampleStep --- Frequency --- Note
//
// 0.44       --- 21,6      --- ~F-0 
//
// 0.45       --- 22,2      --- ~F-0 
//
// 0.46       --- 22,8      --- ~F#0 
//
// 0.48       --- 23,5      --- ~F#0 
//
// 0.49       --- 24,2      --- ~G-0 
//
// 0.50       --- 24,9      --- ~G-0
//
// 0.52       --- 25,7      --- ~G#0
//
// 0.56       --- 27,5      --- ~A-0 (popping glitch)
//
// 0.58       --- 28,5      --- ~A#0 (popping glitch) 
//
// 0.62       --- 30,7      --- ~B-0 (popping glitch) 
//
// 0.64       --- 31,8      --- ~B-0 or C-1
//
// 0.67       --- 33.1      --- ~C-1 (popping glitch) 
//
// 0.70       --- 34,6      --- ~C#1 
//
// 0.73       --- 36,3      --- ~D-1 (popping glitch) 
//
// 0.77       --- 38,1      --- ~D#1 (popping glitch) 
//
// 0.85       --- 42,0      --- ~E-1
//
// 0.89       --- 44,2      --- ~F-1
//
// 0.94       --- 46,9      --- ~F#1
//
// 1          --- 50,0      --- ~G-1 
// 
// 1.07       --- 53,2      --- ~G#1 
// 
// 1.15       --- 56,8      --- ~A-1 or A#1 
// 
// 1.23       --- 61,3      --- ~B-1 
//
// 1.34       --- 66,4      --- ~C-2 (popping glitch) 
// 
// 1.46       --- 72,1      --- ~D-2 
//
// 1.60       --- 79,8      --- ~D#2
//
// 1.78       --- 88,6      --- ~F-2
//
// 2          --- 100,0     --- ~G-2 
//

I hope this may become useful  

Tiny PWM Test 2.zip Tiny PWM Test 2.xex

[VinsCool]

I also purposefully used every duty cycles I had for every notes in this example, since I got 16 steps long samples, so 15 duty!

 

There's now quite a bit more possibilities to make some music out of this  

[rensoup]

22 hours ago, VinsCool said:

I really depends on the use intended for the instruments/samples in question, I believe.

I've come to similar conclusions regarding the necessity of making new samples for certain notes, too, which was the reason I wondered.

 

Maybe an additional line in the .erti such as "PitchedByAUDF=" with a value of 0 or 1 could be a fair compromise? 

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...

22 hours ago, VinsCool said:

This also gives me a few clues for further optimisations in tunes... If a pattern is empty, or its frequency not needed, I could keep using my "null" instrument forcing Distortion 0, volume 0 and AUDF 00 to save a considerable amount of space, since when a channel is mute, usually its frequency remains carried over, which can fill up the memory really quick as a result.

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...

 

23 hours ago, VinsCool said:

What exactly would this envelope speed affect? I kinda expected volume, and commands, at least, to be able to keep the same instrument sound from 50hz to 800hz easily, but again I probably just tested that poorly so it's possible this is my own errors lol

I'll make sure to try that out properly next time now that samples is mostly figured out now.

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.

 

4 hours ago, VinsCool said:

I did it with RMT2LZSS 1.72 and I noticed an important issue for this design: I absolutely need to use a frequency of 7F to get the proper sample step of 1, trying to use anything else becomes choppy, so 00 being 2 I assume will play back the waves wrong, even if I then make sure to force 0.5 in the .erti, for some reason.
Not that this is a really big problem, but that's worth mentioning to avoid any unpleasant surprise.

like I said above, hopefully this should work better now ?

 

23 minutes ago, VinsCool said:

Figured some values that do work for pitch  

This used the same 16 samples long waveforms, tested with a square wave, at frequency 7F again for sample step of 1.

Aren't you taking this a little too far ? ? That formula I made up for the frequency was just a test !

[rensoup]

18 minutes ago, VinsCool said:

There's now quite a bit more possibilities to make some music out of this  

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

[VinsCool]

Thanks for the new version!

9 minutes ago, rensoup said:

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...

Perfect!  Thanks a bunch!

9 minutes ago, rensoup said:

Weird... are you saying you can save space for pretty much every tune even if it doesn't use samples ?

That's what I think, yeah.
I don't know if that's a coincidence or not but clearly having zeros everywhere saves space to me!

10 minutes ago, rensoup said:

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...

Yes and no, if the third channel was muted, then sure! But in my tune I also used it on top of the filter voice, so it won't sound good if it's discarded.
If only the frequency was used, then AUDC wouldn't be needed, indeed, since AUDF seems to be the only thing needed is what modulates the filter voice.
I could be wrong, however.

13 minutes ago, rensoup said:

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.

 

Yep I tried it a moment ago and it seems to work, so I probably was dumb lol

Not sure of the exact divisions I need to achieve a speed of 50hz on 800hz, but yeah it seems to work  
I'll keep trying out numbers until I get what may work.
I thought 0.0625 would work, but I get some weird noise that was not part of my instrument... not really important for now at least

28 minutes ago, rensoup said:

Aren't you taking this a little too far ? ? That formula I made up for the frequency was just a test !

Well damn so I got this and it's already obsolete? XD 
I thought I was smart pitching directly in the erti there LOL 

Well if there is any change to be done I'll make sure to update my numbers if needed hahaha

26 minutes ago, rensoup said:

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

I hope it will be I mean!
as long as some acceptable pitches can be done I'm happy! hahaha

[rensoup]

21 hours ago, VinsCool said:

That's what I think, yeah.
I don't know if that's a coincidence or not but clearly having zeros everywhere saves space to me!

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...

 

21 hours ago, VinsCool said:

Yes and no, if the third channel was muted, then sure! But in my tune I also used it on top of the filter voice, so it won't sound good if it's discarded.
If only the frequency was used, then AUDC wouldn't be needed, indeed, since AUDF seems to be the only thing needed is what modulates the filter voice.
I could be wrong, however.

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) ?

 

21 hours ago, VinsCool said:

Not sure of the exact divisions I need to achieve a speed of 50hz on 800hz, but yeah it seems to work  
I'll keep trying out numbers until I get what may work.
I thought 0.0625 would work, but I get some weird noise that was not part of my instrument... not really important for now at least

yeah it should be 0.0625... if you have a simple example that doesn't work, I could take a look.

[VinsCool]

1 hour ago, rensoup said:

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) ?

Basically yeah, they can output at the same time, if they happen to harmonise very well, like the PWM effect, or to produce chords like in my other sketch tunes.

 

So eg: channel 1 is modulated by channel 3 to output a distortion sound, channel 3 can still output its own volume (and frequency) on top of it and make the resulting sound even richer

 

or if it's the SID pwm sound, the 2 channels get added together to form an octave harmony, since the filtered voice outputs exactly 1 octave higher in pitch.

 

i used this intensively in many tunes, Emkay loves this too.

1 hour ago, rensoup said:

yeah it should be 0.0625... if you have a simple example that doesn't work, I could take a look.

I'll try to once I can, I am currently running into technical problems with my computer, but thankfully I was able to

backup my data... ?

1 hour ago, rensoup said:

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...

I am not exactly sure about how that works, but I noticed that manually setting 0's will help in many cases, at least for my tests, I usually got considerably smaller files output that way.

 

Sustaining a frequency of FF and then 00 in an empty pattern, or like, has little to no data into it, 00 will be the one with the most efficient compression, it looks like.

[VinsCool]

On 5/4/2021 at 10:50 PM, VinsCool said:

I'll try to once I can, I am currently running into technical problems with my computer, but thankfully I was able to

backup my data... ?

Okay so I finally was able to try this tonight lol
clearly something sounds wrong

setting used was:

Quote

[instrument$05] //kick drum
EnvelopeStep=0.0625

in theory that would have worked, unless I'm mistaken... ?

I don't think I'd do much tests for now, this old temporary computer replacement is insufferably slow to use lol

kick test 50hz then 800hz reduced.wav kick test 50hz.obx kick test 800hz.obx

[+Stephen]

10 hours ago, VinsCool said:

Okay so I finally was able to try this tonight lol
clearly something sounds wrong

setting used was:

in theory that would have worked, unless I'm mistaken... ?

I don't think I'd do much tests for now, this old temporary computer replacement is insufferably slow to use lol

kick test 50hz then 800hz reduced.wav 1.25 MB · 3 downloads kick test 50hz.obx 4.44 kB · 1 download kick test 800hz.obx 4.79 kB · 1 download

There's an awful hi-pitch noise on the 800Hz version, but the 50Hz version sounds clean.

[VinsCool]

4 hours ago, Stephen said:

There's an awful hi-pitch noise on the 800Hz version, but the 50Hz version sounds clean.

Yeah this was what I was talking about specifically.

That noise should not exist ?

[emkay]

47 minutes ago, VinsCool said:

Yeah this was what I was talking about specifically.

That noise should not exist ?

Depends on what you did in there

[rensoup]

On 5/10/2021 at 7:56 PM, VinsCool said:

Yeah this was what I was talking about specifically.

That noise should not exist ?

1.74 May 2021
    -fix for envelope step
    -added 16bit precision to portamento depth

 

Should be ok now...

 

16bit precision for portamento depth works for 8bit mode and 16bit mode (where the frequency is plugged in directly into both AUDF)

So portaSpeed is always 1 and portaDepth is 8.8 fixed point but start/end note/frequencies are still set in 8bit, meaning the .8 part always starts at 0.

 

ie: StartFreq = $8500, EndFreq =$9100, Depth = $0010

 

would produce:

$8500

$8510

$8520

$8530

...

$9100

 

the bold part would go into AUDF in 8bit, the bold and non bold part would go into each AUDF  in 16bit

 

I'm hoping it works because as usual it's a little annoying to test... if not, a simple example would help ?

 

The right way should be to convert everything that needs it to 16bit precision, like note tables and other effects but it's kinda messy...