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
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.
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
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.
> It's true that browsers are evolving fast, but right now you can't even get a
Obviously, for the sort of thing where you need a rapid update VU meter,
waveforms, etc, using web stuff is not ideal (though see my earlier
argument about short-sightedness re: the rate of progress of browser
VU meters from an instrument perspective don't need to be fast, you just
send peaks. A vague sense of levels that (crucially) shows all clips is
totally doable remotely in a browser (but that said, this again isn't
really what I'm shooting for).
> > I understand your priorities might be slightly different, since you're
Yep... and it's not remote, and involves writing a bunch of platform
specific native code. The whole point is avoiding that.
Do I think GL is the thing to use _if you want to, and can deploy,
implement device specific native code for the UI_? Absolutely. Is that
suitable for all (or even most) cases where browser UIs shine? Nope.
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).
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.
> Using such functions glScissor(), it would even be possible to embed a plugin UI
I fully support people doing openGL (or clutter, or whatever) UIs,
nothing's stopping you. It won't solve the problem I am trying to solve,
though. This is another example of why LV2 doesn't cram a toolkit down
your throat. It is unclear right now whether the web UI stuff will even
have anything to do with the UI extension.
Anyway, the more interesting/important/pressing issue is how the UI
communicates with the plugin, because that part really should be the
same in both cases, and a solution is needed for currently existing
things that are kludging around the lack of it with e.g.
instance-access. Solution here coming soon.
> > I think I am going to create a "LADSPA metadata" LV2 bundle with a
It does if you want categories etc. (obviously, since LADSPA binaries
simply don't have that information in them). They are not required for
plugins to be operational.
Linux-audio-dev mailing list