Can plugins modify input buffers?

[jaxter184]

Ignoring the special case of in-place processing, are there any requirements or restrictions imposed on the host/plugin regarding whether or not the plugin can modify the input buffer? For example, is a plugin allowed to use the input buffer as a sort of scratch space to help with processing?

[tim-janik]

Ignoring the special case of in-place processing, are there any requirements or restrictions imposed on the host/plugin regarding whether or not the plugin can modify the input buffer? For example, is a plugin allowed to use the input buffer as a sort of scratch space to help with processing?

No, the plugin must not modify the input buffers, that's indicated by the const in const clap_audio_buffer_t *audio_inputs;, part of clap_process_t. If a plugin needs scratch space for processing, allocate that space in clap_plugin_t->activate() and release the memory in ->
deactivate(). That's what the parameter max_frames_count is for.

[robbert-vdh]

Just keep in mind that the const in const clap_audio_buffer_t *audio_inputs does not actually prevent the plugin from writing to audio_inputs[port_idx].data32[channel_idx][sample_idx]. Or reassigning the audio_inputs[port_idx].data32[channel_idx] pointer for that matter. Const does not propagate in C or C++.

[baconpaul]

yes it is an 'intentional' const but not a 'practical' const. Would be lovely if C had a way to say a const point of const floats more easily. But unless things overlap I agree with tim, the intent and the practical advice is don't write on your input. And if they overlap you've already said that's OK and the DAW has chose to overlap for you. So "never write to in"

[jaxter184]

I think if this is meant to be a strict requirement, then it should be clearer either in the API or the documentation. I think the ideal change would be for the input buffer and the output buffer to be different types, one with const pointers and the other without:

typedef struct clap_audio_input_buffer {
   const float const* const* data32;
  // ...
} clap_audio_buffer_t;

typedef struct clap_audio_output_buffer {
   float **data32;
  // ...
} clap_audio_buffer_t;

The sprinkling of consts is almost certainly wrong; I'm unfortunately not great with C. But regardless, in addition to clarifying what is allowed, I feel like this also makes the audio buffer API more consistent with the event buffer API, where the operations that can be performed on the output are different from the operations that can be performed on the input. (For reference, here is the commit that did this same split for the event buffer)

Of course, if there ends up being some reason that this change can't be made, it would be nice if there was at least a comment that clarified that the const clap_audio_buffer_t means that the buffer should not be edited. Based on the context, it seems like a reasonably proficient C programmer can see that const is technically useless, and should therefore be interpreted to implicitly propagate down to the floats in the buffer. However, I don't think it's sufficiently clear (at least for me and my puny Rust brain) as it stands now, and as far as I can tell, there is technically nothing in the specification that prevents them from editing the input buffers (except for this discussion), and I think a comment along the lines of "input buffers should not be edited" above the definition of clap_audio_buffer_t would be sufficient to convey that restriction.

[spongeboburu]

It's convenient to have compatible types for the frame buffer, for instance when using the output of one plugin as the input of another by just switching the memory pointed to by data32/64. const float ** and float ** are incompatible pointer types and can thus not be switched as easily. Typecasting const storage to non-const will still incur undefined behavior if stored to.

My personal take on the const here is "this aggregate and all of it's members and nested members are read only". const is commonly used as a hint to the programmer like this rather than compiler optimization. That said, easy to fix the documentation by adding "Input buffer is read only".

As a footnote, const float * and float const * are synonymous. The qualifier affects the object to it's left in the syntax.