i2productions wrote:I've never had one force close on me like VST's.
You're probably referring to the old JUCE based VSTs, which had a lot of issues... (err, still do).
new JUCE based VSTs no longer have this sort of issues (take a look at the new Loomer VSTs).
I spoke to you about this before, that I want to port and fix the VSTs on linux. Probably the pack will be ready by the end of the month.
Just 1 more month, and we'll then compare LV2 vs VST to see which is better...
Suil currently supports Gtk 2 and Qt 4, i.e. with Suil a Gtk program can embed a Qt plugin UI without depending on Qt, and a Qt program can embed a Gtk plugin UI without depending on Gtk. I (David Robillard) would be happy to work with plugin authors to add support for new toolkits, please contact me if you’re interested in writing a plugin UI using a toolkit that is not yet supported in the LV2 ecosystem.
JUCE (Jules' Utility Class Extensions) is an all-encompassing C++ class library for developing cross-platform software.
It contains pretty much everything you're likely to need to create most applications, and is particularly well-suited for building highly-customised GUIs, and for handling graphics and sound.
A simple solution to this toolkits problem is using the External UI, but drobilla is too stubborn to accept it...
.
Where you are a new guy on front (which is cool!), Drobilla has been around for a while and is a respected developer... You're using big words, a bit too easy and too fast maybe...
Anyway, good luck with JUCE and LV2! All though it might be preferable to have GTK and QT based plugins... it would be a good step if those JUCE plugins could be ported to LV2
For what its worth: I've never used JUCE for my UIs, and I don't think it will be necessary (for me), that's nothing against JUCE as a UI toolkit, but I think last time I checked there was a license fee for commercial use and I had already developed a minimal UI toolkit which used XLib to provide the UIs.
Reasons for using XLib:
1) As mentioned by other people, one of the problems with plugin UIs is that you don't know which toolkit the host will use, so by hooking into X at the most basic level I could get a UI that would work regardless of the host UI toolkit.
2) External UI is used because it allows the plugin to create its own UI with minimal interference from the host. I believe there is a feeling from some developers that external UI is not the way to go, but now that its in most hosts, there seems to me to be no harm in leaving it be.
3) One of the reasons (I believe) for some developers disliking external UI is that it needs some kind of IPC (if you really run the UI in another process, but as noted, I just run the UI in the same process, using external UI to provide the (one) function that was missing from the original LADSPA spec that would have made it possible to do UIs even in LADSPA e.g. the ability for the plugin to write back parameter changes to the host.
Also, external UI doesn't provide for the host UI to embed the plugin UI - from my point of view, my plugins don't need this (and would prefer not to be 'swallowed' into the host UI - so it works ok for me)
4) The problem with using XLib for UIs is that you need some knowledge of GUI toolkits at a very low level to be able to code a UI using it, but personally I think if that makes writing plugins a bit difficult then.. well it's just that writing high quality plugins (and software) is not easy despite what some people assume. The toolkit I have devised has also now been succesfully ported to work on windows GDI as well as XLib with minimal effort.
I'm not sure how well suil functions, I've not stressed it that much - I did experiment with wrapping my XLib UI as a 'fake' GTK plugin UI - which worked, and this is the kind of thing suil is doing at a low (XLib) level (I think, although obviously the developer would be a better person to say) - I think there may be a suil extension eventually that handles XLib UIs which would be useful (as this could work for JUCE too).
It will be interesting to see suil develop, my only doubts are that if it has to support a lot of toolkits then it may mean rapidly growing complexity - e.g. GTK to Qt is only 4 (host - plugin) combinations, but add e.g. XLib, SDL, JUCE, FLTK etc etc... But again this may be an incorrect assumption to make. Its an interesting approach to solving a complex problem.
@falktx: I have submitted a patch for Ardour3 which provides the basic support for native linuxVSTs via Vestige - 32 and 64Bit (JUCE GUI's or whichever toolkit the plugin uses), which has recently been committed to SVN. There are a few more fixes to come, but most linux VSTs I have tried work fine (subject to ardour's rules about plugin I/O compatibility - which I hope will eventually become more flexible with regard to MIDI / audio combinations)
I noticed a few issues with vst midi input though, but the rest seems to work ok.
It's not entirely complete yet, so there will be a few things that need to be fixed / improved, but it was intended mainly just to get things going. Anyone who wants to add to it or fix it up is welcome to do so. I've just submitted another small correction which may address the MIDI issues - it was something which relates to 64Bit. My guess is that that won't have been committed to SVN at the present time.
All though it might be preferable to have GTK and QT based plugins... it would be a good step if those JUCE plugins could be ported to LV2 