No OverToneDSP plugins for Linux anymore ?

[tramp]

gtk is NOT a safe bet, specially when it comes from plugins.
let me post this again: http://lists.lv2plug.in/pipermail/devel ... 01593.html

gtk2 is already deprecated in favour of gtk3, but we cannot use gtk3 in plugins safely at this point.

I'm not aware of a existing gtk3 host.
Also, I'm not aware of any conflict provided by a gtk plugin UI in any existing host(QT or gtk; or what ever), given that for the case of a gtk host, both, plugin and host be build against the same library version.
The trouble comes, when binary's be distributed and used, from outside the core distribution.
That, will be the case for the OverToneDSP plugins anyway.

[Drumfix]

Funny read as always. Thanks to external UIs (or better, its fallback) for my own VST plugins the plugins and their UIs work with each and every VST host from the very first
energyXT to the latest reaper release candidate.

[tramp]

Thanks to external UIs (or better, its fallback) for my own VST plugins the plugins and their UIs work with each and every VST host from the very first
energyXT to the latest reaper release candidate.

That may be, but, no host can provide a internal interface for your plugins to incorporate them into the own UI design.

[Drumfix]

Correct. Especially because it can be a UI, which would not necessarily need to be a graphical UI at all. Or run on a completely different machine from the host, e.g. Tablet.
The mantra that a UI must be a graphical user interface controlled by the host is a host developer only request. A user won't care.

[Drumfix]

Actually, your method works because of a silent agreement between host developers to use an undocumented extension to the VST specification, i.e. most host developers simply copy the method that the juce developer introduced 10 years ago. The VST spec does neither enforce the use of an X11 window as parameter to the effEditOpen function nor describes it any way for a host to get access to a possible (and not required) child window of the plugin. If you've ever looked at the vstgui code that came with the VST Spec (but is not a part of the VST spec) you should have noticed that Steinberg's "method" was to use an Xt widget as the "system dependent window handle" in effEditOpen, not an X11 Window.

From the discussions between Mike and host developers, latest being the one at the ardour forum, it seem to me to be pretty clear that he has enough of all these undocumented host features and host developers accusing him of having a broken design for no reason.

[tramp]

I agree with Drumfix here. External UIs are a good "solution".
It's how I did it with Carla. Carla is a python application that uses Qt. BUT Qt is never used in the backend or plugin, so you get no Qt symbols in the final binary. The engine and UI are completely separate things.

Even true, in guitarix the engine and the UI been separated as well, could run on different machines, or even headless. Rabit, is currently developing a QT5 front-end UI for guitarix, and there is the WEB-UI. That wouldn't be possible, when plugins need to use there own UI's, btw. didn't forward there ports to the host so that it could be under control of the host.

The mantra that a UI must be a graphical user interface controlled by the host is a host developer only request. A user won't care.

A short handed view, even users like embedded systems like this one, were the plugin must be controlled by the host:
https://github.com/rabits/onebutton

[Drumfix]

@falkTx: I was refering to VST2, with references to the vstgui version 2.2 that was shipped with the vst2.3 SDK.