I really like the movement that is happening around these innovations, but there is a high probability that we will not see support for this format quite soon. since the announcement of Taktik was earlier that new features are being developed. given the pedantry and concentration of developers, this may be for the best while the final formation of standards for this branch of plugins is underway.
From a licensing perspective Iām all for this, and its approach to multi-core support is interesting. I donāt have a strong opinion on per-note parameter automation: Iāve never had an MPE or MIDI setup myself. My gut feeling is this feature will be good for those who do, but it still needs plugins to actually support it; e.g. thereās no point being theoretically able to send a per-note filter cutoff to a plug-in that is coded to apply a common filter envelope to every voice.
Curious to see if the approach to threading makes linking multiple plugin instances any harder or easier to implement, for particular routing & mixing plugins.
My main concern, though, is this talk of extensions and rapid feature development. This could backfire horribly if we end up with a fragmented ecosystem, where different hosts all implement different API versions and extension sets. Standardised functionality is absolutely critical to interoperability.
2 Likes
+1 for CLAP support in Renoise!
for polyphonic modulations and optimised performance alone, this is a no-brainer IMHO 
this website tracks hosts and plugins already supporting CLAP:
https://clapdb.tech/
according to u-he - CLAP | Clever Audio Plug-in API, several companies (from small to large such as Epic) are already evaluating the technology.
1 Like
Polyphonic modulation is not supported on plugin level in Renoise, it would require a massive rewrite of lot of parts in Renoise, even the pattern system.
wouldnāt the CLAP plugin format actually make it possible? eg: a CLAP modulation plugin sending polyphonic modulations to a CLAP synth plugin
or is that functionality managed at DAW level?
i was under the impression that CLAP modulations were similar to LV2 CV modulations but polyphonic.
No, because renoise Modulators only work per track, just like automation. If a plug-in was loaded into a sample slot of the renoise instrument structure , it would be different maybe (but already lot of changes in the current concept). Then there is no way currently to actually set automation per note (only for renoise instruments and then only using hex values).
1 Like
hmhm! ok understood 
itās quite a difference in Bitwig for sure.
I hope Renoise will support CLAP plugins alongside VST soon. Iāve been beta testing a few CLAP-only plugins in Bitwig and neither the developers nor I have any complaints so far.
1 Like
As I now understand it, CLAP only benefits performancewise for specific plugins, e.g. U-He Diva. But it would be already possible with VST3, too. I had a discussion with a well known plugin developer about it, and he even says that you already can build VST3 extensions in a very similar way to CLAP. At least he does not see the need for it. Since Renoise currently is structured in a very specific way, it couldnāt modulate plugins on a note instance base, without heavy refactoring of the whole internal structure. So then sadly I do not see a lot of benefit for Renoise users, if CLAP was supported. Ok, CLAPās license is free, this still is a big benefit for developers. It wouldnāt hurt to support it.
Thatās not how they tout CLAP where they claim significant performance gains but if you are right then it will be odd if U-He donāt optimize their VST3 plugins as well?
Subjectively, clap plugins are interesting because it is an open and extensible architecture, which is essentially what Steinberg plugins lack. and here is hope for the porn industry, as it was with the VHS format
Hm, let me clarify what he told me: CLAP is about better multiprocessing scheduling between the DAW and the plugin, so cpu resources can be used/shared more efficiently. Then the DAW vendor has to implement that specific CLAP or VST3 extension (any DAW vendor in fact). His argument then is that community would have more benefit, if the DAW vendors were implementing a VST3 scheduling extension instead.
It is also possible that I donāt fully understand what he told me.
as I understand it, the specifics of vst3 is that some functions are not implemented and some are ignored, and since this is a proprietary product, then this part of the functionality is a whole adventure along the brown brick road.
The main complaint from what I understand is that it is not the best API for development. but here someone who really understands this issue will correct me better.
This is a big deal for developers. Would-be plugin developers could use an MIT-licensed ABI to ātalkā with host DAWs instead of depending on a single vendorās terms and conditions.
It is an open-source project with both community and institutional backing, just like so many other products and services everybody on the internet uses directly or indirectly. The details are quite clear in the original post and related links.
The license is MIT which is extraordinarily permissive. The most appropriate example I can think of off the top of my head is Lua, which plugin & host developers for all kinds of commercial software, not just DAWs, use for free (Renoise is a DAW which does so as well!)
Ups. Was not aware that performance is better.
+1 for CLAP support in Renoise. Already loving it in Reaper, huge performance boost for the plugins Iāve tried so far.
3 Likes
Hi guys,
Still no hope for Clap support ?
" O snail,
climb Mt. Fuji,
but slowly, slowly "
Kobayashi Issa
2 Likes