CLAP: The New Audio Plug-in Standard (by U-he, Bitwig and others)

[Steve Folta]

I've done the same thing with the Airwindows plugins. I'm not sure what baconpaul means when he says it's "not [a] very reasonable UX".

[baconpaul]

Oh I mean "most users wanted a single plugin with all the airwindows, not to get 378 entries in their plugin ui under the airwindows category". here's the way we are doing it now https://github.com/baconpaul/airwin2rack but the underlying static library that builds could super easily make a single-clap-with-multi-plugin.

For one of my '7 plugin testbeds' I use this though and it's how we tested the wrappers too. Works great for that.

and here's the way i did it first more akin to what you have above https://github.com/baconpaul/airwin2clap

was very useful to test clap scaling though at the 0.26 point and so on but almost the first request was 'how do you not show some of these' hence the consolidated model for rack and daws.

[Music Engineer]

In my simple delay plugin, there's only one plugin available. But I'm about to begin writing some other plugins, e.g. chorus, phase shifter, etc., and now I'm wondering if I should make them part of the same project. That's to say, the compiled CLAP file would tell the host that there are x number plugins available and create instances of them when requested by the host to do so.

Has anyone done this? How do the resulting plugins show up in the host? Are the listed as though they are separate plugins?

I can see the attractiveness of this approach. I'm creating simple free (when they're released) plugins and having a single file that gives you all of them would be kind of cool.

Thanks for any info.

Yes - I have done this as well. It's here:

https://github.com/RobinSchmidt/RobsClapStuff

just in case you need a more minimalistic example for how to do it. It's only a couple of GUI-less plugins - a sort of "AGain" example for clap. I also prefer to put all plugins into a single .dll over having a separate .dll file for each plugin because common code (like GUI framework and/or DSP library, etc.) can easily be shared among the plugins which is much more economic, especially if you have many plugins.

My plan is to put the code on GitHub if this modest attempt isn't completely embarrassing.

That would be great. It's always good to have a lot of code examples available to learn from.

[tasmaniandevil]

Has anyone had any trouble implementing a bypass parameter with Reaper?

Try their latest developer build.
We had reported a problem, and they changed something.
It's not completely fixed for us yet, but maybe your problem is solved.

[Leslie Sanford]

Try their latest developer build.
We had reported a problem, and they changed something.
It's not completely fixed for us yet, but maybe your problem is solved.

Thanks for starting that thread. I've downloaded the latest developer build, and I'm still having problems. The behavior is slightly different, though. Before, every time my plugin sent a bypass on event, Reaper would immediately respond with a bypass off event. It no longer does that. However, it's not responding to my bypass change events nor is it sending bypass on events, only off events.

I'll keep an eye on that thread and may chime in.

EDIT: I see from the Reaper thread that you've solved this at the plugin level. I'm pretty sure at this point that it must be a bug on my end. I think I need to dig deeper into state management when the plugin has been bypassed. I'm looking at the start/stop callbacks as well as the flush function.

EDIT2: Got it working. I wasn't properly handling plugin state when it was offline, i.e. bypassed. I assumed that the process function would still be called in a bypass state. Once I realized that wasn't the case (duh) and properly hooked into the start/stop callbacks as well as requesting a flush in response to changing the bypass parameter in the UI, it works like a charm.