About CLAP

[Urs]

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?

Effects usually don't have a concept of voices. Effects often have a concept of "bands" for which there exist separate parameters anyway.

not sure what destructive modulation means

The modulation would be non-destructive. This is opposed to parameter automation. In latter, the knob/fader/button/whatsoever moves, such that it actually edits the setting/preset of the plug-in. Once the parameter automation ends, the parameter is still changed to the value it had been automated towards. The original state is gone, hence it's "destructive" (sounds worse than it is).

Non-destructive in this context means that if the Modulation ends or gets discarded, the plug-in is back to its original state.

In other words: Automation means, the parameter actually changes. Modulation means, what you hear is the parameter where it always was, plus the modulation amount, for as long as it lasts.

[j wazza]

Effects usually don't have a concept of voices. Effects often have a concept of "bands" for which there exist separate parameters anyway.

The modulation would be non-destructive. This is opposed to parameter automation. In latter, the knob/fader/button/whatsoever moves, such that it actually edits the setting/preset of the plug-in. Once the parameter automation ends, the parameter is still changed to the value it had been automated towards. The original state is gone, hence it's "destructive" (sounds worse than it is).

i meant if it could be possible to have effects like there are in some synths, i think some uhe ones, where each voice is sent to a different effect automatically, but i could see how that would be difficult with vst effects in a daw, it would mean multiplying each vst for each voice, but it would be really cool if it could work

i get you now about destructive modulation, thanks!

while ive got you here, id love an expanded version of ace with just more oscs and lfos, especially more pm inputs and being able to use sines,saws etc for every osc/lfo, sorry to go off topic, but i would clap if this happened!

[Urs]

while ive got you here, id love an expanded version of ace with just more oscs and lfos, especially more pm inputs and being able to use sines,saws etc for every osc/lfo, sorry to go off topic, but i would clap if this happened!

I would love that, too. Let's hope that CLAP does what we want it to be, a way to become independent from platform updates and our own schedule, and then we can finally go ahead with all the plans we've made such a long time ago, which were always postponed because someone decided that big change was a good idea while someone else's pace was tragically slow, and we got mixed up in the middle of it because we tried to do the right thing, and now we're done trying and we try to do what's best for us and our customers and what you describe is exactly what we thing that might be, but also for all our other plug-ins, too.

[j wazza]

I would love that, too. Let's hope that CLAP does what we want it to be, a way to become independent from platform updates and our own schedule, and then we can finally go ahead with all the plans we've made such a long time ago, which were always postponed because someone decided that big change was a good idea while someone else's pace was tragically slow, and we got mixed up in the middle of it because we tried to do the right thing, and now we're done trying and we try to do what's best for us and our customers and what you describe is exactly what we thing that might be, but also for all our other plug-ins, too.

i hope so too!

[teilo]

i meant if it could be possible to have effects like there are in some synths, i think some uhe ones, where each voice is sent to a different effect automatically, but i could see how that would be difficult with vst effects in a daw, it would mean multiplying each vst for each voice, but it would be really cool if it could work

Something like this would require separate audio outputs for each voice of an instrument on the track / chain, as well as the transmission of trigger / note for every voice individually. That is a concept that does not exist in any DAW. There are multi-outs, but they are not "per voice." Polyphonic effects also ramp up the CPU usage really fast.

[EvilDragon]

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.

Symlinks are perfectly fine on Windows. I'm symlinking the VST3 folder to D:\VST3 and everything is just spiffy, and has been for years... All plugin installers that want to install to the default VST3 path in CF end up in D:\VST3... just no problems ever.

https://schinagl.priv.at/nt/hardlinkshe ... llext.html

This tool is all that's ever needed. Sucks that it's not built into Windows.


CLAP's suggested paths for Windows also mirror where VST3 paths are (Steiny seems to want to move things from CF into AppData/Local, for whatever reason).

[Paul Eye]

I seriously hope I can put any upcoming CLAP plugins wherever I want to (especially since in Reaper I can set the plugin paths as I like). The case for me being that I've had a C:\Audio\VST directory (with subdirs by developer) on my PCs literally since the last millennium (and the reason why I still stick to VST2 whenever possible). I don't want anyone telling me where I can and can't put my plugins and how I organize them. You can imagine my reaction when VST3 installers (I detest plugin installers in the first place) started forcing plugins into a hardcoded C:\Progam Files\Common Files\VST3\ directory (with barely ever even an option for a developer subdir).

[mystran]

Symlinks are perfectly fine on Windows. I'm symlinking the VST3 folder to D:\VST3 and everything is just spiffy, and has been for years... All plugin installers that want to install to the default VST3 path in CF end up in D:\VST3... just no problems ever.

I see. I remember having some issues with them, but that was arguably at least a couple of years ago, so perhaps the situation has significantly improved since then.

[edit: I should probably clarify that "at least a couple of years ago" is a scientific measure that can mean pretty much anything between 2 and 20 years; it's entirely possible that I'm just seriously out of date on this one and they indeed work fine now]

CLAP's suggested paths for Windows also mirror where VST3 paths are (Steiny seems to want to move things from CF into AppData/Local, for whatever reason).

Well, AppData is per-user so (1) it makes sense if you assume the plugins are licensed to users rather than machines and (2) more importantly, it means you don't need admin rights to install them.

[EvilDragon]

You don't need admin rights to install things to PF/CF, actually. Installers have their own permissions entity (TrustedInstaller) and all they need is a nod from the user by confirming the UAC dialog (since Vista).

[Kott]

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.

/opt is never used for libs/plugins, de-facto it's purpose for self-contained 3rd-party apps.

.lv2 and vsts installed from packagemaner sits fine in /usr/lib[64] so clap could so too

[syntonica]

You don't need admin rights to install things to PF/CF, actually. Installers have their own permissions entity (TrustedInstaller) and all they need is a nod from the user by confirming the UAC dialog (since Vista).

UAC was always the first thing to go after I logged in. If I eff up my machine, it's nobody's fault but my own.

The whole single-user/all users thing is so messed up on both Windows and Mac. I'm surprised it hasn't been fixed in the last 20 years. (Not.)

[crickey13]

cant wait to get the clap!

[mystran]

You don't need admin rights to install things to PF/CF, actually. Installers have their own permissions entity (TrustedInstaller) and all they need is a nod from the user by confirming the UAC dialog (since Vista).

That's not what I mean. What I mean is that your user account still needs to have the permission to install software and typically this translates to it being part of the administrators group, otherwise you don't have permission to confirm the UAC dialog.

[mystran]

.lv2 and vsts installed from packagemaner sits fine in /usr/lib[64] so clap could so too

Well, you can have package manager putting them there, but then you really also need to allow /usr/local/lib so that plugins can also be installed without the package manager.

edit: Let me discuss this a bit more, because I'm a long-time Linux user (even though it's not what I run at home right now) and a Unix (Solaris/BSD/Linux mostly) administrator, I'm acutely aware of the "complicated" situation with file system standards.

The reason I suggested /opt would be the good location is that if you're looking at the situation from the point of view of a 3rd party commercial plugin (which might even have it's own installer) then in a sense it really is a "self-contained 3rd party application" even though the "platform" on which it runs is a compatible host. So from this point of view, such a 3rd party commercial plugin really should go into /opt when installed system wide... although I admit you could make the case that you shouldn't put stuff there if it's supposed to be part of some search path.

On the other hand, if you look at the situation from the package managers point of view, then /usr is indeed where you normally put stuff. Finally if you're fetching the source from github and compiling yourself, then the standard place to install would be /usr/local, because if you put it in /usr you risk conflicts with the package manager.

So in a sense... on Unix (and this is not Linux specific at all) you've got this really great separation between how you're supposed to install software from different sources and when you're dealing with applications it's arguably truly wonderful (especially from a system administrator point of view in a more complex environment), because from the location you immediately know what types of install it is and they mostly never step on each other... but I really don't think anyone truly thought about plugins when it comes to this.

So I don't know. Perhaps the correct solution following the usual unix-design would be to designate an environment variable (eg. CLAP_PATH) that contains a semicolon separated list of all the directories that you're supposed to look into and then then default that with something like "~/.clap;/usr/local/lib/clap;/usr/lib/clap" ... but ofcourse, from the usability point of view this is truly horrible once you start installing self-contained 3rd party plugins.

[EvilDragon]

You don't need admin rights to install things to PF/CF, actually. Installers have their own permissions entity (TrustedInstaller) and all they need is a nod from the user by confirming the UAC dialog (since Vista).

That's not what I mean. What I mean is that your user account still needs to have the permission to install software and typically this translates to it being part of the administrators group, otherwise you don't have permission to confirm the UAC dialog.

Hmmm, that's not what my experience tells me from installing other plugins on regular user (not admin) accounts...