i just got a chance to play with these and all of them besides 106 iirc produce a subtle click sound every few seconds. is this normal behavior?
I tried a couple of them and got the same thing.
106 uses maybe 10X or 20X the CPU that other VCOs use. Don’t really know what it’s trying to do in there.
All of the KautenjaDSP modules are emulators, so relatively high CPU usage is to be expected. See this issue for the developer’s thoughts on the subject.
CPU usage is improved in the latest version.
I’m not hearing any clicks.
The Namco 106 looks nothing like the picture in the documentation, so I think it’s a stray dev version that made it into a library build.
they all have the same audible click. i double checked 106 and it was present on that one also.
thanks. i’ll have to give them another try.
Hi everyone, thanks for the interest in these modules! @delexander is correct in that these are directly emulating the underlying chips, and thus are pretty resource hungry. For each audio sample, many “CPU samples” are running on the chip emulator. I’ve addressed the performance issue somewhat by running CV acquisition at 1/16x the sample rate and LED updates at 1/128x. It’s mostly noticeable for 106, but your experience may vary depending on the machine that you are using. The latest version, 1.3.1, contains these changes.
@Aria_Salvatrice is correct about 106, the first version snuck in by accident. The latest version of the plugin should have the actual 106. My bad for any confusion there.
@Squinky I think the version of 106 you are referencing was a development stub that snuck into deployment by accident. I’m getting about 6% CPU usage on a 2017 Macbook Pro at 48kHz sample rate with the module from the latest version (on battery with full charge). Let me know if performance is still bad for you though.
@persy, regarding the click, this is a problem with how the synthesizer back-end (it’s all BLIP-based) for the chip emulations is working with sample rates. You’ll hear the click when running at a sample rate with a value in the 100s place, e.g., 44.1kHz, 88.2kHz, etc. If you run any sample rate without a value in the 100s place, e.g., 48kHz, 96kHz, 192kHz, there shouldn’t be a click. You can track this issue of GitHub here, https://github.com/Kautenja/PotatoChips/issues/17, if you like. Hopefully I can get it resolved and released soon. Please let me know if you do still hear the click when running at sample rates of 48kHz or the like.
A final update! The 1.3.1 version of 106 has some other issues with sample rate and tuning that are resolved in 1.3.2 that is entering the release pipeline right now. For interested nerds, the issue that was tracking the fix can be found here https://github.com/Kautenja/PotatoChips/issues/16.
yes, much better now. Still not quite sure what it does, but it looks like a real plugin now. The CPU usage is still pretty high, but as far as I can tell it’s doing several things at once, so probably all is well. thanks!
i am still getting the click 48kHz.
@Squinky when I get some spare time I’ll put together a little bit of dev documentation describing how they work under the hood. Everything is based on the code originally written by Blargg to provide the PSG emulation that is needed for developing console emulators (like RackNES). The emulators need to do processing at a rate defined by the CPU clock – for instance, the NTSC version of the NES ran at ~1.78MHz – that originally processed the console’s machine code in order to run the games designed for the machine, i.e., the ROM files. As such, the PSG emulations are designed to be tightly coupled with this CPU emulation, and run at that clock speed. FUN FACT: All of these old PSGs actually ran at CPU rates to handle aliasing in a naïve fashion (see: Oversampling). Since there is no CPU emulation needed in most cases for these modules (save for the S-SMP from the SNES when I get around to it), the CPU has to be faked in accordance with the sample rate. That means for each audio sample, the chip has to process
SAMPLE_RATE steps to produce the sample that is cycle-accurate to the chips original logic.
Console emulator logic normally runs in a loop over video frames that runs at something like 60Hz or 50Hz. Within that loop, a number of CPU cycles are executed (
FRAME_RATE). I don’t believe this code from Blargg was ever really designed to run directly inside the audio pipeline like this and that’s perhaps why we’re seeing some inefficiencies and issues with the engine sample rate. Now that these first four modules are wrapped up, I plan to dive into the
Blip_Buffer code and see what can be done to fix the current issues and improve overall performance.
Hopefully that description helps some until I get a proper tech report done with figures and maths, but I’m happy to elaborate more if there are specific questions.
@persy would you mind providing some more information about your experience? I’m not able to replicate the issue at 48kHz in my production nor development VCV Rack environments (both MacOS & Ubuntu). I’m assuming this happens for all the modules in the plugin? If you could confirm with all four of them, I would greatly appreciate it.
OS (and version): Rack Version: Potato Chips Version: Engine Sample Rate: Audio Interface Sample Rate:
To clarify some ambiguity in my first post, the “sample rate” I’m mentioning there is the engine sample rate. The audio interface sample rate doesn’t seem to cause any issue for me if I put it on 44.1kHz (assuming the engine is on 48kHz or the like).
Good news, I’ve located the source of the click and believe to have fixed it. I’m still working on making the band-aid more permanent and cleaning things up before releasing. 2A03, VRC6, and FME7 are still detuned at sample rates of 44.1kHz, 88.2kHz, etc. for some reason, so I’m not quite to the bottom of the problem yet.
Version 1.3.4 is in the release pipeline now and should address the issues with sample rate for all modules in Potato Chips!