When can a plugin ask for extensions

[baconpaul]

Interesting conversation with @tim-janik tonight about a problem his host has with surge

The problem is as follows

1. Surge asks for a timer in its ::init method
2. His host doesn't scan for extensions until after a plugin is inited

So either

1: surge is wrong and I should move my timer to activate or
2: his host is wrong and extensions should be available in clap_plugin::init

but the spec is silent on this and so we wanted to raise this discussion.

@abique @robbert-vdh @Bremmers - what say you?

We can specify it in 1.0.3 also with a change to plugin.h init.

[tim-janik]

The host code for plugin setup basically does this:

surge = factory->create_plugin(); // plugin may not query host, allthough it'd be fine in my case
// here surge (JUCE) does *not* support get_extension
initok = surge->init(); // here it calls: host->get_extension(CLAP_EXT_TIMER_SUPPORT) && register_timer()
// early destruction demanded per spec
if (!initok) { surge->destroy(); return; }
// after successful init, the host continues to query plugin capabilities
plugin_timer_support = surge->get_extension (CLAP_EXT_TIMER_SUPPORT); 

And the timer implementation does this:

// register_timer()
if (!plugin_timer_support) return false;
id = schedule_timer(); ...;

In a nutshell, I was expecting plugin->init() to maybe query host extensions, but not use them yet, because the host has not had a chance to query the plugin for its capabilities yet. The spec doesn't say anything specific here, so far I see the following problems:

1. How's the host supposed to complete plugin specific initializations, if it's extensions are used before it can query the plugin extension capabilities?
2. Should it be allowed for the host to query for plugin extensions during host extension methods that are already called on the host while the plugin is still in init()? (could become a bit of a mess with recursions here...)
3. How does extension use during init() relate to the spec requirement that demands immediate plugin->destroy() if init returns false? Tricky case: plugin_init() { ... register_timer(); return false; } Will this leave a stale timer? Poor host having to clean that up ;-)

[baconpaul]

Yeah I think surge is mistaken here and I should move to activate. But curious if we should update the spec also

[robbert-vdh]

Ah yes this is a good point. I think init() is the place to query extensions, but I'm not sure if you should also be allowed to start using them there. Somehow clap_plugin::activate() sounds like a bit of a weird place to register a timer, but it would probably be the most sensible place to do it (and then you can unregister the timer in deactivate).

[tim-janik]

Yeah I think surge is mistaken here and I should move to activate. But curious if we should update the spec also

Here's a sequence I think would make sense:

1. The host calls plugin->init();
2. Then plugin->init() may call all clap_host_t functions, but shouldn't expect host extensions to be usable just yet
3. The host sees a true return from plugin->init()
4. Then he host queries plugin extensions. THIS is the earliest point where I think the overall initialization phase can be considered "completed".
5. Plugins that need to do further work after init() (e.g. for timer setup) should call clap_host_t->request_callback() from init(). After all, this function is always provided by the host.
6. In the first call to on_main_thread(), the plugin can happily mess around with everything the host provides. Note that the spec should guarantee the plugin to rely on request_callback()+on_main_thread() to work, that is not an optional extension mechanism after all.

[baconpaul]

I like your solution with a request callback

[baconpaul]

Right so I guess @robbert-vdh i want to make sure a main thread timer is looking out for the juce message manager mechanism as early as possible which is why I chose init. (In vstgui I do this all in gui creat destroy but juce uses its message manager for more). That’s why I like tims solution

I think we should update the documentation for init regardless

[robbert-vdh]

Yes, I think extensions can and should only be queried during init(). Doing it before that is not allowed, and I don't know if doing it after that point is legal or not (but it should at least not be needed since the supported extensions shouldn't change after init). I thought this documented in the spec, but it seems I'm mistaken.

[abique]

The plugin can query the host extensions in init().
It is forbidden to do it before because the host do not know yet the plugin pointer.

[abique]

The plugin can call back into the host during init(). It is forbidden in create() because the host doesn't know yet the plugin pointer.
The plugin may want to check the track-info for example in order to select an appropriate audio ports configuration.

[Bremmers]

Yeah, I was going to say something like that too. Some extensions may actually need to be used in init(), so you probably can't say "using extensions in init() isn't allowed".

[pauldavisthefirst]

Well, then this also requires a rule for extensions. One rule would be: no extension is permitted whose presence (or absence) changes the behavior of any other extension. A simpler one, similar to what @tim-janik suggested, is that the plugin cannot use the any extension in init() until all of it has finished registering them all. That would probably be a good rule anyway. However, it doesn't handle the case where host behavior in response to a plugin callback changes after the host scans the plugin.

[baconpaul]

Right the “one way” extensions (host do this) are a bit different than the two way extensions (host do this to me because I implement this plugin extension). Timer is in the second category

I backed down that change by the way until bws43b9 due to a bug it tickled on macos

[baconpaul]

Which Alex has fixed

[Bremmers]

I've changed my code to make registering a timer in init() work. Basically I just removed a defensive check.
timer-support.h should say something about this I think.

[tim-janik]

About the "odd" situation of the host having to cleanup resources due to extension use before init() returns false...

I think it'd be good if the spec at least recommended that plugin->init() does return false; as early as possible, best before it starts to use any host extensions.
The rationale here is to avoid hard to debug scenarios. It's not impossible to cleanup of course, but can be laborious and thus hard to get right, especially if the host coding style has to avoid being overly defensive — which started this whole issue ;-)