CLAP... thoughts?

[pdxindy]

The synths of Bitwig have an FX slot where you can add your own FX chain to the synths which is mainly useful for saving presets, I think.

It would be great if you could extend that concept to also add per-voice FX to a synth. Maybe CLAP could be extended to allow instruments to provide an FX slot where you can add other plugins to a per-voice FX chain.

Adding devices to the FX slot is also useful because a modulator on the synth device, can then modulate the FX devices as well.

Plugin synths (VST/CLAP) also have the same post-FX chain, but it is only a tiny arrow and lots of people don't realize it is there! Unfortunately there is no pre-fx chain (note fx) like with Bitwig instruments.

I wish a synth could be nested in the post-fx chain of the Note Grid and receive poly modulation from the Note Grid

[Hink]

May I suggest moving name discussions to their own thread? - It worked wonders for the discussion of installer issues...

absolutely, anyone wants to start one in everything else it's fine. Unfortunately to move all those posts with 48 or something like that pages is not so easy.

Done!

Go here to complain about the name and/or how useless CLAP is, how it's doomed to fail, we don't need another standard, etc...

viewtopic.php?t=583507

sorry couldnt resist ...ty

[fisherKing]

anyone trying to innovate, advance the tech of making music, recording sound... is ok by me. not everything succeeds, but if we don't try, we get nowhere. and i, for one, love new options, new tools, new tech.

am keeping an eye on this thread, and CLAP development in general; i want to see where it all goes

[Held]

Plugin synths (VST/CLAP) also have the same post-FX chain, but it is only a tiny arrow and lots of people don't realize it is there!

I never knew that and used a Chain device to add FX Thanks for pointing it out!

[Weasel-Boy]

I have a question about wrapping a CLAP plug-in in a VST3 wrapper (or, any wrapper, actually). If this has been discussed (and answered) earlier in this thread, I apologize. I may have missed a page or two.

Once wrapped, how much of CLAP’s featureset becomes limited by the VST3 wrapper? What I mean is: will a non-CLAP implemented DAW just respond to only the VST3 feature set?.. or will it be able to take advantage of some of the new CLAP features beyond the confines of the VST3 spec?

[Tj Shredder]

I would not expect that it can get features through, that VST3 doesn’t support… How should that be possible?
But it could translate easy CLAP implementations into complicated VST3 implementations. For developers not paid by Steinberg its a dream come true…

[Urs]

We're discussing an experiment where a CLAP-as-XYZ wrapper could at least have one shared thread pool for all wrapped plug-ins. This would give those plug-ins which do their own multithreading a performance advantage if wrapped from CLAP to anything else. They would still compete with the DAW though, but at least there wouldn't be dozens if not hundreds of threads competing with each other.

[mystran]

We're discussing an experiment where a CLAP-as-XYZ wrapper could at least have one shared thread pool for all wrapped plug-ins. This would give those plug-ins which do their own multithreading a performance advantage if wrapped from CLAP to anything else. They would still compete with the DAW though, but at least there wouldn't be dozens if not hundreds of threads competing with each other.

Is this discussion (the technical side) publicly somewhere?

Sharing a threadpool is already something you can (and should) do with multiple instances of a single plugin (with any API). Sharing a threadpool between multiple plugins from a single vendor can also be done by moving the pool into a common .dll/.dylib/.so and making all your plugins load the same copy (with any API). Sharing a threadpool between multiple plugin vendors would be doable for any plugin API if you could agree on a common implementation in a common shared object.

So from the logistics point of view, I'm not convinced this is going to work if each vendor is wrapping their plugins directly... but it might work if the wrapper is a separate component that the user installs (and hence installs only one copy) that then loads all the CLAP plugins... or something, I don't know... but if there's a discussion somewhere, I'd like to follow it.

[Urs]

Afaik that project to create a CLAP-as-XYZ wrapper is not public yet. That may happen once there's a skeleton.

But yeah, sure, an external library could be used fromm any format, but no other format currently has a standardised implementation for this that would use the host's thread pool.

[DRMR]

But yeah, sure, an external library could be used fromm any format, but no other format currently has a standardised implementation for this that would use the host's thread pool.

3..2..1 gpu.audio fanbois coming in (I mean, it is a valid use-case for such common extended features. not sure if clap thread-pooling is relevant for this, though)

[Urs]

Probably not relevant, no.

[vurt]

viewtopic.php?p=8459350#p8459350

wires adds beta.

[egbert101]

https://youtu.be/tGw9nZXEEJA

[Kalamata Kid]

IMHO Would be great if the plugin had developer keywords for what it does.
Compressor, reverb, delay, midi fx, arp, sample based instrument, utility.
But then also allow for the user to add keywords.

[sQeetz]

I applaud (clap) to the effort. Hope Apple is watching and either implements it fully, or at least "takes inspiration" for further AU development