On Sat, 2011-02-26 at 19:19 +0100, Olivier Guilyardi wrote:
On 02/26/2011 06:45 PM, Stefano D'Angelo wrote:
Something
like 100k-200K could be fine in my case, at the condition that adding
LV2 support provides a real benefit in terms of functionality.
This depends on what you are using it for and how. Being decentralized
& extensible, you could also use it to make coffee. :-)
Heh :) Well, right now, I'm more wondering about what ui:AndroidUi could be.
I think browser UI is definitely the way to go. Then it's a UI for
basically anything, and one that's inherently remote control capable.
I have a few ideas knocking around in the back of my head about simple
dynamic RAD for web based plugin GUIs...
Aside, in the ui ext docs there's this example
which contains ui:binary, but I
can't find any reference documentation about this binary property on the page:
http://lv2plug.in/ns/extensions/ui/
Noted. An error duplicated from an ealier LV2 spec. One of these days
I'll write a simple validator to catch this stuff...
However, in
the long run, I would avoid LADSPA for two reasons: 1.
lack of extensibility, etc., 2. LADSPA plugins can run into LV2 hosts
without explicit support through the NASPRO bridges (which will be
able to work by default with SLV2 starting from the next SLV2 release,
otherwise you can grab the current svn SLV2 already).
Hmm, I've been wandering in google yesterday about such LV2-LADSPA bridge.
I am discovering the NASPRO project. That's interesting. It seems like it may
consume a lot of brain-time diving into all this when compared to LADSPA. But
I'm nevertheless a bit worried about adding support for LADSPA, as it's getting
old and somehow obsolete. But IIUC correctly you are about to add some sort of
LADSPA backward compatibility, which in any case, sounds very good and was
clearly missing.
I just dropped explicit LADSPA support from Ingen in favour of NASPRO.
IMO, if the bridge is inadequate, then the bridge should be fixed, so
I'm investing in NASPRO, so to speak, so hopefully it remains a vibrant
project :)
From a host author POV, it's pretty awesome to
implement a single plugin
API and get full-featured support for (possibly) all the
plugin APIs for
free...
-dr