Jump to content
IGNORED

Web Pokey


mrk

Recommended Posts

26 minutes ago, mrk said:

 

Something like:


diff --git a/rmt.js b/rmt.js
index 450e396..8641736 100644
--- a/rmt.js
+++ b/rmt.js
@@ -626,6 +626,8 @@ export class RMTPlayer {
                 this.channelTone[i].postPlay(this, i < 4 ? prev_audctl : prev_audctl_r)
             }
         }
+        this.savedAudCtl = [this.getPokeyAudctl(0), this.getPokeyAudctl(1)]
+
         this.sendRegs(this.pokeyRegs)
     }
 

or for mono only simply: 


this.savedAudCtl = this.getPokeyAudctl(0)

??? This way it will be stored in player property and available all the time

 

EDIT:

or simply do your stuff at very begin of step() method, before Audctl is zeroed (this.getPokeyAudctl() should return correct value there)

 

 

 

 

this was exactly what I was trying to do, but when I try to read the value grabbed at the start of step(), it would return a 0 where I actually needed it ?

maybe I just do things wrong, I'll try a bit later to see where I did it incorrectly :) 

Link to comment
Share on other sites

1 hour ago, VinsCool said:

I know I don't have a lot of programming experience, but I have had much less troubles figuring out stuff in 6502 ASM, so either I'm out of this world or javascript was invented to be the most counter-intuitive possible, lol ?

See, javascript is consuming you already ?

 

Coding is always a mix of satisfaction and frustration... much more of the latter though so keep going!

  • Haha 2
Link to comment
Share on other sites

So just as I thought things were not going so well, my friend TakuikaNinja came in and saved the day!

 

Not only did he found a way to get the values in memory when needed, he even fixed the 1 frame delay entirely!

https://github.com/VinsCool/web-pokey/commit/447e7cb5354e2e56ce2360a08b5d375b9f398116 

 

Currently testing it a bit right now, this makes an incredible difference!

I can now adapt all my tuning tables to it without any worry things may sound weird :D 

Link to comment
Share on other sites

Man, you remember the issue I mentioned having with instrument tables in += mode?

Well the fix ended up causing problems in everything else using instrument tables.

I was able to work around it yesterday, but things sounded quite wrong in certain situations, like if the table was skipping some frames, usually the first ones

It's frustrating to think I got a fix but other tunes were broken shortly after, so I think I have got like 5 "fixes" that were not really helping it, but I think I got it now... it makes no sense but if it works I guess that's all that matters lol

 

The "fix" turned out to be a simple -1 and +1, it makes no sense but at least the speed and the way the envelopes were read seems to be proper now ?

I only needed 4 commits that were breaking elsewhere, and a reversal of a change to finally come to this conclusion, and I fear the moment it will backfire now lol

 

Thankfully all the tunes that were playing a bit weird in yesterday's video all seem proper now :D 

Link to comment
Share on other sites

4 hours ago, VinsCool said:

Man, you remember the issue I mentioned having with instrument tables in += mode?

Well the fix ended up causing problems in everything else using instrument tables.

Hmm, the bug is still there? I was sure I fixed it recently here: https://github.com/mrk-its/web-rmt/commit/98ecde40983615abf832702cf0a12013d705b612

 

  • Like 1
Link to comment
Share on other sites

2 hours ago, mrk said:

Hmm, the bug is still there? I was sure I fixed it recently here: https://github.com/mrk-its/web-rmt/commit/98ecde40983615abf832702cf0a12013d705b612

 

yeah, it was this commit that did indeed make the += mode working, but broke everything else using the instrument table for some reason.

I was able to find a workaround that seems good enough now at least, it only took me several tries since every time I was trying to fix something, a different thing broke, and I would only notice in different .rmt files, after I thought it was good lol

At least to my ears, it looks like my most recent fork commit have worked around it the best, it's only a matter of finding a tune that will sound incorrect later maybe, I hope not! :P 

 

I have more experimental stuff coming soon, but I'll proofread my spaghetti code before I upload it tomorrow, just in case I screwed up somewhere hahaha.

I have a new test video uploading in the meantime :D 

Link to comment
Share on other sites

34 minutes ago, VinsCool said:

yeah, it was this commit that did indeed make the += mode working, but broke everything else using the instrument table for some reason.

Not sure if I understand what 'everything' above means - could you point me some rmt (for standard, not patched player) that sounds wrong after this commit (comparing to original, not patched rmt 1.28)? Maybe something included in 1.28 example songs? I can investigate it.

 

Edited by mrk
  • Like 1
Link to comment
Share on other sites

Just browsing the source, and I noticed this:

 

const VIB_TABLE = [

    [0],

    [1, -1, -1, 1],

    [1, 0, -1, -1, 0, 1],

    [1, 1, 0, -1, -1, -1, -1, 0, 1, 1],

]

 

I assume this is according to the RMT player source code.

 

Here's another "bug" IMHO. In between [0] and [1,-1,-1,1], there should be at least:

 

[0,1] and [1,0]

[0,-1] and [-1,0]

[1,-1]

 

Especially the first four are very handy to fool the ear when tuning errors occur in high octaves. And slower versions. I suppose that's why I never used the vibrato function, but always use my own table of offsets in the instrument editor ;)

 

Edit:

 

The third line is weird, too. 1 and -1 are played twice, with just a single 0 in between (which is the true note).

Fourth line playes 1 and -1 four times, and only a single 0 in between. ?

 

Edit2:

 

You should obviously replicate RMT's behaviour, but this are some weird vibrations :)

Edited by ivop
Link to comment
Share on other sites

9 hours ago, mrk said:

Not sure if I understand what 'everything' above means - could you point me some rmt (for standard, not patched player) that sounds wrong after this commit (comparing to original, not patched rmt 1.28)? Maybe something included in 1.28 example songs? I can investigate it.

 

Well it really could be noticeable in most .rmt tunes.

 

They would exhibit incorrect instrument envelope speed, and drop envelope frames when trying to work around it.

I did eventually find a way around it by using 2 tiny changes based on your commit originally posted before I spent multiple times working around it, but got variable results.

It took me a bit of guesswork, with trial and error, so it's probably not the right fix either.

Changes were these:

this.tspd = (data[4] & 0x3f) - 1 in class RMTInstrument {}

and

this.tspd = this.instrument.tspd + 1 in class RMTTune {}

This is probably not right either but at least most things sound fine as far as I tested yesterday evening since.

Link to comment
Share on other sites

31 minutes ago, ivop said:

Just browsing the source, and I noticed this:

 

const VIB_TABLE = [

    [0],

    [1, -1, -1, 1],

    [1, 0, -1, -1, 0, 1],

    [1, 1, 0, -1, -1, -1, -1, 0, 1, 1],

]

 

I assume this is according to the RMT player source code.

 

Here's another "bug" IMHO. In between [0] and [1,-1,-1,1], there should be at least:

 

[0,1] and [1,0]

[0,-1] and [-1,0]

[1,-1]

 

Especially the first four are very handy to fool the ear when tuning errors occur in high octaves. And slower versions. I suppose that's why I never used the vibrato function, but always use my own table of offsets in the instrument editor ;)

 

Edit:

 

The third line is weird, too. 1 and -1 are played twice, with just a single 0 in between (which is the true note).

Fourth line playes 1 and -1 four times, and only a single 0 in between. ?

 

Edit2:

 

You should obviously replicate RMT's behaviour, but this are some weird vibrations :)

I agree, the vibrato is weird honestly.

It could indeed benefit from some improvements, now that you mention it.

This is exactly the same numbers used in the original rmtplayr:

vib0	dta 0
vib1	dta 1,-1,-1,1
vib2	dta 1,0,-1,-1,0,1
vib3	dta 1,1,0,-1,-1,-1,-1,0,1,1

 

  • Like 1
Link to comment
Share on other sites

2 hours ago, VinsCool said:

Well it really could be noticeable in most .rmt tunes.

 

They would exhibit incorrect instrument envelope speed, and drop envelope frames when trying to work around it.

I did eventually find a way around it by using 2 tiny changes based on your commit originally posted before I spent multiple times working around it, but got variable results.

It took me a bit of guesswork, with trial and error, so it's probably not the right fix either.

Changes were these:

this.tspd = (data[4] & 0x3f) - 1 in class RMTInstrument {}

and

this.tspd = this.instrument.tspd + 1 in class RMTTune {}

 

This is probably not right either but at least most things sound fine as far as I tested yesterday evening since.

 

Heh, thanks, It is possible I broke something recently, will take a look.

  • Thanks 1
Link to comment
Share on other sites

35 minutes ago, mrk said:

 

Heh, thanks, It is possible I broke something recently, will take a look.

Much appreciated :)

At least, my temporary workaround seems to work fine, so don't feel like this is urgent, as far as everything else goes, most things seem as good as they could be, so thanks a lot for the rmtplayr recreation, It's a lot of fun to use :D 

  • Like 1
Link to comment
Share on other sites

1 minute ago, VinsCool said:

Much appreciated :)

At least, my temporary workaround seems to work fine, so don't feel like this is urgent, as far as everything else goes, most things seem as good as they could be, so thanks a lot for the rmtplayr recreation, It's a lot of fun to use :D 

Your workaround will be definitely helpful in bughunting, thanks! And I'm really glad you like this toy :]

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

22 hours ago, ivop said:

The third line is weird, too. 1 and -1 are played twice, with just a single 0 in between (which is the true note).

Fourth line playes 1 and -1 four times, and only a single 0 in between. ?

 

Edit2:

 

You should obviously replicate RMT's behaviour, but this are some weird vibrations :)

First I'm going to mimic original RMT as well as possible (with all his bugs / weird vibrations) - to be able to play all these rmt tunes created by original RMT as close as possible (I was even thinking about comparing sapr streams, but probably your eyes ears guys will be enough ;) This way we can also find bugs in Web Pokey itself. If it is done I'm open for implementing all these improvements / patches you made for RMT or extending this format in any direction.

Edited by mrk
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

I did some experimental changes to pokey.js, making both Poly4 and Poly5 sound correct without a pre-calculated table as well.

I also *think* I may have helped both Poly9 and Poly17 doing so? can't say for sure but the white noise sounds good to me, and the Poly9 tones in some of my test tunes seems to be very close to what Altirra outputs.

 

Not sure what else there is to change in the code due to the way I edited it, but maybe you'd be interested :) 

https://github.com/VinsCool/web-pokey/commit/bf7168168ec23b9c99dd5c73fe133d94d7ad432a

 

Here's one of my tunes running in this experimental version, playing from my Web-RMT fork version as well:

 

Edited by VinsCool
  • Like 3
Link to comment
Share on other sites

6 hours ago, VinsCool said:

I did some experimental changes to pokey.js, making both Poly4 and Poly5 sound correct without a pre-calculated table as well.

I also *think* I may have helped both Poly9 and Poly17 doing so? can't say for sure but the white noise sounds good to me, and the Poly9 tones in some of my test tunes seems to be very close to what Altirra outputs.

Not sure what else there is to change in the code due to the way I edited it, but maybe you'd be interested :) 

https://github.com/VinsCool/web-pokey/commit/bf7168168ec23b9c99dd5c73fe133d94d7ad432a
 

Ha, it is super helpful, thanks! I see you are starting mastering this JS thing, hehe ;) 

 

I was really frustrated by these Poly4 and Poly5 generators (I copied / derived these formulas from Altirra Hardware Reference Manual, but they didn't sound good and I ended with copying them from Atari800 I think). Can you create PR for it? :)

 

Poly9 / Poly17 looks the same after your changes (I think, taking a look again)

 

 

BTW what time zone are you in? Cannot determine looking on posts timestamps :]

 

Edited by mrk
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

On 10/8/2021 at 8:39 PM, VinsCool said:

Well it really could be noticeable in most .rmt tunes.

 

They would exhibit incorrect instrument envelope speed, and drop envelope frames when trying to work around it.

Fixed (I hope I didn't break other things this time) :)

 

Debugging it was quite fun. I started with creating rmt instrument with square, 50%-fill envelope and 2-element table changing in sync with envelope.


This way I was able to instantly hear the difference between web-rmt and rmt

And I think this is best way to simplify future debugging - let's create very simple rmt files clearly showing difference (unfortunately I'm tone deaf so I can easily miss difference in real tunes )

 

 

 

table_env_desync.rmt table_env_sync.rmt

Edited by mrk
Attaching examples
  • Thanks 1
Link to comment
Share on other sites

12 minutes ago, mrk said:

Ha, it is super helpful, thanks! I see you are starting mastering this JS thing, hehe ;) 

Can you create PR for it? :)

Thanks!

I've derived them from the Altirra Hardware Manual, Appendix A - Polynomial Counters, and then looked at the Altirra POKEY code as a reference, I was surprised to see the code was almost the same after my changes! 

I suppose there is some cleanup to do and some more tests before I send a PR, I've only recorded my tune and tested a handful of them before I went to bed, so I am not sure if I broke anything from this yet.

22 minutes ago, mrk said:

I was really frustrated by these Poly4 and Poly5 generators (I copied / derived these formulas from Altirra Hardware Reference Manual, but they didn't sound good and I ended with copying them from Atari800 I think).

This is what I believed was done, because things looked similar. I had referenced Atari800 at first and saw some similar stuff, except for the pre-computed tables that were used in the Atari800 code, they seem to be... wrong? ?

Poly5 was especially weird compared everything else, so I spent some time trying different combinations based on the documentation to come to the results I got.

 

I can say for sure Poly4 and Poly5 sound really good now, they seem to produce identical patterns to the pre-calculated tables, and they also seem to match the output from Altirra emulator, but I cannot be 100% certain everything is correct of it due to my lack of programming experience hehe

20 minutes ago, mrk said:

Poly9 / Poly17 looks the same after your changes (I think, taking a look again)

I think you may be right, now that I look again, maybe I had a different impression, or maybe I forgot a detail, I remember hesitating adding a ~ because it made Poly9 sound weird, so maybe the original code was correct for the Poly9/Poly17 generators already? :P 

I ended up with these lines thinking "heh that sounds pretty good anyway"

I was kind of confused to see Poly4 and Poly5 seemed to use most of the same code for generation... The Poly5 timbre sounded much closer to a Poly4 pattern too.

image.thumb.png.129605f27d3793642518f6db9e95163d.png

 

---

Having some rest might help me clarify some of this a bit more, hopefullyl I was able to help a bit so far :D 

Link to comment
Share on other sites

5 minutes ago, mrk said:

Fixed (I hope I didn't break other things this time) :)

 

Debugging it was quite fun. I started with creating rmt instrument with square, 50%-fill envelope and 2-element table changing in sync with envelope.


This way I was able to instantly hear difference between web-rmt and rmt

And I think this is best way to simplify future debugging - let's create very simple rmt files clearly showing difference (unfortunately I'm tone deaf so I can easily miss difference in real tunes )

Thanks! This was also how I was going, using test tunes or very specific modules made to test certain things, that was how I noticed the Instrument envelope issue at first :P 

I'll test your changes and see how it goes :) 

Link to comment
Share on other sites

40 minutes ago, VinsCool said:

I suppose there is some cleanup to do and some more tests before I send a PR, I've only recorded my tune and tested a handful of them before I went to bed, so I am not sure if I broke anything from this yet.

Sure. But please include only this Poly5 / Poly9 change in this PR - is always better to create few simpler PRs instead of single big one. Or I can simply cherry-pick your commit if everything looks sounds good :)

Edited by mrk
  • Like 1
Link to comment
Share on other sites

7 minutes ago, mrk said:

Sure. But please include only this Poly5 / Poly9 change in this PR - is always better to create few simpler PRs instead of single big one. Or I can simply cherry-pick your commit if everything looks sounds good :)

I'll go send a PR from my current change, in this case :) 

If you notice anything wrong it's my fault, haha

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...