I’ve written a plugin for VCVRack which has recently been upgraded to v1.x with some great help by the kind Jerry Sievert and Netboy3. Before submitting this new version for inclusion in the library I would like to solve one problem which is a great nuisance. Btw. the plugin is called Vocode-O-Matic (published under the name Sculpt-O-Sound). When starting with an empty Rack (using the SDK version of Rack) and loading the plugin and setting up a simple patch all is fine. The vocoder does what it is supposed to do. If I then restart Rack, it will load the latest patch and then EITHER there is a loud humming noise that lasts for several seconds and then I hear the vocoder slowly fading in, OR there is no sound at all and the vocoder does not seem to produce any output. In the latter situation if I then switch the vocoder in bypass mode, I can hear the carrier and modulator signal without a problem, so the plugin is responsive, but not in the intended way. Do I need to do some setup steps I may have forgotten to implement? I would appreciate any advice you may have. The code is here: https://github.com/josbouten/Sculpt-O-Sound/tree/v0.6_to_v1.1 Note that this is a development branch ( the main branch is still the Rack v0.6x version).
Can you provide a patch that you are testing this on? What platform and OS versions?
I find it very hard to read code quickly where it is broken into different files, but one thing I seen is which is usually still compatible with v1.x but deprecated.
xc = inputs[CARR_INPUT].getVoltage() * params[CARRIER_GAIN_PARAM].getValue(); xm = inputs[MOD_INPUT].getVoltage() * params[MODULATOR_GAIN_PARAM].getValue();
Also not too sure about
engineGetSampleRate() on line 90/91 I think this should be
args.sampleTime (preccess calling step)
Doesn’t seem to be fully migrated from looking through these few lines
You’re looking at an old commit history or the wrong branch. This line is correct in the latest version of the branch v0.6_to_v1.1:
Haven’t tested anything, but I’d add an
onReset in the module’s constructor.
In the onReset I initialise a few buttons. The filter taps are all initialised elsewhere to zero values before they are used, so there could not originate a sound from them. And anyway, there are 3 filter taps at max which all are replaced within 3 sample periods by real data, so even if they contained some random number that would hardly be audible as a loud hum for a second or so, rather that would be a spike. Following this logic the cause must be something different.
I’ve attached the patch. I’m running this on OSX Majove version 10.14.6 starting the SDK version of Rack using “make run”.vocode-o-matic_test_02.vcv (70.8 KB) The audio files are the examples in the git repository (jung05.wav and fl1_std.wav). The sound I hear is a loud low frequency that increases in volume and then changes in the vocoder output sound in sort of a slow fade. The vocoder then continues at its normal volume. The transition takes a few seconds.
I could not reproduce it on Linux (which is my main dev platform). Let me build and run it on my MacBookPro (also with Mojave) and see if it’s reproducible there. I assume you use VCV 1.1.5 for both SDK (building) and Rack (running).
Yes, I use the 1.1.5 version for both. The odd thing is, this does not happen every time I start Rack. At one occasion I had an audio track playing via safari while I started up Rack. The sound of the track already playing started to sound distorted. Only after exiting Rack the sound went back to normal. This may not be related, but I’m wondering might this can be an audio driver issue? I’m using a UMC4040HD as DAC. On the other hand I’m almost certain I’ve had audio failing to play when using the standard output device.
I just pushed a pull-request to you. It looks like the carrier tap filter array was not initialized. Once I initialized it, the issue went away for me. Please check it out and let me know.
Hmm, silly of me to miss that initialisation. I guess one can get blind to ones own code. But thanks for pointing this out. I’ll change the code and try whether this remedies the problem. Because the uninitialised carrier filter taps will be overwritten in 3 sampling periods, this however to me does not explain why now and then there is this hum sound for more than a second at start up. It does explain a loud initial tick like sound I often hear at startup.
If you’re implementing an IIR filter, future outputs have a dependency on previous outputs, so unitialized data will propagate indefinitely into the future.
To the best of my knowledge I’m using FIR filters.
That was the link from the first post, can only go on what is given!
The comment in the code example says “direct form 1”. I’m going to bet you have an IIR filter. I’ve made this same mistake before, and it can take a few seconds to recover.