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 [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
