1 Mar
2011
1 Mar
'11
4:47 p.m.
On Tue, 2011-03-01 at 14:13 +0100, Stefano D'Angelo wrote:
If we exclude older IE releases it all gets a lot better :-)
If you exclude IE entirely it gets even better. I hear maybe the very
latest release is just unawful enough that maybe you don't have to do
this, but I couldn't care less.
This stuff is more appropriate for controllers. Faders, knobs, buttons,
grids, loop sequencers, etc. Maybe you personally don't care to control
audio software with a tablet (or any machine on which you can't install
a bunch of native LAD crap) but there's no question that a lot of people
do.
Personally I don't care about high performance native UIs that draw
waveforms or whatever, because the last thing I want to be doing (or
anybody wants to watch) is clicking around on a damned screen when I'm
trying to play. 99% of that stuff is worthless fancy bling intended for
back of the box screenshots, if you ask me. Plain old lines and flat
rectangles are not only as good - but better - for tactile UIs actually
designed for playability/readability.
True for live usage, not really for offline processing, recording
sessions, etc.
Like I said, I am doing the web thing for controllers, for which it is
awesome.
Your mind pushed it too far as soon as browser specific anything got
involved.
Yep. I'm all for GL UIs.
2011/3/1 David Robillard <d(a)drobilla.net>et>:
> On Mon, 2011-02-28 at 21:51 +0100, Olivier Guilyardi wrote:
[...]
Also, I don't see what's so easy with
browsers. I've done web development for
years, and compatibility problems are the rule.
Never said it was easy, but requiring a modern browser is still much,
much more portable and less annoying than requiring a bunch of specific
native code on every device. This is not a "web site" that needs to work
in IE6 or whatever. Just want the
UI on the same machine? Do the same in your browser.
I don't see why this is so crucial for plugins. At least not in the long run. Think spatialization,
EQs, physics-related stuff, scientific usage and, somewhere in the
future, sound analysis (spectrograms, etc.), highly interactive stuff.
I've no doubt there's things that the browser isn't good for. They're
also usually things that involve a lot of data and you wouldn't do
remotely anyway. Use a native UI.
As for my personal goals, that's all a bunch of "nerd clicking and
staring at a screen" crap that is specifically what I am trying to avoid
entirely.
As one
example, I want to have a machine controlling the audio rig, have
people arrive with their tablet (or whatever), go to a particular
address and participate in the jam. This is be a pretty
awesome/novel/unique possibility. Non-realtime audio is even a
possibility if their device can do such things. Obviously, the only way
of doing this is web UI. As a nice plus, when you do it that way, hey,
you get a PC appropriate network transparent UI for free. From the
perspective of someone who needs this anyway, some very tangible reasons
would be needed to make rewriting the whole UI in GL as well not an epic
waste of time. Note that most of realising this dream will be done by
the host, only certain plugins would need special web UI fragments. The
rest just need to provide sufficient information for the host to make
sense of their parameters (as they need to regardless).
/me thinks, at this point, about a possible WebUI decorator plugin
with interactive design possibilities...
(then my mind pushes it too far: let's integrate with Firebug or something. :-P)
If you want to
do some sort of experimental fancy 3D plugin UIs rendered
in the same 3D universe or whatever (right now, i.e. not using webGL),
where it is necessary for a plugin to have special UI code (i.e. the
host can't generate it) sure, this is not the way to go. Use
GL/Clutter/whatever. Unless you actually need the performance advantage
of native GL, though, browser is better.
Uhm, GL is actually embeddable in most semi-serious toolkits (even SDL
should allow that IIRC). Should we go for a GL/WebUI approach? /me: GUI decorator plugin #2 - give it a bunch of
metadata (and maybe
fonts image), it will create the GUI on the fly for you.
In any case where it's actually feasible for the host, or a library, to
generate the UI, rather than having to write specific UI code, that's
very definitely the way to do.
Along those lines, I need to spread the port groups extension... you can
automagically make pretty good UIs as long as you can actually group
things sensibly...
-dr