Need help getting my VST to process audio


#1

Hi I'm new here, I've been working on a simple compressor vst for a class at school and I've followed the juce tutorial found at redwoodaudio's website but with a simple compressor class that I found on the musicdsp website.  My code compiles and the vst sliders move properly but when I load my vst into a DAW like energyXT and link the components together in the modular window so that midi in goes to sequencer, sequencer to synthesizer, synthesizer to compressor, compressor to a spectrum analyzer in order to see if anything is actually happening, and then from the spectrum analyzer to the audio out.  But when I actually play with the slider's on my VST there is no visible difference on the spectrum analyzer so I'm afraid that it isn't actually operating on the output from the synthesizer.  I'm working on Windows if that helps and I have my project files ready if someone would be willing to help point out where the flaw is?


#2

Well, as a starter, you could just set the gain to zero in your audio processor and see if audio stops coming out.  Just in the processBlock bit zero the buffer (buffer.applyGain(0.0f) ought to do it).  

Then at least you'll know whether it's a coding error, or just an error in your test setup.


#3

I replaced the code in the processBlock with the buffer.applyGain and when I test the output stops coming out when I do not bypass the compressor so I think that means the testing environment is set up, that narrows it down to a coding error?


#4

That's a pretty good start.  Ok - maybe post the code from your processBlock?


#5

Okay so my processBlock looks likes so:


void CompressorAudioProcessor::processBlock (AudioSampleBuffer& buffer, MidiBuffer& midiMessages)
{
    // In case we have more outputs than inputs, this code clears any output
    // channels that didn't contain input data, (because these aren't
    // guaranteed to be empty - they may contain garbage).
    // I've added this to avoid people getting screaming feedback
    // when they first compile the plugin, but obviously you don't need to
    // this code if your algorithm already fills all the output channels.
    for (int i = getNumInputChannels(); i < getNumOutputChannels(); ++i)
        buffer.clear (i, 0, buffer.getNumSamples());
    // This is the place where you'd normally do the guts of your plugin's
    // audio processing...
    if (getNumInputChannels() < 2 || UserParams[MasterBypass]){}
    else{
        //buffer.applyGain(0, buffer.getNumSamples(), 0.0f);
        double* leftData = (double*)buffer.getWritePointer(0);
        double* rightData = (double*)buffer.getWritePointer(1);
        for (int i = 0; i < buffer.getNumSamples(); i++){
            mCompressorControl.process(leftData[i], rightData[i]);
        }
    }
}

Where mCompressorControl is a SimpleComp object from the compressor class I mentioned in the first post.

Here's a link to the github where I found the class definition code available:  https://github.com/music-dsp-collection/chunkware-simple-dynamics


#6

Presumably that buffer is a single precision floating point buffer, but you've cast it to a double!  That isn't going to work.  Go read about casting and floating point numbers and have a think about it.

You are asking the compiler to just assume that the buffer contains doubles, even though it actually has floats in it. 

You actually want to read the float, as a float, convert it to a double and then run the process.  You could do this a block or a float at a time.    

E.g.

float f = buffer[sample_number];

double d = static_cast<double>(f);

process(d);

buffer[sample_number] = static_cast<float>(d);

When you convert the float (rather than the float *) to a double the compiler actually has the float in a register and emits an instruction (on intel) something like cvtss2sd which upgrades the float to a real double.

See example on godbolt: http://goo.gl/zlpEkL

Conversion can be a slightly slow operation* and if it makes no difference to the quality it's sometimes better to convert the processing code to avoid having to do this type of  conversion.

 

*apparently is the demotion to a float that's slow the upgrade to a double is relatively speedy I just discovered...!


#7

Wow that totally fixed thank you so much!  I guess I didn't understand casting properly you've taught me a very valuable piece of information.  I'm so happy you could help me I hope you have an amazing life.


#8

Awesome!  Always good when it starts working :)