On Fri, 2011-07-29 at 21:35 +0200, rosea grammostola wrote:
On 07/29/2011 09:30 PM, Harry van Haaren wrote:
On Fri, Jul 29, 2011 at 7:39 PM, David Robillard
I don't think that's too abstract for your average dev.
It's a library
API. Certainly your average dev can use a library.
Being a self-taught dev (no comment on average or not :) I can say I
did find very difficult to understand how the lv2 framework
operates, and how the piece fit together. Equally so as there are
few *simple* examples out there, that one can read and *understand*,
not just gloss over the 1000+ lines and think 'maybe next year'
Less talk, more rock.
True that. I've uploaded a sample class to host an LV2 plugin with a
"jack-orientated" interface. Its released under LGPL, and uses the
LILV library to load the plugin. Written in C++, code is hosted
I'm aware that the code is not perfect, and will accept
suggestions / improvements.
Here is another view of an 'average' dev. Just to get an idea how some
devs might look at things from the outside. Personally, I am 100%
neutral in this discussion though ... ;)
Frankly I'm a bit more optimistic than to consider some random person
posting "And forget about Suil, it doesn't work", and calling me
"stubborn" for implementing a better solution that many people have been
eagerly anticipating. As if ignorant bitching and whining on the
Internet is a rare or valuable resource... (external UI is *inherently*
unwrappable, by the way, and I do not appreciate being called "stubborn"
and demonized for putting a lot of time and effort into solving our
common problems. Perhaps, "falkTX", if you were less rude, ignorant,
and insulting, people would be more open to considering your
No, that solution is not perfect yet, it's new. Duh. As far as my
testing has shown, and the testing of anyone who has productively come
forward with issues, it seems to be working just fine. Complaining and
being a total dickhead on some forum does not help. These problems
would probably be solved already if they were on my bug tracker rather
than buried in some irrelevant forum. Many of the Qt related problems
in the original release *have* been solved by actual cooperation.
That's what happens when you contribute usefully. Try it some time.
To address some points:
* External UI is *not* necessary for JUCE, and is not the best way
* External UI is a kludge in the process of dying, investing in it with
new code at this point is pretty stupid IMO
* Even if you are going to implement external UI (which don't get me
wrong is still a pragmatic thing to do in some cases), it's foolish to
*only* do that and not expose your native widget. It's trivial to
expose an embeddable UI as well
* I am actively interested in resolving any issues with embedding with
the currently supported toolkits, and very cooperative in that respect
* I am actively interested in supporting any new toolkits. X11 is
forthcoming, and linuxDSP is open to using it. This will probably
provide an easy path for JUCE and most other toolkits as well, since X11
is a useful common denominator. In order to make this stuff work, I
need plugin UIs that expose a (whatever widget). Make the UIs and I
will make them work everywhere possible. I promise.
To disspell some nonsense:
* The argument that suil is going to have some exponential complexity
problem is an absurd straw-man. Localising that (completely manageable)
complexity in a single well-tested library makes it feasible. *Not*
having something like Suil is FAR more complex, globally. That's the
whole point. The wrapper modules in Suil are like 50 lines of code!
Whatever complexity demon people are imagining simply is not there at
* This weird one-sided view that somehow embedding Qt in Gtk is fine but
the other way is not is utter nonsense.
* The host does NOT have to link against all the supported toolkits.
That's pretty much the entire point of Suil.
* Re: complication, external UI burdens the plugin/UI author with a huge
amount of unnecessary window/IPC/logistical complication. This is by
far the *worst* place to put the complexity, and it means that big glob
of complexity is duplicated (poorly) in every single plugin project.
This makes writing new UIs and plugins difficult, which as others have
recently mentioned here is a very bad thing. The situation was awful, a
better solution was needed, and that's what Suil is for.
It is unbelievably frustrating for people to post crap like this on some
forum, say they gave up on Suil and implemented their own bridges (silly
duplication of effort), when I havn't heard a single thing about any of
this from any of these people! What completely absurd behaviour! I am
not psychic, I can't fix it if I don't even know about it!
Welcome to Free Software. Clearly you are new here. Learn to work