CLAP: The New Audio Plug-in Standard (by U-he, Bitwig and others)

[baconpaul]

Did any one experience an issue where the host automatically ends sending modulations for an active note_id when another note_id gets triggered for the same musical note?

With which plugin? Plugins which use the channel as a note differentiator (and many of the u-he ones today do this) will act that way if you don’t have a note channel rotator. Plugins which use the note id as the differentiator (like the clap saw demo and surge) will not.

[S0lo]

Did any one experience an issue where the host automatically ends sending modulations for an active note_id when another note_id gets triggered for the same musical note?

With which plugin? ......

Mine. I think I figured it out. I had to use the VOICE_INFO extension with the CLAP_VOICE_INFO_SUPPORTS_OVERLAPPING_NOTES flag. Looks like its working now.

[S0lo]

What do you use for time when you send\record automation to the host ?

Code: Select all

	clap_event_param_value_t *pcev = (clap_event_param_value_t *) &cev;
	pcev->header.size = sizeof(clap_event_param_value_t);
	pcev->header.time = ??????;
	pcev->header.space_id = CLAP_CORE_EVENT_SPACE_ID;
	pcev->header.type = (uint16_t)CLAP_EVENT_PARAM_VALUE;
	pcev->header.flags = 0;
	pcev->param_id = index;
	pcev->value = value;

Please don't get me wrong here. I know what time means and I know how to receive modulation/automation events from the host and play them in a sample accurate fashion. Thats not what I'm asking.

[robbert-vdh]

What do you use for time when you send\record automation to the host ?

Code: Select all

	clap_event_param_value_t *pcev = (clap_event_param_value_t *) &cev;
	pcev->header.size = sizeof(clap_event_param_value_t);
	pcev->header.time = ??????;
	pcev->header.space_id = CLAP_CORE_EVENT_SPACE_ID;
	pcev->header.type = (uint16_t)CLAP_EVENT_PARAM_VALUE;
	pcev->header.flags = 0;
	pcev->param_id = index;
	pcev->value = value;

Please don't get me wrong here. I know what time means and I know how to receive modulation/automation events from the host and play them in a sample accurate fashion. Thats not what I'm asking.

Just use 0 if you don't already have a specific timestamp for the automation event (e.g. if you're just sending automation as a result of the user dragging a knob in the GUI).

[baconpaul]

Exactly; And "time" is "sample offset from start of process block" so "0" means "at start of block" and "frame count - 1" means end and so on.

I also use the convention that if I don't know I pick 0.

[S0lo]

When sending SysEx dumps to the host (via clap_event_midi_sysex_t). How long is the plugin expected to hold that dump buffer in memory before it can assume that the host has already processed it? Can we assume that say by the time the host calls the next proccess() that we can free those buffers?

Or is the host required to actually copy the dumps to it's own memory once try_push() is called?

[Tale]

Or is the host required to actually copy the dumps to it's own memory once try_push() is called?

I would assume that the host is required to copy the data, and I guess the same goes the other way around (i.e. when receiving SysEx from the host the plugin is required to copy the data).

[Christian Schüler]

My biggest complaint (working through the raw C API for the past couple of hours) is that the example plugin template uses 3 spaces instead of 4 spaces for intendation [edit: oh and uses Javastyle brace-placement in C ... ]

(Over here: 4, and Allman braces ftw.)

I'm sorry that's it. If the API is not using Allmann sytle braces I can't legally use it... /s

Seriously though, I read through the thread and what do people have against CMake? It's the worst meta-build tool out there, except all the others that are even worse. At least CMake sees good support.

I already have an internal API-abstraction layer in my plugin but it is heavily geared towards VST2 because that's the one that ever got implemented. But if CLAP is similar, then it shouldn't be difficult to add support. Besides, I'm use the raw aeffect.h, I never used the provided C++ wrappers that for me didn't add any value, so structs and function pointers is all I need.

[Christian Schüler]

However:
*Cubase never adopted the AU format.
*Logic never adopted VST.
*Avid does not support anything besides AAX.

Each of those devs want to make their format standard.

Not necessarily. They just want to stew in their own juices for as much as possible.

[mystran]

I already have an internal API-abstraction layer in my plugin but it is heavily geared towards VST2 because that's the one that ever got implemented. But if CLAP is similar, then it shouldn't be difficult to add support. Besides, I'm use the raw aeffect.h, I never used the provided C++ wrappers that for me didn't add any value, so structs and function pointers is all I need.

Probably the biggest difference for a simple plugin is that CLAP handles parameter automation as part of the event stream, both in and out of plugin and if you have an architecture where the GUI sends events directly to host, then you need a bit of glue to queue them such that you can flush them to host from the audio process callback (or flush callback when not processing).

Other than that, I don't know if it's really "similar" to VST2, but it's really an API and not a framework, so I don't see how it'd matter too much what your plugin works internally. Support for CLAP exclusive features might require some architectural changes depending on how your plugins are built, but feature parity with VST2 should not be terribly difficult.

[S0lo]

Or is the host required to actually copy the dumps to it's own memory once try_push() is called?

I would assume that the host is required to copy the data, and I guess the same goes the other way around (i.e. when receiving SysEx from the host the plugin is required to copy the data).

It makes sense to think so. But just in case, since this doesn't seam to be explicitly stated (yet), I already implemented some precautions, waiting until the next event(s) are sent before freeing the dumps. This will at least wait for the next proccess() call. Usually more.

[Urs]

Why not ask in the Github discussion section? That's where Alexandre, Paul and Robbert hang out. If the documentation is missing something, that's how it gets fixed...

[mystran]

Or is the host required to actually copy the dumps to it's own memory once try_push() is called?

I would assume that the host is required to copy the data, and I guess the same goes the other way around (i.e. when receiving SysEx from the host the plugin is required to copy the data).

It makes sense to think so. But just in case, since this doesn't seam to be explicitly stated (yet), I already implemented some precautions, waiting until the next event(s) are sent before freeing the dumps. This will at least wait for the next proccess() call. Usually more.

CLAP is a well specified API. In general when a well specified API doesn't explicitly mention that you need to keep some data alive, it should be perfectly safe to assume that a copy is made.

[S0lo]

Why not ask in the Github discussion section? That's where Alexandre, Paul and Robbert hang out. If the documentation is missing something, that's how it gets fixed...

heh, I'dont know. good point. They were kind enough to reply here so I got hooked to this thread

[baconpaul]

Why not ask in the Github discussion section? That's where Alexandre, Paul and Robbert hang out. If the documentation is missing something, that's how it gets fixed...

heh, I'dont know. good point. They were kind enough to reply here so I got hooked to this thread

GitHub triggers notifications for me; kvr does not. So it’s really a latency question

And yeah make a copy if you want it to be longer lived than the call and it’s a const event *. I think that was your question right?