On Wed, 2011-03-02 at 14:20 +0100, Olivier Guilyardi wrote:
Thin platform drivers, i.e... platform specific native code.
Can we PLEASE stop beating this dead horse? My point is that NO SOFTWARE
NEEDS TO BE INSTALLED AT ALL WHATSOEVER AT ALL PERIOD AT ALL. Get it?
Good. Let's move on.
> What you're talking about makes sense if the host itself runs in the browser...
The idea is to put the entire performance/control/et UI in the browser,
so it can be remote. You've missed the remote idea. Remotes good, even
on a desktop. People go out and spend money on special purpose devices
for this all the time. Tablets can give you a completely generic
reconfigurable... that.
The "host", as in the plugin host that does audio things, is obviously
not in the browser, that's on the machine doing audio things, C, Jack,
etc.
> That said, for instance on Android, you can embed a small WebView into the UI of
Yep.
> But (http) network operations are going to bring
It's not a network operation if it's local. Local socket communication
is very fast... and something that's arriving in the browser.
http://en.wikipedia.org/wiki/WebSockets
As far as I'm concerned a non-crap app design should be capable of doing
engine <=> UI communication over a anyway, even
if you only intend to use it on a local machine. You WANT a huge
meaningful wall between those two things. For one thing, if your UI
stuff crashes, your audio doesn't, and your set doesn't trainwreck.
The other win of UI<=>audio separation is that not all of our DSP code
runs on a computer with a monitor at all. Little embedded boxes that do
DSP stuff don't have big screens... but they usually have USB ports (or
network, or MIDI, or something).
That UI <=> Plugin separation is necessary is, IMO, a given, and not up
for debate. You could throw it all out the window and gain virtually
nothing in return, but... well, doesn't sound wise, does it?
> >> The plugin would expose a draw() callback
Plugin and UI are not the same thing, nor should they be.
> > So far, nobody has showed up with a desire to write a GL plugin UI.
OK, well, do you have any active plans to do OpenGL plugin UIs any time
soon?
> > The next SLV2 will abstract away UI types, so if/when this gets
In one sense. The problem it's solving also shows some of its
weaknesses.
> >> I'm confused now. You are talking about UIs automatically built by the host from
... Yeah, that would be the obvious reason. ;)
> >> this is the absence of plugin specific UI, and the kind of thing which you can
Yep. I see how heavy it is, and I also see that it is the only
technology stack you have, if you want to do this kind of thing. I also
see it's getting a whole lot less heavy extremely rapidly.
Anyway, go look at some modern canvas experiments. Drawing a curve
quickly is well within what works fine right now. Drawing and animating
a whole ton of them smoothly is current reality.
Why you are trying to pick apart web UIs in the same email as you're
arguing where one size does not fit all I don't know... I want a remote
control that works on any device out of the box. It's about as blatantly
obvious as anything can be that web is literally the only way to go for
that, because the browser is actually on those devices. QED.
Do I think /all/ desktop PC hosts and plugin should use it? No. It's for
"remote control" things (even if not remote). Is GL good? Yes. I sure
wish I used it for the Ingen canvas. Has anyone actually showed up yet
who wanted to write a GL UI? No. Unless you're one, talking about it is
a waste of time.
> >> I think that I understand you idea of doing this with a browser. No need to
You just mentioned controller apps where users build their own UIs
(touchOSC etc), sooo... I guess you don't believe in reality? ;)
> Okay, well, this Web UI idea would certainly be good in certain cases. And the
This is audio. Give people the ability to pixmap at all and they're
going to make some big retarded quasi hardware photo thing, each
entirely different, and usually horrific screen real-estate wasters.
Consistency between UIs ain't going to happen. GL would probably be even
more consistent than the toolkits, ironically, because it tends to push
you towards vectorey things.
> But this later problem could be solved with a simple audio-oriented UI toolkit,
Aaaand now we're entered the realm of many years of work that nobody is
going to do. Unless JUCE counts.
Speaking of doing tons of work, GL gives you an open-ended way to draw
things... and that's it. One you actually need to make those things
interactive, you need something else. Something else that isn't just GL,
and probably isn't portable, and is a ton of more work regardless. The
DOM inherently makes it trivial to deal with events, and that's all
built-in. A mess of little toolkits, all alike, is not a fun situation,
and plopping it on a GL backend doesn't make it go away.
-dr
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
LINUX® is a registered trademark of Linus Torvalds in the USA and other countries.
Linuxaudio.org logo copyright Thorsten Wilms © 2006.
Hosting provided by the Virginia Tech Department of Music and DISIS.