ARGH! I don't like the way process processreplacing works


#1

It sends the entire thing to a processblock function… which has these functions J built like ApplyGain, etc.

I definately like the simplicity of Tobybear’s Template because you decide exactly how you want it to work… it passes you the pointers and you go to work on the pointers based on the number of channels. Maybe it’s cause I’m not familiar to with this C stuff… but this section is completely unintuitive to me. It makes no sense compared to how it’s done in Delphi.

I mean it’s cool if all you want to do is process sound… but I wanted to try porting one of my little konstrux plugs… which are stupid simple.

Why can’t I get the damn thing to simply pass the “value” of the Gain slider on the outputs of the plugin!. I don’t want it to be assumed audio… I want to pass a straight value… that’s it. ARGH!

At this point the only thing I can think of is to bypass it all together, and have process and processreplacing call my own function. :evil:


#2

Ignore me… although I have not quite figured it out… the VST SDK works like the delphi template (or should I say vice versa) which makes more sense to me… I don’t understand all those audiosamplebuffer routines… :? So I’m gonna skip the buffer stuff and try it how the VSTSDK works.


#3

it’s not too bad, as far as I can tell from the docs.

If I’m reading it right, all you need to do is call

getSampleData(0,0) to get a pointer to the left channel

and

getSampleData(1,0) to get a pointer to the right channel

the getNumSamples field will return you the amount of samples you can process

so

double* p;
int i;

i=getNumSamples;
p=getSampleData(0,0);
for (int j=0; j<i; j++)
{
  *p=0.1;
  p=p+1
}

should fill the left channel with the val 0.1


#4

I ended up replacing it with the VST SDK stuff… which works as I would expect.

I’ll try it the way you suggested tho… thanks! :slight_smile:

[code]void DemoJuceFilter::processBlock (float** inputs,
float** outputs,
long sampleFrames,
const bool accumulate)

{
if (accumulate)
{
float *in1 = inputs[0];
float *in2 = inputs[1];
float *out1 = outputs[0];
float *out2 = outputs[1];

    while (--sampleFrames >= 0)
    {
            (*out1++) = gain;    // replacing
            (*out2++) = gain;
    }

    // if we're accumulating, we should add to the existing contents of the
    // output buffer..

}
else
{
    float *in1  =  inputs[0];
    float *in2  =  inputs[1];
    float *out1 = outputs[0];
    float *out2 = outputs[1];

    while (--sampleFrames >= 0)
    {
            (*out1++) += gain;    // accumulating
            (*out2++) += gain;
    } 
}

}[/code]


#5

also, any solutions regarding the lib and gettting the filesize down (hinted at in the other threads me thinks). This little thing is 1.2M which is 3x the size of my delphi version… which already way too big…


#6

strip’ll get it down to about 700k, but to shrink it lower than that we need to work it out so that JUCE can be compiled as part of the overall app, not precompiled into a .a file.


#7

What a bunch of hackers!

Here’s why AudioSampleBuffers are better than just passing in arrays:

  • When I add build tools for AudioUnits, DX, etc., they’ll act as a portable layer between your code and whatever the native format is
  • They contain methods for dsp operations on the data that could in future be optimised for whatever CPU you’re running on
  • You can also use them to hold your plugin’s internal data buffers, and if you need to resize them, you just call the setSize method.
  • It’s a bit saying you’d rather use char* arrays instead of String objects!

And valley please don’t bother trying to compile juce directly into your plugin! You’ll waste days getting it to work, and it won’t make any difference - the libjuce.a file is just an archive of precompiled object files. MSVC does a much better job of making smaller executables than mingw, but you can always run UPX on it after stripping it, and it should get down to a few hundred K.


#8

[quote=“jules”]
And valley please don’t bother trying to compile juce directly into your plugin! You’ll waste days getting it to work, and it won’t make any difference - the libjuce.a file is just an archive of precompiled object files.[/quote]

OK. Good to know that it isn’t just sticking the whole library in the exe.


#9

[quote=“ModuLR”]I ended up replacing it with the VST SDK stuff… which works as I would expect.

I’ll try it the way you suggested tho… thanks! :slight_smile:

[code]void DemoJuceFilter::processBlock (float** inputs,
float** outputs,
long sampleFrames,
const bool accumulate)

{
if (accumulate)
{
float *in1 = inputs[0];
float *in2 = inputs[1];
float *out1 = outputs[0];
float *out2 = outputs[1];

    while (--sampleFrames >= 0)
    {
            (*out1++) = gain;    // replacing
            (*out2++) = gain;
    }

    // if we're accumulating, we should add to the existing contents of the
    // output buffer..

}
else
{
    float *in1  =  inputs[0];
    float *in2  =  inputs[1];
    float *out1 = outputs[0];
    float *out2 = outputs[1];

    while (--sampleFrames >= 0)
    {
            (*out1++) += gain;    // accumulating
            (*out2++) += gain;
    } 
}

}[/code][/quote]

I know its wrong, but I’m used to this sort of processing block, I tried the above code and got:

'void DemoJuceFilter::processBlock(float **,float **,long,const bool)' : overloaded member function not found in 'DemoJuceFilter' I like putting the dsp right in there like that… I’m sure he modded it more to get it to work that way…
~Rob.


#10

Yeah - note the fact that this thread is 6 years old. The plugin classes have changed beyond recognition since then.


#11

Oh, thats embarrassing right there… ughh :oops:


#12

Well, this is how I have it setup now, thanks to some help:

[code]void DemoJuceFilter::processBlock (AudioSampleBuffer& buffer, MidiBuffer& midiMessages)
{
float *spl0 = buffer.getSampleData(0);
float *spl1 = buffer.getSampleData(1);

for(int i=0; i<buffer.getNumSamples();spl0++,spl1++,i++)
{
*spl0 *= gain;
*spl1 *= gain;

}
}
[/code]

Works great!

Now on to custom look and feel!

~Rob.


#13

Another approach would be to treat your pointers to the inputs as arrays:

void DemoJuceFilter::processBlock (AudioSampleBuffer& buffer, MidiBuffer& midiMessages)
{
   float *spl0 = buffer.getSampleData(0, 0);
   float *spl1 = buffer.getSampleData(1, 0);

   for(int i=0; i<buffer.getNumSamples();i++)
   {   
   spl0[i] *= gain;
   spl1[i] *= gain;

   }
} 

I’ve had issues in the past that have been solved by the above method. If you want to work with a block of samples, as opposed to sample-by-sample, array addressing is quite useful.

Sean Costello


#14