Post by verklagekasper on Jan 27, 2016 20:34:23 GMT 1
Hi, after I've spent a day with tracking down a weird crackling noise, I finally found the cause of the problem. So here's a word of warning:
Do not use pin.getBuffer(). Always use getBuffer(pin) instead. They look equivalent, but in fact getBuffer(pin) == pin.getBuffer() + getBlockPosition().
For explanation, assume you had a subprocess like this:
1. The SDK executes subProcess(3) to generate the first 3 samples.
2. The SDK calls onSetPins() such that the event can get processed.
3. The SDK executes subProcess(97) to generate the remaining 97 samples.
Now the buffer that subProcess would receive in step 1 would cover the samples 0-2. So in step 3, you'd expect a buffer covering samples 3-99. But you'd receive exactly the same buffer as in step 1! So you'd write samples 0-96 rather than 3-99, overwriting the 3 samples you generated already in step 1, and miss the last 3 samples.
Frankly, use getBuffer(pin). That call adjusts the buffer beginning properly when subProcess isn't executed in one go but gets interrupted by events. Btw I think that pin.getBuffer() should not be public but private to avoid this pitfall (If someone still needs it, it can simply be computed as getBuffer(pin) - getBlockPosition()).
Cheers,
Burkhard
Do not use pin.getBuffer(). Always use getBuffer(pin) instead. They look equivalent, but in fact getBuffer(pin) == pin.getBuffer() + getBlockPosition().
For explanation, assume you had a subprocess like this:
void MyPlugin::subProcess( int sampleFrames )
{
float* out = pinOut.getBuffer() // wrong!
...
}Now the following can happen: The host requests 100 samples from the subprocess, and there's a pinset event at timestep 3. SDK3 would process this as follows:1. The SDK executes subProcess(3) to generate the first 3 samples.
2. The SDK calls onSetPins() such that the event can get processed.
3. The SDK executes subProcess(97) to generate the remaining 97 samples.
Now the buffer that subProcess would receive in step 1 would cover the samples 0-2. So in step 3, you'd expect a buffer covering samples 3-99. But you'd receive exactly the same buffer as in step 1! So you'd write samples 0-96 rather than 3-99, overwriting the 3 samples you generated already in step 1, and miss the last 3 samples.
Frankly, use getBuffer(pin). That call adjusts the buffer beginning properly when subProcess isn't executed in one go but gets interrupted by events. Btw I think that pin.getBuffer() should not be public but private to avoid this pitfall (If someone still needs it, it can simply be computed as getBuffer(pin) - getBlockPosition()).
Cheers,
Burkhard