Synthpopalooza Posted October 25, 2020 Share Posted October 25, 2020 I noticed the last entry ended on 65536 ... which didn't seem right. Going to look at it closer. Quote Link to comment Share on other sites More sharing options...
ivop Posted October 25, 2020 Author Share Posted October 25, 2020 (edited) I think the window/hop size is slightly off. Apparently 1s/0.1s is not exactly 44100+4410. Also, the last tone is because I did not snap of the last bit of the sample, but you can ignore that. Once the hop size lines up, the 127th tone should line up exactly with the last tone. I put the marker at 2:18.6 (138.6s), which should be at 2:18.77 or something. Edited October 25, 2020 by ivop Quote Link to comment Share on other sites More sharing options...
ivop Posted October 25, 2020 Author Share Posted October 25, 2020 (edited) Meh, progressive framerate is not exactly 60Hz/50Hz, but 59.9277/49.8607Hz for NTSC/PAL. 60/59.9227*(44100+4410) = 48572.529390 So for NTSC the window size is 48573. Altirra, configure system, computer, speed: Match hardware. Edit: for PAL it is 50/49.8607*(44100+4410) = 48645.488430. Hop size is 48645. Edited October 25, 2020 by ivop Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted October 25, 2020 Share Posted October 25, 2020 When I checked my settings by ear against the 16-bit tuning wave, I noticed they were one step out ... I will recheck tonight. So, I think I will first make a note table for all intervals, both iterations ... make a common best note table from them all ... then two tables, one for forward sawtooth and one for reverse sawtooth. Quote Link to comment Share on other sites More sharing options...
rensoup Posted October 25, 2020 Share Posted October 25, 2020 On 10/24/2020 at 4:41 PM, ivop said: The main problem is, how do you replay a cycle exact recording? You could perhaps include an out of band stream that records timing information for STIMER and SKCTL. Or, if you know upfront that only, say, three methods of syncing are used, you can hard code the exact three delay sequences and only record when to execute them. yeah I assumed there would be only a bunch of different delays but instead of storing timing info, you'd store those timed writes as extra register streams... Taking a completely made up example: -A delayed write of 120 cycles to STIMER would be stored as stream 9 -A delayed write of 253 cycles to STIMER would be stored as extra channel 10 -A delayed write of 77 cycles to SKCTL would be stored as extra channel 11 (stream 0-8 being the regular pokey registers) And if those extra streams aren't needed they would take no space thanks to the bitmask. Each stream requires an extra 256 byte buffer though (I'm guessing the player could be modified to only require the number of buffers for streams that aren't empty) I could be talking out of my ass of course because I don't know the full picture. On 10/24/2020 at 4:41 PM, ivop said: All in all, it is a lot of work. Adding timed recording to an emulator, write the player, etc... But I understand why you want to record everything to SAP-R/LZSS or an equivalent, because the player is one of the fastest. But a generic cycle exact recorder and a native replayer is impossible IMHO. That said, 99.9% of the tunes can be recorder to SAP-R. And as synthpopalooza said, a lot of modes involving SKCTL only need to have their initialization done once upfront, and after that you can just replay your $d200-$d208 SAP-R recording. Well you brought up cycle exact recording first with Pavros' method. I don't know if it's required for the better pokey control people like Emkay are requesting ? The 2nd advantage of LZSS is the player simplicity: no need to write anything as complex as the RMT 6502 player. If I understand correctly Foft suggested A pokey vst plugin which is the same as the Pokey.DLL that comes with RMT ? You said you were going to rewrite a Pokey.DLL, so openmpt + pokey means you could play tunes on PC as well as export them to LZSS directly which means no need for any emulator timed recording ? side question: is RMT pokey.dll very far behind in terms of emulation vs Altirra ? I seem to recall someone (roger?) saying it could be that RMT accessed it in a very limited way. Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted October 25, 2020 Share Posted October 25, 2020 I dont think my reverse 16 bit $4x mode worked properly in a hacked RMT I had done recently Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted October 26, 2020 Share Posted October 26, 2020 So ... I took some of the generated notes, and compared them to the tuning note in Pokey Explorer, and I noticed that on the lower registers, some of them are just a step out of phase. I wonder if the note table I am using is tuned properly. I copied the original 16-bit $Ax table from an old COMPUTE! article, but it may need to be rechecked for accuracy. If the $Ax 16-bit note table is indeed accurate (as I think it is) there may be a slight frequency error on the lower frequencies. On $0101, when you get up to about C3 it's pretty much spot on Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted October 26, 2020 Share Posted October 26, 2020 OK, I filled in the blanks by ear for the $0101 first iteration table: Table 1: $0101 interval, $0001 start c1 - $e5e6 c# - $dfe0 d - $d8d9 d# - $d2d3 e - $cacb f - $c6c7 f#1 - $c0c1 g - $bbbc g# - $b5b6 a - $b0b1 a# - $aaab b - $a6a7 c2 - $a1a2 c# - $9c9d d - $9899 d# - $9495 e - $8f90 f - $8a8b f# - $8788 g2 - $8384 g# - $7F80 a - $7B7C a# - $7778 b - $7475 c3 - $7071 c# - $6D6E d - $6A6B d# - $6768 e - $6465 f - $6162 f# - $5e5f G - $5B5C g# - $5859 a - $5657 a# - $5354 b - $5152 c4 - $4E4F c# - $4c4d d - $4a4b d# - $4748 e - $4546 f - $4344 f# - $4142 g - $3f40 g# - $3d3e a - $3b3c a# $393a b - $3839 c5 - $3637 c# - $3435 d - $3233 d# - 3132 e $3031 f $2e2f f# - $2d2e g - $2b2c g# - $2a2b a - $2829 a# - $2728 b - $2526 c6 - $2425 c# - $2324 d - $2223 d# - $2122 e - $2021 f - $1f20 f# - $1e1f g - $1d1e g# - $1c1d a -$1b1c a# - $1a1b b - $191a c7 - $1819 d7 - $1718 d# - $1617 e - f - $1516 f# - $1415 g - $1314 a - $1213 a# - $1112 c8 - $1011 As you get into the 6th octave tuning errors creep in. After c7, notes start getting dropped from the note table On the lower frequencies below c#3, i retuned these by ear. I am pretty sure that the reverse versions of these ($a1a2 - $a2a1 - c2) also will generate the same note, albeit variable tuning perhaps. Could you run your ear over these and see if you think these are accurate. Ideally, I would like an optimal table built from the first two, having only the frequencies which are closest to the actual note. This may again involve listening by ear. Next, I will do the other iterations, compare with the other tables, until we eventually have a full optimal note table encompassing all intervals that is as close to being in tune as we can get it, without distortion overtones. Then we can knock this setting on the head. Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted October 26, 2020 Share Posted October 26, 2020 Also at the $0505 interval, we get these two values at a4: 440.892517, and 440.893280. That is VERY damn close to A440. ? 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted October 26, 2020 Author Share Posted October 26, 2020 18 hours ago, rensoup said: I could be talking out of my ass of course because I don't know the full picture. No, you are close to what I meant with a side channel depicting when to do predefined synchronize sequences. 18 hours ago, rensoup said: Well you brought up cycle exact recording first with Pavros' method. I don't know if it's required for the better pokey control people like Emkay are requesting ? Possibly. Still not quite sure what emkay means by "micro programming" 18 hours ago, rensoup said: The 2nd advantage of LZSS is the player simplicity: no need to write anything as complex as the RMT 6502 player. Yes. We can write a new player without the complex optimizations used there. 18 hours ago, rensoup said: If I understand correctly Foft suggested A pokey vst plugin which is the same as the Pokey.DLL that comes with RMT ? A VST plugin is something that can be used by a DAW (Digital Audio Workstation). It can do MIDI, audio, or both. A Pokey VST plugin could, for example, input MIDI events from a sequencer (or a keyboard) and output Pokey audio data. 18 hours ago, rensoup said: You said you were going to rewrite a Pokey.DLL, so openmpt + pokey means you could play tunes on PC as well as export them to LZSS directly which means no need for any emulator timed recording ? Yeah, I said that, but I have postponed writing a new Pokey emulation, because I have found a different and easier way to do batch processing with Pokey Explorer 18 hours ago, rensoup said: side question: is RMT pokey.dll very far behind in terms of emulation vs Altirra ? I seem to recall someone (roger?) saying it could be that RMT accessed it in a very limited way. I have no idea. IIRC pokey.dll is based on the atari800 emulators implementation. 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted October 26, 2020 Author Share Posted October 26, 2020 13 hours ago, Synthpopalooza said: So ... I took some of the generated notes, and compared them to the tuning note in Pokey Explorer, and I noticed that on the lower registers, some of them are just a step out of phase. I wonder if the note table I am using is tuned properly. I copied the original 16-bit $Ax table from an old COMPUTE! article, but it may need to be rechecked for accuracy. If the $Ax 16-bit note table is indeed accurate (as I think it is) there may be a slight frequency error on the lower frequencies. On $0101, when you get up to about C3 it's pretty much spot on Both NTSC and PAL tuning tables Pokey Explorer uses, are calculated by https://github.com/ivop/pokey-explorer/blob/master/util/genfreqtab.c I believe my tables are correct. How does your COMPUTE! table compare to https://github.com/ivop/pokey-explorer/blob/master/tuning-16bit-ntsc.s ? Quote Link to comment Share on other sites More sharing options...
ivop Posted October 26, 2020 Author Share Posted October 26, 2020 13 hours ago, Synthpopalooza said: On the lower frequencies below c#3, i retuned these by ear. I am pretty sure that the reverse versions of these ($a1a2 - $a2a1 - c2) also will generate the same note, albeit variable tuning perhaps. Could you run your ear over these and see if you think these are accurate. Yes, it seems that $a1$a2 and the reverse almost produce the same note. My observation is that when reversing the value, the difference in frequency is around 1-2Hz max. For high notes, there's no discernable difference, but for lower notes 1Hz difference can be heard easily. I don't know your age and audio setup, but I (mid forties) start hearing the high whistling note around C3. The lower basses are probably not useful because of that Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted October 26, 2020 Share Posted October 26, 2020 Not sure but here is the table: https://www.atarimagazines.com/compute/issue34/112_1_16-BIT_ATARI_MUSIC.php Quote Link to comment Share on other sites More sharing options...
foft Posted October 26, 2020 Share Posted October 26, 2020 (edited) VST idea might be a no-go. OpenMPT supports VST 1 and 2, but not 3 as I understand it and the VST 2 API is no long around: https://www.steinberg.net/en/newsandevents/news/newsdetail/article/vst-2-coming-to-an-end-4727.html The V2 API can still be found somewhere though perhaps there is an alternative. Edited October 26, 2020 by foft Quote Link to comment Share on other sites More sharing options...
foft Posted October 26, 2020 Share Posted October 26, 2020 (edited) Taking a look at the sid equivalent to see how it works... https://github.com/igorski/VSTSID https://www.igorski.nl/download/vstsid--sid-synthesizer-instrument Perhaps we should fork this thread, I feel I'm not really on the original topic with this... ? edit: Probably not what we want to use, but found this! https://bedroomproducersblog.com/2018/07/08/vcv-rack-vst-port-unofficial/ https://library.vcvrack.com/KautenjaDSP-PotatoChips/POKEY Edited October 26, 2020 by foft 1 Quote Link to comment Share on other sites More sharing options...
rensoup Posted October 26, 2020 Share Posted October 26, 2020 2 hours ago, foft said: Perhaps we should fork this thread, I feel I'm not really on the original topic with this... ? Up to you, I don't know if there is that much to talk about? 2 hours ago, foft said: edit: Probably not what we want to use, but found this! https://bedroomproducersblog.com/2018/07/08/vcv-rack-vst-port-unofficial/ https://library.vcvrack.com/KautenjaDSP-PotatoChips/POKEY so vcv rack is a vst plugin and KautenjaDSP is a vcv rack plugin ? and its pokey emulation came out of nowhere ? Quote References & Acknowledgments Green, S. (2006). Game Music Emu. http://www.slack.net/~ant/libs/audio.html#Game_ Music_Emu. Various (2020). Pokey wiki. https://en.wikipedia.org/wiki/POKEY. any idea how good it is ? Quote Link to comment Share on other sites More sharing options...
foft Posted October 26, 2020 Share Posted October 26, 2020 No idea, was just trying to work out the vst plug-in api and if I could do a simple poc Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted October 27, 2020 Share Posted October 27, 2020 So, I may redo those sweeps in PAL, make them longer, then see if there is some correlation with the NTSC frequencies. I examined those waveforms too. They look very triangle-ish. In fact at high frequencies they sound like NES or that lead sound from the Pac Man opening. 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted October 27, 2020 Author Share Posted October 27, 2020 (edited) 19 hours ago, rensoup said: and its pokey emulation came out of nowhere ? Looks like it is a new implementation, started this year. https://github.com/Kautenja/PotatoChips/blob/master/src/POKEY.cpp https://github.com/Kautenja/PotatoChips/blob/master/src/dsp/atari_pokey.hpp A tsunami of TODOs Lots of polycounters not implemented yet, and there's no SKCTL (two-tone mode, poly resets). Edit: oh, it does mention SKCTL in the comments. But it's an ehm... todo Edited October 27, 2020 by ivop 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted October 27, 2020 Author Share Posted October 27, 2020 Here's another Pokey emulation (with roots in Ron Fries' pokey emulator. atari800 in 1997): https://github.com/mamedev/mame/blob/master/src/devices/sound/pokey.cpp It also does keyboard and pots, but no serial. 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted October 27, 2020 Author Share Posted October 27, 2020 19 hours ago, foft said: No idea, was just trying to work out the vst plug-in api and if I could do a simple poc poc? Piece of code? I assume the quality of your VHDL Pokey emulation is up to par with Altirra or even real hardware. How hard do you think it would be to port your code to C without relying on VHDL emulation? Quote Link to comment Share on other sites More sharing options...
sanny Posted October 27, 2020 Share Posted October 27, 2020 POC - Proof Of Concept 1 Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted October 28, 2020 Share Posted October 28, 2020 So ... I have, through judicious use of all the prime intervals, managed to get the note table of this setting almost all the way to C9 without severe tuning errors. Above C9 the detected frequencies get crazy so I don't know how much farther I will try to take it up. 1 Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted November 17, 2020 Share Posted November 17, 2020 OK ... preliminary note table! Some notes: There are two tables, the second is for the inverse triangle waves where the second frequency is greater than the first. Generating these involves reversing the values, except for values marked with a * that come from the $0505 intervals. In these cases the inverse value is also given. ivop (and anyone else): Please test these values to see if they are accurate. If so, I will add to my POKEY table. AUDCTL=$64 AUDC1=$AX AUDC3=$00.txt 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted November 19, 2020 Author Share Posted November 19, 2020 (edited) At first glance, it looks good. As I'm not really looking forward at checking eight octaves of notes by ear, I got this new idea Instead of playing batches of sweeps, play a predefined set of notes. Just like batch processing, it won't be a UI function, but a compile time function or even a separate application. Once you capture 8x12 notes, run it through aubiopitch and see if you did everything right Thanks for creating this table! Looking forward to hear some music made with it BTW here's the new thread: https://atariage.com/forums/topic/313338-pokey-explorer-v11-release/ Not sure what's the best idea. Keep discussion here, or move to the new thread? Edited November 19, 2020 by ivop 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.