CLAP 1.2.0

[abique]

When going through the macros, we have:

#if defined(CLAP_CPLUSPLUS) && CLAP_CPLUSPLUS >= 201103L
#   define CLAP_HAS_CXX11
#   define CLAP_CONSTEXPR constexpr
#else
#   define CLAP_CONSTEXPR
#endif

If I'm correct, in C++ constexpr implies const, so maybe in the else branch #define CLAP_CONSTEXPR const would be better?

Then if we do the change above, second question:

static CLAP_CONSTEXPR const char CLAP_EXT_TRACK_INFO[] = "clap.track-info.draft/1";
// OR
static CLAP_CONSTEXPR char CLAP_EXT_TRACK_INFO[] = "clap.track-info.draft/1";

@Bremmers @robbert-vdh would that create problems for making rust/delphi/... bindings to CLAP?

Thank you for your advice.

---

EDIT: that doesn't work if constexpr is used on a function.

[abique]

I'd like to re-discuss the draft transition for 1.2.0.

Breaking the end-user experience isn't an option to me because it will leave a massive negative impression of CLAP. Users will fail to understand why it broke and why we'd make that choice. There will be traces in the forums that will never go away. Overall, it'll have a negative impact on the project.

However, in the set of extensions that we stabilize in 1.2.0, the audio ports related one aren't widely used and are OK to break I suppose, then for the others, breaking them won't affect the projects playback at least in Bitwig. They are more convenience extensions, like preset-discovery, preset-load, param-indication, remote-controls, ...

I see two possible path:

1. keep the draft in the extension id
   • This will look ugly (in the sources) forever
   • No extra pain for the devs, everything stays working
2. remove the draft in the extension id, introduce a compat ext id eg: CLAP_EXT_CONTEXT_MENU_COMPAT, ask the plugin and hosts to check both the ext id and the compat ext id if the compatibility matters to them, remove the compat ext id at some point in the future
   • kind of ugly to have to check for 2 extensions ids, but doable
   • there will be cases where it "doesn't work" because of old and new product combination
   • transition time needs to be 2 years I think
   • code will look good in 2026, if we ever decide to remove the compat ext id, which may decide against in the futur and it'll turn out to stay forever...

What do you think?

[Bremmers]

@abique would that create problems for making rust/delphi/... bindings to CLAP?

Would be no problem for the Delphi translation.

[messmerd]

I'm fine with either option, but I prefer (2).

If we go with (2), it should not be very difficult to coordinate with the developers of the handful of known CLAP hosts to alert them to this change ahead of time. We could have support for both the new and compatibility IDs in hosts before CLAP 1.2.0 is even released.

I'd even be willing to open PRs in host repos to add this support myself.

If all major hosts support both the old and new IDs before 1.2.0 is released, plugin developers should not have to worry about this change at all, so I think any COMPAT constants should be directed primarily towards host developers who want to support pre-CLAP 1.2.0 plugins with any of the affected extensions, not at plugin developers. I could even see this being a footnote in a comment under the new IDs rather than a COMPAT constant that we'd need to remove later.

The only issue I can see is that the affected extensions in new (>=1.2.0) plugins will not work in old (<1.2.0) hosts.

However, this does not really bother me because:

• Most CLAP plugins I've seen currently use older CLAP versions such as 1.1.1 and are not actively upgrading to the newest CLAP version as soon as it releases. This gives hosts more time to catch up.
• Plugin frameworks such as CLAP JUCE extensions and others could delay updating to 1.2.0 if they really want to ease the transition for plugins that rely on them.

[baconpaul]

I'm fine with option 1 for the ones we promote to 1.2.0 as long as the ones left in draft in 1.2.0 (1) remove draft from their name and (2) don't auto-include the then-still drafts in clap.h.

I think the draft in the name is less embarrassing than breaking for no reason, I agree. I just don't want to have to make this choice again at 1.3, 1.4, 1.5 etc....

[abique]

I'm fine with option 1 for the ones we promote to 1.2.0 as long as the ones left in draft in 1.2.0 (1) remove draft from their name and (2) don't auto-include the then-still drafts in clap.h.

I think the draft in the name is less embarrassing than breaking for no reason, I agree. I just don't want to have to make this choice again at 1.3, 1.4, 1.5 etc....

With Bitwig, the break will happen only if:

• bitwig <= 5.0
• plugin uses clap >= 1.2.0 without clap-helpers and didn't use the compat ext id

The code to work with both ext id would be added to bitwig and clap-helpers.

[baconpaul]

So that’s the camp 2 compat Id idea?

I’m fine with that too.

Like I said my biggest concern is we don’t have to do this again at 1.3 so things that stay draft in 1.2 get draft removed etc

[urshimself]

I'm good with 2, too. Most important thing is it'll eventually be resolved, at the end it's a clean resolution, it won't happen again.

That said, we have experienced worse compatibility breaks in all other formats we support, often without even being notified about it. Mostly due to SDK changes or change of interpretation of specs. Sometimes we learn through users.

Therefore the only wish I have is that the changes are communicated transparently, like this is what we did, this is why we did it and that is why it's gonna be resolved forever.

[baconpaul]

Yeah it takes me a morning to do a clap point release with a new clap helpers for surge too if helpers does the both names trick

[abique]

I've prepared a PR with what changing the stabilized extension ID would look like: https://github.com/free-audio/clap/pull/379