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 <[email protected]> > > wrote: > > 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 > > here: https://github.com/harryhaaren/Lv2Host > > > > 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 ... ;) > http://linuxmusicians.com/viewtopic.php?f=44&t=7207#p21193
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 opinions...) 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 forward * 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 all. * 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 together. -dr _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
