On Tue, 2011-02-22 at 19:50 +0100, Stefano D'Angelo wrote: > 2011/2/22 David Robillard <d...@drobilla.net>: > > 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.org/14098999.html > >> :) 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