I've just compiled most lv2 libs (core, ui, uri-map, serd, sord, lilv, suil, event) from http://lv2plug.in/spec/ on a clean system. Its all working perfectly, without a single problem. Thought I'd mention that as mostly there are "its broken" mails coming from me to the list :) -Harry

Hello David, On 07/27/2011 01:44 AM, David Robillard wrote: I understand that you want LV2 to be a standard and only a standard, and thus only show its specification on http://lv2plug.in. You seem to consider that serd, sord and lilv are helper libraries and only one route amongst other possible routes to host LV2 plugins. This is consistent in /principle/, but do you not something feel like such "modularity" can be confusing, when compared to existing major plugin technologies which provide everything as an SDK? Do you not feel like a complete LV2 SDK would be more developer friendly, in /practice/? Regards, -- Olivier

Hello Gabriel, On 07/29/2011 04:32 PM, Gabriel Beddingfield wrote: 1. I don't have time to work on this. 2. That's a task for the core LV2 devs IMO and I'm not part of the LV2 team. 3. If I became part of the team, I wouldn't see things from the outside anymore, which is useful to give practical ideas. I have spent some time trying to get a global figure of plugins in general, and this SDK question comes from this point of view. An external point of view. -- Olivier

On Fri, Jul 29, 2011 at 1:00 PM, David Robillard <d(a)drobilla.net> wrote: I /personally/ agree that an "official SDK" is silly... be it LV2 or Android or Qt or MeeGo or whatever. I'm a developer... why would I want to use some mickey-mouse SDK? Give me the headers... and a chroot... and emacs... and a beer! However, these mickey-mouse SDK's /do/ foster adaptation of the technology. There's a whole generation of ADHD Devs who are looking for some kind of gooey instant gratification. "Oooo, an Eclipse plug-in! Shiny!" ...and there's the fact that LV2 really /is/ just-a-little-too-abstract for your average dev. So, while the idea of an LV2 SDK disgusts me (personally)... Olivier is right that it would accelerate developer acceptance. -gabriel

On Fri, Jul 29, 2011 at 7:39 PM, David Robillard <d(a)drobilla.net> wrote: 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. Cheers, -Harry

On Fri, 2011-07-29 at 21:35 +0200, rosea grammostola wrote: 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

On Sat, 2011-07-30 at 03:31 +0400, Alexandre Prokoudine wrote: Frankly I don't really care who he is. Conduct is conduct, and that conduct always results in precisely what we see here: no improvement. -dr

On 07/29/2011 08:00 PM, David Robillard wrote: I agree that good pointers and docs on the LV2 site could be a solution. But, one concrete reason is that for example, you don't have anything like aptitude install lilv on other OSes. I think that we don't see the need for SDKs on Linux because we have distributions and smart packaging systems, which gracefully handle dependencies. -- Olivier