linuxaudio.org

(split from: RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb)
On 02/26/2011 11:35 PM, David Robillard wrote:
> At this very instant, on a particular device, browser might not be up to

quoted text
> snuff.

>

> 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

quoted text
> 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.

I tend to believe that, generally, what is supposed to work in all cases doesn't

work well in specific cases. It may do the job somehow, but it's not really

adapted. And if this results in poor acceptance, then your investment is lost.
Portability is good, but if you go too far with it, you lose a lot of API and/or

platform specific features and optimizations.
Also, I don't see what's so easy with browsers. I've done web development for

years, and compatibility problems are the rule.
> Just want the UI on the same machine? Do the same in your browser.
I don't see why this is so crucial for plugins.
It's true that browsers are evolving fast, but right now you can't even get a

VU-meter to update fast enough in a portable manner. Browsers are not adapted to

such things as live frequency curves and other powerful audio UIs.
> I understand your priorities might be slightly different, since you're

quoted text
> trying to push Android software in the market, but that's my position.

>>From a makin' money makin' apps perspective, a free iPhone/iPad port

> sure doesn't hurt, though... 

I don't think it's a matter of priorities here. We have different opinions on

what plugin UIs could be on mobile devices.
Actually, on current mobile platforms, when one wants a portable UI, there is an

alternative to Web UIs: OpenGL. This runs everywhere, and as smoothly as can be.

All you need is the plugin to expose draw() and mouse motion functions.
Using such functions glScissor(), it would even be possible to embed a plugin UI

in a host UI while making sure that it doesn't draw out of its bounds.
A toolkit on top of OpenGL may often be useful especially for drawing texts and

widgets. For example, there is Clutter: http://www.clutter-project.org/
But this is no constraint, every plugin would be free to use the toolkit of its

choice internally when rendering within its draw() function.
There are subtleties though. For example on Android, there are so-called screen

densities, theoretically ranging from 120dpi to 320dpi according to the device.
But that's easily solved with OpenGL, the host can scale the displayed plugins

if needed. The plugins do not need to know what the ratio between a point and a

pixel is.
And if there existed some specialized toolkit for audio UI development, and even

a UI builder in the lines of JUCE's Jucer, then creating portable and

high-performance plugin UIs would become very easy.
That said, I have also investigated other solutions for simple portable plugin

UIs, but I think that OpenGL is worth considering.
>>> I just dropped explicit LADSPA support from Ingen in favour of NASPRO.

quoted text
>>> 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 :)

>> I am really glad to read that this gap between LADSPA and LV2 is about to disappear.

>

> Likewise.

>

> 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...

Hmm.. Does the current bridge rely on LADSPA rdf files to be present? If so then

I would say that it doesn't really provide backward compatibility from LV2 to

LADSPA. AFAIK, ladspa.h is the specification, and I would hope that the bridge

is able to detect and load any plugin which follow this specification.
> Porting is, of course, even better. A tool that uses slv2 and

quoted text
> 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...

In the Android case, this is entirely possible yes, during the APK packaging phase.
--

  Olivier

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev