linuxaudio.org

On Tue, 2011-02-22 at 19:50 +0100, Stefano D'Angelo wrote:

quoted text
> 2011/2/22 David Robillard :

> > On Tue, 2011-02-22 at 04:52 +0000, Jeremy Salwen wrote:

> > [...]

> >> Hi David,

> >>

> >>

> >> As a plugin developer, I'm very much looking forward to this,

> >> especially since I proposed something similar to this a bit ago

> >> (http://www.opensubscriber.com/message/linux-audio-dev@lists.linuxaudio.o... :)   But the fact that you're capable and willing to implement this solution means a lot more than my confused half-baked ideas.  I look forward to the day when embedding and cross-toolkitedness walk hand in hand.

> >

> > Right, what you describe here is more or less what I am getting at (it's

> > come up several times in the past), except rather than bundling it with

> > every UI (which is copy-paste code reuse and all sorts of nuisance

> > waiting to happen), I think it should just be a normal system library

> > that hosts can use to do the job.

> >

> > We generally have the philosophy that if there is a choice, complexity

> > does not belong in the plugin (or UI). Putting the complexity in the

> > plugin is bad bad bad, plugins should be small and easy to write. In

> > this case, a plugin UI should just implement and expose its widget -

> > dealing with that widget is the host's problem.

> >

> > In this case, we have a tricky enough complexity that we don't want it

> > duplicated in all the hosts either, so a library is definitely the way

> > to go. I call it Suil :)

>

> I didn't follow the whole discussion, but I just want to toss out one

> not-so-stupid-as-it-may-seem possibility: HTML + CSS + JS. Take a look

> at YUI.

I don't think it's stupid at all. Saying using browser technology for UI

is stupid these days is the height of short-sightedness. That's clearly

where everything is headed.
I have a working plugin (called "dirg") that provides a UI by hosting a

web server which you access in the browser. It provides a grid UI either

via a Novation Launchpad, or in the browser if you don't have a

Launchpad. Web UIs definitely have a ton of wins (think tablets, remote

control (i.e. network transparency), etc.)
I also have a complete LV2 "message" system based on Atoms which is

compatible with / based on the event extension.  Atoms, and thus

messages, can be serialised to/from JSON (among other things,

particularly Turtle). This IMO definitely The Way Forward for more

advanced communication between UI and plugin: float control ports really

don't cut it, and instance-access is evil. This kind of thing is why I

have always strongly advocated the 'host handled' communication between

plugin and UI. Instance-access was designed to kludge VST UIs into LV2,

but really should not be used in new code. This is the other high

priority "alarming LV2 situation" right now.
Currently dirg provides the web server on its own with no host

involvement, but every plugin doing this obviously doesn't scale, so

some day we should figure this out... first we need an appropriately

high-level/powerful communication protocol within LV2 land (hence the

messages stuff).
-dr
_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

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