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:
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.
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…
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.
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.
[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.
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.
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.