About CLAP

[carrieres]

Sucks that it's not built into Windows.

mklink is enough, no ?

[EvilDragon]

Yeah sure, that's what LSE is doing in the back end (and more). It's just having a context menu option makes it much easier for people that are scared of command line.

[Kott]

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

...
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.

That is my thoughts. CLAP_PATH env might be required (or recommended) thing for CLAP hosts. I think it's not so horrible, you can expand this path to /opt/clap too if you gonna install smth not suitable for /usr/ or ~/

Moreover. There are distros with their own FS hierarchy, with layers, prefixes and chroots etc, so having this variable should easily adopt plugins installing in these cases.

[camsr]

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.

Also, as the note signal ends, a voice is inclined to continue as per it's release stage. Perhaps multi-outputs for each voice in solo is a good option. Both the synth and effect plugin following it would need to be expecting no mixing until the final stage. IOW, both the synth and effect would have to be designed to accept multiple solo channels with polyphony as an end result in mind.

[Urs]

In CLAP, a synth can (must in certain scenarios?) tell the host that a certain voice (identified by port, channel and note number) has ended, i.e. that its release phase is over. The reason for this is to tell the host that it does not need to send parameter modulation anymore, e.g. when the modulation is sent for a certain port/channel/note number or combination thereof.

I have thought about suggesting to extend this so that this communication is not only between plug-in and host but also among plug-ins in the chain. While it's certainly tempting to open up concepts for per-voice-interoperation, it also immediately adds complexity and a plethora of potential issues. So I'd be against it and our plug-ins wouldn't support it. Instead, MIDI 1/2/MPE can be passed from plug-in to plug-in.

Audio ports for each voice are possible, too, including flags for silence (could be interpreted as voice idle). But then again of course there's no feedback channel to tell a plug-in ahead of the chain "oh, I'm not gonna process on this port, no need to send audio". For effects that have a voice concept, or synths that have audio inputs.

[camsr]

There is also the old school way of doing it; multiple generators and multiple effects routes.

[camsr]

Audio ports for each voice are possible, too, including flags for silence (could be interpreted as voice idle). But then again of course there's no feedback channel to tell a plug-in ahead of the chain "oh, I'm not gonna process on this port, no need to send audio". For effects that have a voice concept, or synths that have audio inputs.

It is a valid concern (to shut off cpu consumers that output into ONLY muted input(s)), and I agree the level of complexity could be bothersome.

[Benutzername]

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.

I think it would be enough to define a minimal set of host search locations in the standard like the ones you've listed. If a plugin lib ends up in one of these folders then all will be good. This scheme seems to work quite well for lv2, vst2 and vst3. There is no reason to over complicate things.

Urs had a good point with development folders and portable installs so hosts will have to offer multiple search paths anyway. If plugins are installed outside the usual folder structure for whatever reason then hosts should be able to find them with the help of the user eventually.

So in practice this would look like VST3 with additional user defined locations.

[mystran]

Urs had a good point with development folders and portable installs so hosts will have to offer multiple search paths anyway. If plugins are installed outside the usual folder structure for whatever reason then hosts should be able to find them with the help of the user eventually.

As a developer, I actually keep two separate plugin folders just so that I can have one that contains all the collected junk that I use for actually making music (configured only in the host I use for making music) and then another one with very limited selection (mostly just some analysis tools that are useful for debugging) that I use when I need to debug something in random host X and don't want to bother trying to scan through my actual plugin folder.

Anyway, the way I see it, the main advantage of having standard paths is mostly just so that you can have installers default to a sensible place. Having to tell a host where the plugins are is a minor nuisance, where as having to tell every installer separately where to place your plugins gets old pretty fast.

[sjm]

I guess I'll stick to getting my condescending attitudes from Steinberg then...

Really?

There are people who are busy preparing open source projects, writing documentation, defining APIs, testing implementations or simply just financing the things that need to be done. If you want to be part of the decision making process I strongly suggest to become creative and actually contribute.

I did try, but you weren't remotely interested in engaging with me constructively.

[Urs]

I guess I'll stick to getting my condescending attitudes from Steinberg then...

Really?

There are people who are busy preparing open source projects, writing documentation, defining APIs, testing implementations or simply just financing the things that need to be done. If you want to be part of the decision making process I strongly suggest to become creative and actually contribute.

I did try, but you weren't remotely interested in engaging with me constructively.

Sure, but as I said, it was an unrelated issue. You can post as many constructive ideas here as you wish, but I am not the right addressee. Therefore you can not receive an answer from me, or expect me to join in a discussion. You need to talk to the people in charge. That is not me. The people in charge are available via the means of the Github repository linked in the first post. Go there, work with them. Don't expect me to engage in discussions that are not for me to engage in.

You wouldn't ask me to implement MIDI 2 in VST3, would you? You'd ask Steinberg.

Hence, sorry if I'm blunt, but there are topics I do not wish to discuss here. It is that simple.

[Dan]

CLAP sounds exciting .

[Urs]

Mini-Update:

When we started in April 2021, we estimated a year. Ok, now it's a little bit more than that, but every piece is falling into its place right now.

The CLAP ABI is going to be finalised very soon, as all core extensions are becoming final and are being tested in multiple plug-ins and hosts. Some auxiliary extensions remain in draft status as we expect more feedback from a wider group of developers.

Logo artwork is available, and http://cleveraudio.org is pointing to the Github repo for now.

Bitwig and us are consulting with people (contributors etc.) and we are drafting a message and a plan to publish CLAP 1.0 and to move it to a governing body in the foreseeable future.

u-he is a few little fixes and improvements from publishing betas of MFM, ACE and Hive with CLAP support, where ACE and Hive feature CLAP's parameter modulation. Thus, in Bitwig (and surely more hosts to come) you'll be able to put LFOs and envelopes on nearly any parameter that has a knob, and do so per note (polyphonic). There'll be some beta testing involved before we can update all synths with mutichannel MIDI (ACE, Bazille, Diva, Hive, Repro-5) with this kind of feature.

Surge is going to have full CLAP support and a few other open source projects have pull requests scheduled which will enable CLAP for them immediately, if their owners agree.

The vibe in the group is very good, even if we have been quiet for a while.

Stay tuned!

[EvilDragon]

Happy days!

HTTPS not set up yet for that domain, it seems?

[Hanz Meyzer]

I like the logo! Why no Bazille?

Very nice news!