I’ve got a few modules that I think are ready for a small-ish release. I wanted to ask about the typical release workflow: is it recommended to ask for beta testers, and then release to the VCV Library, or release to the VCV Library first, and then ask people to test?
I think it’s best to ask for beta testers before submitting to the VCV Library. Each time you submit to the Library, it will go through their review process prior to being available to users. The more complete your plugin is before submitting, the less time you and they will spend on reviewing/waiting.
The modules are pretty nice,
but I might have found a bug,
the Tape sometimes gets pretty distorted when it seems to be overloaded.
and the distortion is still there even when I stop the sequencer and don’t pass any sound through “Tape” and after a few seconds I turn the sequencer and clock on again, the distorted sound is still there.
I know that I have build a very unusual routig with feedback, but I just would let you know.
And I think this is what beta testing is for
@rsmus7, seems like a stability issue… The magnetic hysteresis model that I use can be a little bit finnicky when it gets overloaded, especially without internal oversampling (which I’m still trying to figure out if I can do within the Rack API). In my plugin version I only offer +6dB of input gain within the plugin, and try to instruct the user to keep the overall levels at or below unity going into the plugin, and this seems to work reasonably well. Obviously, in Rack it’s much more difficult to keep track of gain staging from module to module.
There are solution’s but there’s always tradeoffs: I can use a smaller alpha coefficient for the alpha transform, but this will add some high-frequency damping. I can also switch from using a 2nd-order Runge Kutta solver to a Newton-Raphson solver, which is more computationally expensive. In my opinion, these tradeoffs are worth it for a more robust module, so users don’t have to worry about things like this, and can go about their patching fearlessy. Anyway, I’ll get these implemented soon…
By the way, very cool patch! Not sure if that seems run-of-the-mill to you more experienced folks, but as a relative newbie, I’m amazed at what you modular wizards come up with .
Anyway, sorry to get a little bit technical. I’ll actually be off-the-grid the next few days, but I’ll be sure to check back at this thread when I return.
Still a few more things I’d like to add before the next release, but I wanted to let you all know about some changes and see if anyone wants to try the latest builds:
I’ve added 4x internal oversampling to the CHOW Tape module. This helps to avoid aliasing artifacts, and improves the module stability. I could go to higher oversampling factors, but I think 4x is a good compromise to supress aliasing without taking up too much CPU.
In CHOW FDN, I’ve switched my delay lines from using sinc interpolation to 3rd-order Lagrange interpolation. This greatly reduces the CPU footprint.
I’ve added a new module, a recurrent neural network with 4 inputs. I’ve had some fun using this as a distortion-type effect, but it can come up with some kind of strange and interesting results. Eventually, I’m hoping to add some pre-trained networks to this module.
For developers:
I’ve made a generalised oversampling class to use for the tape module. It uses an arbitrary order Butterworth filter for anti-aliasing and anti-imaging. It should be pretty easy to set up for use in any module, as well as extend to use different filters if you prefer. Check it out here!
Just finished some updates in preparation for a new release. If anyone wants to try out the latest builds, those can be downloaded here. Updates include:
New virtual analog distortion module (“ChowDer”). I had some fun modelling a couple old circuits using some Wave Digital Filter code I wrote a few months back. If any other developers want to use my WDF code for their own circuit models, I’m more than happy to help out (plus it’s all open source ).
Updated GUI designs for all modules, courtesy of my friend Margus (I don’t think he’s on the forum yet).
Small performance improvements for all modules, especially the Tape module.
For devs: The performance improvements were aided by a benchmarking app that I made, inspired by @Squinky. The approach is a little bit tricky to get set up, but it’s nice in that it benchmarks the modules directly rather the internal DSP functions, so it should be pretty generalisable to anyone else’s modules as well. For more information, see here.
Oh, that’s cool. It sounds like you linked in rack code so that you can benchmark your plugin binary directly? That’s nice. Always wanted to do that… never did.