On Sat, 2011-02-26 at 19:44 +0100, Olivier Guilyardi wrote:
At this very instant, on a particular device, browser might not be up to
Personally I'm more interested in better long-term investments, and the
browser is only going to get better - and it's getting better very, very
quickly. This stuff is moving way too fast to throw out all the wins and
ease of browser UIs, IMO.
The ultra-portability is a really lucrative feature. Being able to
control plugins over the network from anything with a web browser
without requiring any UI-client side specific code whatsoever is a whole
lot of awesome. Even for desktop software - have a nice phone or tablet?
Go to http://yourmachine:12345 (or whatever) and there's the UI. No
screwing around with phone/tablet software whatsoever.
Just want the UI on the same machine? Do the same in your browser.
I understand your priorities might be slightly different, since you're
trying to push Android software in the market, but that's my position.
(Aside: For Ingen fans, I think this is the way things are going for
making UIs for Ingen patches. Build your UI, even dynamically, by
visually programming with LV2 messages, and your patch can have a custom
browser UI that can be used if you're running Ingen as an app, or if the
patch is running as an LV2 plugin in some other host. Develop LV2
plugins, with a network transparent GUI, without writing a single line
> > I just dropped explicit LADSPA support from Ingen in favour of NASPRO.
I think I am going to create a "LADSPA metadata" LV2 bundle with a
(hand-curated) data file with extra info about various LADSPA plugins,
particularly classes (plugin categories) for plugins without lrdf.
LADSPA plugins not being categorized in the menu is the user-visible
kink in integration right now...
Porting is, of course, even better. A tool that uses slv2 and
dyn-manifest to dump out a bundle for a wrapped plugin would do almost
all the LADSPA=>LV2 porting work for you, and is trivial to write...
Linux-audio-dev mailing list