Could reset output buffer within PDR be dangerous?

DSP, Plugin and Host development discussion.
RELATED
PRODUCTS

Post

Hi all,

I'm resetting the output buffer within the ProcessDoubleReplacing function I've implemented for a Synth I'm making with IPlug/C++:

Code: Select all

void MySynth::ProcessDoubleReplacing(double **inputs, double **outputs, int nFrames) {
	double *left = outputs[0];
	double *right = outputs[1];
	memset(left, 0, nFrames * sizeof(double));
	memset(right, 0, nFrames * sizeof(double));
	
	// ... code
}
And I was thinking... can this be dangerous?
I know DAW could pass the "input buffer pointer" to another plugin.
Can it do the same for the output buffer?

Let say I've two instances of the plugin loaded, and DAW share across them the same output pointer: the result of the first PDR will be resetted once it pass the same buffer to the second instance, where it process its PDR and run memset again.

Is this scenario possible?
Thanks

Post

You are just setting data to the buffer for the requested amount. Why should that be dangerous?
~stratum~

Post

stratum wrote:You are just setting data to the buffer for the requested amount. Why should that be dangerous?
Yes, I'm setting (resetting) the buffer to 0 for every sample once I call PDR.
But is that buffer "unique" (for each loaded plugin)? Or can be shared between different instances (of the same plugin for example) into the DAW?
For the input buffer this could be possible for what I've learned...

Post

But is that buffer "unique" (for each loaded plugin)? Or can be shared between different instances (of the same plugin for example) into the DAW?
For the input buffer this could be possible for what I've learned...
If that API does not work as intended, the whole VST spec would be thrown to the trashcan. Therefore it looks pretty safe as long as you don't touch the input buffers.
~stratum~

Post

stratum wrote:If that API does not work as intended, the whole VST spec would be thrown to the trashcan. Therefore it looks pretty safe as long as you don't touch the input buffers.
I can't see in the official documentation where its written that every instance of plugin must receive its own dedicated output buffer memory and input can instead be the same between instances.

Both input and output are double **, I made it up that DAWs will manage them as they want?
That's why I ask if it could introduce any problem...

Post

If I may ask, why reset the output buffer for every block ?

There's ::Reset() already inplemented in iPlug which afaik gets called back from the host when processing starts or restarts (e.g after stop / play) so I just cleared my buffers there and it seemed fine, wouldn't that suffice ?

But I only did a few simple synths with iPlug yet, so I'm curious if it's better (in some cases) to clear buffer for every block.

Post

Even God cannot make two mountains without a valley in between. ~ Gaelic Proverb (quoted from http://proverbicals.com/mountain/)

Therefore what you do is safe, because otherwise the API wouldn't work. I guess you need to take a break and have some fresh air.
~stratum~

Post

stratum wrote:I guess you need to take a break and have some fresh air.
:) Funny, the dubt has grown to me where I was in pause :wink:
stratum wrote:Therefore what you do is safe, because otherwise the API wouldn't work.
Which API do you mean? That method is simply called by DAW, isn't?
The DAW decides what to pass to it.
Is it simply taken for granted?

I can't test plugin on every DAWs, so I wasn't sure its the correct way.
I trust you anyway :)

Post

If you can't reset the output buffer how would it ever be safe to write anything there?

Post

matt42 wrote:If you can't reset the output buffer how would it ever be safe to write anything there?
Well, maybe I also need to manage it? As check if its the first processed buffer, thus reset with 0s and than add data, and on the following (which already contains data), just put only += newValue.

I don't know since its not written in the documentation, that's why I ask to you :) Maybe I was wrong the attempt ;)

But it seems from your comments that the "shared" buffer can only be the input one, and theres an output one per-instance ;)

Post

The documentation is not so good. There are no guarantees for the input buffer. So Juce, for example, is smart and passes a const pointer for the input.

But seriously, you need to write to the output buffer. If some writes are ok and others not how would that ever work? It wouldn't.

Post

That's the whole point - you *must* replace whatever was in the buffer with the output of your plugin. That's why it's called ProcessDoubleReplacing :wink: . In fact, it's illegal to NOT replace what was in the buffer because it could have values like INF or NAN (which you don't want to pass downstream into the effects). It's very likely that it will contain garbage from previous tracks (which the host expects you to wipe out and replace with your output).
Last edited by MadBrain on Mon Oct 02, 2017 9:26 pm, edited 1 time in total.

Post

It's like an implicit social contract or unwritten law. If somebody passes a buffer to your function and calls it 'output' then it's safe to write:) If the buffer is a member variable (or a global), only then I would look for other usage restrictions, such as whether a mutex needs to be locked or not (but that doesn't make sense in an audio thread anyway and would be a pretty bad interface, also. Sometimes what makes sense or what doesn't is an implicit unwritten 'documention' - it's common sense and it would be totally awkward to do it otherwise - imagine an interface in which you are given a buffer to write to and a mutex required to access it as a callback function parameters, and the buffer needs to be written immediately by that callback, what would you think about the author? what if that mutex is a member variable but the buffer is a function argument? I'd say he's probably smoking something really weird in both cases.)

Newer languages have keywords to mark such things (like c#'s out keyword), but c++ is a bit old, and this style is well known.
~stratum~

Post

Yes yes, I know I need to write to the output buffer. That's pretty obvious, I agree :)
My concern was about "reset" that buffer at the beginning of each PDR call, because if its treaty as the "input" (i.e. it could be unique and shared across instances) it could create lot of problems. That's all :)

Its a matter of what DAW will do rather than bad specs. Since there isn't any full documentation, and we all know that DAW do whatever they want (:D), I found it a fancy question, sorry :ud:
No_Use wrote:If I may ask, why reset the output buffer for every block ?

There's ::Reset() already inplemented in iPlug which afaik gets called back from the host when processing starts or restarts (e.g after stop / play) so I just cleared my buffers there and it seemed fine, wouldn't that suffice ?

But I only did a few simple synths with iPlug yet, so I'm curious if it's better (in some cases) to clear buffer for every block.
For what I know, ::Reset() in IPlug is called when "start/end", or change samplerate, or specific function that need to "reset" the plugin, not the buffer itself.

So I need to reset the buffer to 0 before add/build up my signal. Else it could start to "add" from garbage stuff (as MadBrain).
Let say your synth output a sine. The sine values need to start from "0" for each sample, not from (old) garbage values.

Post

matt42 wrote:If you can't reset the output buffer how would it ever be safe to write anything there?
This!

The OP question doesn't make sense.

Post Reply

Return to “DSP and Plugin Development”