Proposal: different strategy for clap_processor_capabilities

[jatinchowdhury18]

So at the moment, if I'm trying to implement clap_processor_capabilities in a plugin, I run into the following problem:

clap_process_status MyPlugin::clap_direct_process (const clap_process* process) noexcept {
   ...
   // handle events
   case CLAP_EVENT_PARAM_VALUE:
   {
        // my code here...
   }
}

We recently merged a fix that stops parameter events here from triggering a "runaway" series of events, but when implementing this manually, I can't do that, because my plugin does not have access to supressParameterChangeMessages.

---

However, I think this leads to a little bit of a larger conversation about how we make it possible to implement CLAP-specific behaviour. I think in a lot of cases, the folks implementing clap_processor_capabilities will mainly want two things:

• A way to handle events that JUCE doesn't have a default way to handle (e.g. parameter modulation)
• A way to "split" the processing blocks in such a way as to handle those events in a more sample-accurate way

The second thing we're already looking at with #76, so I wonder if it makes sense to implement two "versions" of clap_processor_capabilities:

• clap_processor_advanced_capabilities could work like the current situation, where the user just has to implement all of clap_direct_process()
• With clap_processor_basic_capabilities, the wrapper would not call clap_direct_process(), but would allow the implementer to define specific behaviour for handling certain events (i.e. "I want my plugin to handle all events using the default behaviour, except for parameter modulation, where I want to do my own thing").

(There should probably be better names than this obviously.)

The secondary advantage here is that when we make improvements to clap-juce-extensions (for example implementing the bypass signal path), folks who are implementing custom behaviour can still get those improvements automatically.

I guess one potential drawback is that this could make the wrapper less compatible with a future JUCE CLAP implementation.

---

Anyway, I'm curious if folks think this could be a good idea?

[baconpaul]

So a very interesting thing we could do, which would obviate the need for clap_direct_process in the surge case, would be as follows

1. Do the sample splitting
2. Add two new methods to the capabilities class
   • handle_unhandled_clap_event(const clap_event *)
   • generate_block_output_events(const clap_output_list_thingy *, uint32_t base_sample)

then modify the ::process to call the first in the default: block of the event traverse and the second after the sub-block traversal (with the starting sample offset so you can decorate your outbound events)

with this i think i could write surge without a process direct.

see what i mean?

[baconpaul]

So I think we now have this done! I'm closing this. Cool stuff!