search

free-audio / clap-wrapper

Wrappers for using CLAP in other plugin environments
MIT License
107 stars 17 forks source link

CLAP wrapped VST3 crashing most hosts since CLAP 1.2.0 update #229

Closed tas-from-planet-u-he closed 6 months ago

tas-from-planet-u-he commented 6 months ago

Tested mainly on M1 Sonoma. Reaper also tested on Win 10, same there. Since the moment Alex updated our u-he plugin builds to CLAP 1.2.0, the wrapped VST3 version will instantly crash most hosts.

The actual CLAP plugin works fine. The real VST3 works fine. Only the wrapped VST3 crashes.

It works ok in Bitwig 5.1.2 and Live 11.3.2.

Cubase 13 and Reaper 7 crash as soon as the wrapped VST3 is being loaded. Studio One might load it, but crashes when quitting the host. And FL Studio doesn't successfully scan it anymore, so it cannot be loaded there.

The plugin always logs this at the moment of the crash: [CLAP] It is wrong to query the latency before the plugin is activated, because if the plugin dosen't know the sample rate, it can't know the number of samples of latency.

Since most released u-he plugins are not using CLAP 1.2.0 yet, there is only one plugin you can currently test this with, the Zebralette 3 public beta on KVR (revision 15573), which can be downloaded here:

https://www.kvraudio.com/forum/viewtopic.php?t=607153

baconpaul commented 6 months ago

So the reason for this is twofold

  1. The latency check was incorrect in the helpers code. That is fixed here https://github.com/free-audio/clap-helpers/commit/244adf1647d7d417cb15e10a699361c706d50aa2 and I guess I should merge that into main. @Trinitou / @abique thoughts on clap-helpers next becoming main?

  2. At u-he you have compiled with clap helpers at terminate checking level rather than log. While that's useful for debugging I don't recommend it for production plugins. You probably want to rebuild with your production clap helpers usage set to log not terminate.

abique commented 6 months ago

Yes let's merge.

baconpaul commented 6 months ago

OK I'll move next to main right now.

baconpaul commented 6 months ago

And done

defiantnerd commented 6 months ago

So, this was actually a clap-helper issue?

baconpaul commented 6 months ago

The clap helper was wrong when querying latency at startup, yes. David @ u-he found that and I merged it above.

The u-he plugs are coded with zero-tolerance terminate-on-error settings. So this error made them crash rather than log.

I strongly suggest the u-he plugins in release mode not use the terminate-on-problem mode. But also they should pull clap-helpers to head and rebuild.

Schroedingers-Cat commented 6 months ago

I strongly suggest the u-he plugins in release mode not use the terminate-on-problem mode.

The specific plugin binary discussed here is a beta build which does intentionally crash on any misbehaviors, like our internal builds. Final release builds, as you suggest, already just log the misbehavior.

So, this was actually a clap-helper issue? ... But also they should pull clap-helpers to head and rebuild.

We already had the fix in our repo before it was merged into CLAP's official repository and still had the misbehavior crash. Turns out there's a similar problem to the helper issue within the CLAP wrapper. I created https://github.com/free-audio/clap-wrapper/pull/230 to fix this.

baconpaul commented 6 months ago

Wonderful! Thank you for upstreaming these fixes!