About CLAP

[carlca]

I was interested to hear in Moss's video that bindings would be made available to enable Delphi to be used for plugins. Is this likely to be extended to Free Pascal/Lazarus? That would make sense because Free Pascal is truly cross platform, whereas with Delphi, although you can compile to different OS targets, the actual development has to be done in Windows.

[moss]

I was interested to hear in Moss's video that bindings would be made available to enable Delphi to be used for plugins. Is this likely to be extended to Free Pascal/Lazarus? That would make sense because Free Pascal is truly cross platform, whereas with Delphi, although you can compile to different OS targets, the actual development has to be done in Windows.

Didn't do Pascal since my school days
Maybe you can ask here: https://github.com/Bremmers/CLAP-for-Delphi

[carlca]

Didn't do Pascal since my school days
Maybe you can ask here: https://github.com/Bremmers/CLAP-for-Delphi

It's come a long way. I had a 20 year career in Delphi. I've now switched to Free Pascal/Lazarus and it is pretty darn good. Here it is running under macOS...

Screenshot 2022-03-11 at 23.49.48.png

I'll check out that site you mentioned. Thanks!

[syntonica]

There is a free Community Edition for Delphi for Mac. It's huge. Like ~8Gb huge, iirc.

Free Pascal works, but it's kind of a Frankenstein's Monster and lurches forward with a similar pace and gait. I'm not sure how it feels about ARM64, though. It'll probably do it, but I haven't looked at in a couple of years.

[carlca]

That would make sense because Free Pascal is truly cross platform, whereas with Delphi, although you can compile to different OS targets, the actual development has to be done in Windows.

There is a free Community Edition for Delphi. It runs on Windows. It is able to cross-compile for various OS targets, including macOS and Linux. That would be why I wrote what I wrote. See quote above.

[TaoTeo]

This is so exciting! Can't wait to see what the future holds

[Hanz Meyzer]

Is CLAP production ready, or let's say, does it already work for the most of VST3 features, can it be used in new plugin projects right now?

[Urs]

Is CLAP production ready, or let's say, does it already work for the most of VST3 features, can it be used in new plugin projects right now?

No, not yet. But it has become quiet since V0.23, so I think the officially stable V1.0 is near.

[Benutzername]

I've looked at the available docs but I couldn't find what the rules of deployment are. Is it strictly defined where CLAP plugins must be installed on all platforms or is it completely up to the plugin and host to find each other (like VST2)?

[mystran]

I've looked at the available docs but I couldn't find what the rules of deployment are. Is it strictly defined where CLAP plugins must be installed on all platforms or is it completely up to the plugin and host to find each other (like VST2)?

Actually for VST2 there's a standard location on macOS and a standard registry key (which stores the VST folder path) on Windows. While you can certainly also put your plugins elsewhere (as long as you tell your host where to find them), most installers at least default to these.

I guess on macOS it'd make sense to put CLAP plugins to Library/Audio/Plug-Ins/CLAP since this would mirror all the other plugin formats. On Windows where people are likely to want more variance, it would probably make sense to specify a registry key (as with VST2)?

[Benutzername]

and a standard registry key (which stores the VST folder path) on Windows.

In the old days™ I had to edit this value every time I wanted to start Cubase VST because another host changed this value to it's own VST path every time it started up. No host had the option to specify multiple search paths back then. Many plugins installers just dumped everything into "C:\Program Files\Steinberg\VstPlugins" regardless of the registry key and most of them even ignored the locale of the system when doing so ("C:\Program Files" was called "C:\Programme" in old german Windows versions). It was a total mess.

That's why I'm asking. I'd really appreciate to have strict rules before everything gets rolled out. It seems logical to have two defined positions in the file system where the files end up, one for the current user and one for all users. I'd guess that this would in practice just place CLAP folders right next to the VST3 folders:

Mac: ~/Library/Audio/Plug-Ins/CLAP and /Library/Audio/Plug-Ins/CLAP
Linux ~/.clap and /usr/lib/clap
Windows: ~\AppData\Local\Programs\Common\CLAP\ and C:\Program Files\Common Files\CLAP\

Will it be possible to install the dlls somewhere else? This would imply that hosts will have to offer multiple search paths to the user. The VST3 specs also specify network paths. Are they really needed? Are non CLAP dlls allowed in the path? What about iOS and Android? Currently not supported but they may be in the future. Are there rules for additional files like presets or samples?

[fese]

+1 on standardized install locations for clap plugins on all platforms. VST2 is still a mess, with some installers not even offering install location but putting the dlls just where they think it is fine.

I know there are people who for different reasons want to install plugins in custom directories, but imho those should just learn about symlinks and junctions.

[Urs]

On Mac, the Library location is the correct path. I don't recall the recommended locations for other platforms. I think though it's worth pointing out that some applications might have a reason to load plug-ins from other locations, e.g. if a host runs from a USB drive itself. We use that for our own development toolchain, so we're happy that a CLAP plug-in can be loaded from custom locations.

Are there rules for additional files like presets or samples?

Yes.

Plug-Ins can provide the host with a list (location?) of its own presets and the host can ask the plug-in to load any such preset. That is, CLAP does not specify a specific preset format, and thus it can be anything that's convenient (e.g. .fxp maybe) for users and developers. In other words, the host can offer browsing capabilities, but nobody has to convert their preset libraries for it.

Plug-Ins can provide the host with file references as used in the current state, such that the host can collect samples/parts/presets/whatsoever and store those with the project file.

[mystran]

and a standard registry key (which stores the VST folder path) on Windows.

In the old days™ I had to edit this value every time I wanted to start Cubase VST because another host changed this value to it's own VST path every time it started up. No host had the option to specify multiple search paths back then. Many plugins installers just dumped everything into "C:\Program Files\Steinberg\VstPlugins" regardless of the registry key and most of them even ignored the locale of the system when doing so ("C:\Program Files" was called "C:\Programme" in old german Windows versions). It was a total mess.

Well, yeah. The other problem is that most users (and possibly a few devs too) probably have no clue there's a registry key in the first place.

Mac: ~/Library/Audio/Plug-Ins/CLAP and /Library/Audio/Plug-Ins/CLAP

Yeah, that's what I was referring to above. Mirrors other standards.

Linux ~/.clap and /usr/lib/clap

Actually /usr/lib/clap is probably the wrong place.

In general /usr is supposed to be reserved for the distribution [ie. theoretically a system update could just completely wipe the whole /usr/lib and rebuild it from scratch] (and in theory should be shareable between multiple systems), where as /usr/local is where you normally put any locally installed stuff. However this runs into the question of what to do if some plugins are installed from distribution repository and others manually.

Fortunately, there's an even better place to put this stuff: the /opt directory is specifically for "the installation of add-on application software packages" so really /opt/clap would IMHO be the ideal location. Unlike with .../lib locations you don't run into any difficult questions about having non-library files in a library path either.

Windows: ~\AppData\Local\Programs\Common\CLAP\ and C:\Program Files\Common Files\CLAP\

Well, this is the problematic case, because ~\AppData is really kinda annoying path to work with and then there's probably a lot of people that want to put that stuff on D:\ instead and then you've got the additional problem that symlinks are not very reliable on Windows so you can't just easily link the standard path into the real location.

I don't know. I'd still rather vote for registry key (or possibly two: one in HKLM and one in HKCU), even if you picked the ones you proposed as the defaults (eg. when the key is missing).

[j wazza]

cant wait to get the clap!

the poly modulation would be great for me, my daw is bitwig which is basically a modular synth like you mentioned, would this just be for instruments or would there be a possibility for poly effects too?

not sure what destructive modulation means