On Sat, 2011-02-26 at 19:44 +0100, Olivier Guilyardi wrote:
> On 02/26/2011 07:28 PM, David Robillard wrote:
>
> >> 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...
>
> Browser UI is too much overhead IMO. I've had many Android devices in my hands.
> Some of them are fast, some of them lag terribly. You need to optimize as much
> as you can, and thus avoid extra layers such as a browser, javascript, and all that.
>
> Also, for really nice Android plugin UIs, the use of OpenGL could be great. It
> provides a great frame rate, suitable for fancy realtime frequency curves,
> waveforms, etc..
>
> But all this need some careful research.
At this very instant, on a particular device, browser might not be up to
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
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.
From a makin' money makin' apps perspective, a free iPhone/iPad port
sure doesn't hurt, though...
(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
of code.)
> > 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 :)
>
> 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...
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...
-dr
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sat, 26 Feb 2011 17:35:18 -0500
This archive was generated by hypermail 2.1.8 : Sun Feb 27 2011 - 04:15:02 EET