Either loud noises or no sound at all when starting Rack with plugin

josbouten · October 26, 2019, 11:56am

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).

netboy3 · October 26, 2019, 1:17pm

Hi Jos,

Me again

Can you provide a patch that you are testing this on? What platform and OS versions?

Coirt · October 26, 2019, 2:39pm

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.

github.com

josbouten/Sculpt-O-Sound/blob/5b64cf2957d8ce8cd006cd2f8719b73da8f8a5ec/src/Vocode_O_Matic_v0.4.cpp#L94


  params[CARRIER_GAIN_PARAM].value = INITIAL_CARRIER_GAIN;
  params[MODULATOR_GAIN_PARAM].value = INITIAL_MODULATOR_GAIN;
}


void Vocode_O_Matic::step() {
  // Do da vocoding thang.
  float deltaTime = engineGetSampleTime();
  float oneStepDeltaTime = engineGetSampleTime();
  bool refresh = false;
             
  xc[0] = inputs[CARR_INPUT].value * params[CARRIER_GAIN_PARAM].value;
  xm[0] = inputs[MOD_INPUT].value * params[MODULATOR_GAIN_PARAM].value;
  float smoothing_factor = 1.0;


  for (int i = 0; i < NR_OF_BANDS; i++) {
    //
    // CARRIER
    //  
    // Direct Form I topology is used for filtering. Direct Form II would in this case cost as many multiplications and shifts.
    yc[i][0] = carr_alpha1[i] * (xc[0] - xc[2] - carr_alpha2[i] * yc[i][1] - carr_beta[i] * yc[i][2]);
    //

Would be:

  xc[0] = inputs[CARR_INPUT].getVoltage() * params[CARRIER_GAIN_PARAM].getValue();
  xm[0] = 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

netboy3 · October 26, 2019, 2:50pm

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:

github.com

josbouten/Sculpt-O-Sound/blob/f42c7ef25953c8c8510643a0c13708594b3d19c3/src/Vocode_O_Matic_v0.4.cpp#L91


}


void Vocode_O_Matic::process(const ProcessArgs &args) {
  // Do da vocoding thang.
  float deltaTime = args.sampleTime;
  float oneStepDeltaTime = args.sampleTime;
#ifdef DEBUGMSG
  bool refresh = false;
#endif


  xc[0] = inputs[CARR_INPUT].getVoltage() * params[CARRIER_GAIN_PARAM].getValue();
  xm[0] = inputs[MOD_INPUT].getVoltage() * params[MODULATOR_GAIN_PARAM].getValue();
  float smoothing_factor = 1.0;


  for (int i = 0; i < NR_OF_BANDS; i++) {
    //
    // CARRIER
    //
    // Direct Form I topology is used for filtering. Direct Form II would in this case cost as many multiplications and shifts.
    yc[i][0] = carr_alpha1[i] * (xc[0] - xc[2] - carr_alpha2[i] * yc[i][1] - carr_beta[i] * yc[i][2]);
    //

stoermelder · October 26, 2019, 3:07pm

Haven’t tested anything, but I’d add an onReset in the module’s constructor.

josbouten · October 26, 2019, 8:34pm

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.

josbouten · October 26, 2019, 8:43pm

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.

netboy3 · October 26, 2019, 8:53pm

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).

josbouten · October 26, 2019, 9:00pm

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.

netboy3 · October 27, 2019, 12:49am

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.

josbouten · October 27, 2019, 10:40am

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.

Vortico · October 27, 2019, 10:44am

If you’re implementing an IIR filter, future outputs have a dependency on previous outputs, so unitialized data will propagate indefinitely into the future.

josbouten · October 27, 2019, 10:46am

To the best of my knowledge I’m using FIR filters.

Coirt · October 27, 2019, 1:33pm

That was the link from the first post, can only go on what is given!

Squinky · November 29, 2019, 5:31pm

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.