About CLAP

[camsr]

I am sensing a duplication of concerns in the scenario that both the host and plugin are checking for silent buffers. If the plugin was to do it, it would pass appropriate return value, but what would the host do? If the host checked, it could only assume that a silent input buffer would carry through to a silent output buffer (as in, no sound generation occuring)? And in the case the plugin does not use sample stream data, why would this return be of any signifigance? Just trying to understand how to mesh these concepts here.

[rafa1981]

It's an object, but in plain C (i.e. not C++).

Nitpick Olympics: It is kind-of the virtual function table (VTABLE) of an object. I say kind-of because there is extra stuff.

For objects with no virtual functions it would be enough with passing the "this" pointer to a given struct or a void* as the first parameter explicitly.

And this above would have worked with CLAP too, but given the fact that the host is going to store them in a table of functions, passing the table directly saves some symbol lookups on the shared object. It's the only reason I could come with when looking at the code.

Passing a table makes adding new core functions to the API less easy though, I assume this is taken care of with the extensions stuff. Probably it would not be a bad idea to add the size of 20 or 30 pointers of reserved dummy storage to the struct and have plugins memset it to 0 for future additions to the core API. I haven't read the API in full so this comment might not apply and things might being taken care of in another way.

[Urs]

There are many questions here that I simply can't answer - I'm not directly involved in CLAP development -, and which might deserve their own thread in the dev forum. I'm sure that once it's ready for V1.0, Alexandre and others can answer each question a lot more thoroughly than I could.

As for the concepts pointed out, our impression was from the beginning that an open, public discussion would lead to so much noise that it'd be impossible to agree on specifications. We've been through several phases of "one could also" and "why don't you" once the number of people involved exceeds a certain threshold. Hence, at some point one simply has to make a decision. With CLAP now being adopted by several parties, it becomes more and more unlikely that a core component gets refactored in any major way. Naturally, with more and more proof of concept, pressure for change also disappears.

[Urs]

I am sensing a duplication of concerns in the scenario that both the host and plugin are checking for silent buffers. If the plugin was to do it, it would pass appropriate return value, but what would the host do? If the host checked, it could only assume that a silent input buffer would carry through to a silent output buffer (as in, no sound generation occuring)? And in the case the plugin does not use sample stream data, why would this return be of any signifigance? Just trying to understand how to mesh these concepts here.

The plug-in does not return a flag for silent buffers*. It just tells the host to either keep processing or go to sleep it if the input is silent (in this case, the host checks for silent buffers). The plug-in can also ask the host to simply stop processing it until there are new events to handle.

This is an extension the the concept of silent flags, which takes into account that "oh yes, the output may be silent, but I might have some more audio soon!" and it also extends the protocol with an option to return an error if the buffer had been compromised (i.e. if for whatever reason the buffer contained a NaN anywhere).


* correction: Individual buffers can be marked "constant", which may indicate silence.

[abique]

I would suggest to discuss technical issues using https://github.com/free-audio/clap/issues
Thank you very much

[mystran]

I am sensing a duplication of concerns in the scenario that both the host and plugin are checking for silent buffers. If the plugin was to do it, it would pass appropriate return value, but what would the host do? If the host checked, it could only assume that a silent input buffer would carry through to a silent output buffer (as in, no sound generation occuring)? And in the case the plugin does not use sample stream data, why would this return be of any signifigance? Just trying to understand how to mesh these concepts here.

The plug-in does not return a flag for silent buffers. It just tells the host to either keep processing or go to sleep it if the input is silent (in this case, the host checks for silent buffers). The plug-in can also ask the host to simply stop processing it until there are new events to handle.

I think this is poor design. It'd be much better to just flag any "canonically zero" buffers as such and let plugins do a fast-path bypass themselves. If you want to have functionality for suspending plugins on top of that, then so be it... but please make it explicitly forbidden (preferably as a clause in the licensing terms) for hosts to "check for silent buffers" because they have a history of being far too aggressive with that and causing audible artifact unless you inject low-level noise to the plugin output just to defeat the detection.

[Urs]

I think this is poor design. It'd be much better to just flag any "canonically zero" buffers as such and let plugins do a fast-path bypass themselves. If you want to have functionality for suspending plugins on top of that, then so be it... but please make it explicitly forbidden (preferably as a clause in the licensing terms) for hosts to "check for silent buffers" because they have a history of being far too aggressive with that and causing audible artifact unless you inject low-level noise to the plugin output just to defeat the detection.

Well, the way it's done in CLAP actually prevents hosts from misbehaving. And the plug-in can absolutely tell the host that it misbehaves if it stops processing audio without the plug-in's consent.

[rafa1981]

There are many questions here that I simply can't answer - I'm not directly involved in CLAP development -, and which might deserve their own thread in the dev forum. I'm sure that once it's ready for V1.0, Alexandre and others can answer each question a lot more thoroughly than I could.

Fully agree. Design by committee sucks. As I see it is almost always superior for someone or some small group to do a prototype and people review it, while the writer(s) decide which things to address or ignore. VST didn't even allow this.

In my case I was answering to Jeff's question basically.

[mystran]

I think this is poor design. It'd be much better to just flag any "canonically zero" buffers as such and let plugins do a fast-path bypass themselves. If you want to have functionality for suspending plugins on top of that, then so be it... but please make it explicitly forbidden (preferably as a clause in the licensing terms) for hosts to "check for silent buffers" because they have a history of being far too aggressive with that and causing audible artifact unless you inject low-level noise to the plugin output just to defeat the detection.

Well, the way it's done in CLAP actually prevents hosts from misbehaving. And the plug-in can absolutely tell the host that it misbehaves if it stops processing audio without the plug-in's consent.

Well, I suppose I wasn't 100% serious with all of the previous, but.. in general I think it'd be better for both the plugin and the host to be able to look at a flag and tell that a given buffer is nothing but silence on per-buffer basis and then decouple this for any kind of suspending.

I actually have a "test-bed" audio engine (to play around with graph scheduling and that kind of stuff) that treats the per-buffer silence-flags as mandatory such that whenever the flag is set, the actual buffer contents don't matter. This means that you can have "plugins" with lots of inputs and outputs many of which are always canonically zero and neither the "host" nor the "plugin" ever needs to touch the actual memory holding the actual buffers (ie. no cache cost) if the silence flags are set (but the memory is there, so a naive implementation can just issue a memset call to convert a silent buffer into a non-silent buffer with nothing but zeroes).

Now, whether or not such a scheme makes it into CLAP is probably not going to make or break the standard, after all we're talking about fairly minor optimisations here, but I just want to point out that passing zero buffers around with flags to indicate their contents are garbage and should be interpreted as zeroes can have some performance advantages even when suspending a node is not applicable.

[Urs]

Well, the buffers have such flags (see my correction above)

The return value of the process function is simply an indicator as to the plug-in telling the host how it wants the situation handled.

[mystran]

Well, the buffers have such flags (see my correction above)

Great. Sorry for posting before checking the source code.

In any case, I believe this kind of thing is sort of similar to the host-threadpooling thing in the sense that it can give very real performance benefits with relatively minor "mandatory impact" on development complexity.

[camsr]

The plug-in does not return a flag for silent buffers*. It just tells the host to either keep processing or go to sleep it if the input is silent (in this case, the host checks for silent buffers). The plug-in can also ask the host to simply stop processing it until there are new events to handle.

This is an extension the the concept of silent flags, which takes into account that "oh yes, the output may be silent, but I might have some more audio soon!" and it also extends the protocol with an option to return an error if the buffer had been compromised (i.e. if for whatever reason the buffer contained a NaN anywhere).


* correction: Individual buffers can be marked "constant", which may indicate silence.

Ok great, so it provides flags for handling process() call anomalies.

(technical opinion incoming)
There is a choice to also have the function return void, and put these flags into the struct the process() is called with, which IMO keeps things organized better. The host will need to handle this return value somehow, and maybe having it in the same struct as the input parameter could save some instructions or something. The void function can still return prematurely if needed. I am unsure as to how much error-handling code could be useful in the process(), but if there is a technical reason for using the int32 return type for major program errors, I suppose it would be useful.

[Don Deluxe]

A thrilling example of a company thinking "big picture" while showing leadership and being a responsible steward.

CLAP is an exciting project and I hope that all parties involved are successful. As a community, we deserve an alternative to VST and the restrictions it imposes upon developers. A new interface with fewer restrictions, robust licensing , and a forward thinking design philosophy, will help push music technology forward and out of the hands of a single corporate entity. An exciting prospect.

Thank you for your contributions, U-He.

[Urs]

Thank you. We really haven't done that much, but we're eternally grateful to then people who do!

[sl23]

This sounds like an interesting idea! Not that I know anything about the programming side of it, but it's good to see corporations being taken out of the equation! This must be the fastest growing thread, 11 days and already 19 pages, wow!

Are there plans to support older plugin standards too? Like a built in 'bridge'?

Is there a website for more info to keep track of news etc? I tried web search, but only get links to clap VST's lol

Thanks to everyone involved