[linux-audio-dev] Re: chrome

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: [linux-audio-dev] Re: chrome
From: Dave O'Toole (dto_AT_qwsi.net)
Date: Thu May 25 2000 - 17:28:39 EEST


Paul Barton-Davis wrote:
>
> > on the CD you make with it. The primary concern should be user control
> > and audio quality.
>
> Except: I'm in interested in getting musicians and sound engineers to
> use Linux.

Oops; I was primarily interested in making music, and creating tools to
do this with. Am I on the wrong mailing list?

> Yes, you can play it too them over and over and show them how good it
> sounds. But when they can *the same plugins* (or better) using a VST
> GUI, why bother with Octal, or Linux at all ? Oh, yes,

...

> I think this chrome-aversion is a kind of inverted snobbery on the
> part of *nix users. If the user is blind, they won't be using a GUI at

This is a big oversimplification, even for LAD. People are making the
"Linux vs. Windows" choice for reasons quite separate from visual
appearance (notice how I left out the Mac?). In fact, I will readily
admit that most Linux applications aren't quite as pretty or as visually
consistent (I'll return to this one later) as their Windows
counterparts. It is not "snobbery" to suggest that something other than
chrome can drive the quality and userbase of an application. My earlier
comment about chrome not being crucial was not snobbery. I would call it
"pragmatism". It would not have needed to be said if there wasn't such
an apparent tradeoff choice looming before the LADSPA group: several
people here have remarked that essentially making a new
platform-independent GUI toolkit (for LADSPA custom interfaces) is
easily a huge project, one that could suck an enormous amount of time
away from development of audio apps.

Also, saying that "chrome isn't essential" isn't the same as
"chrome-aversion." There is a practical argument against excessive
chrome, which I'm getting to.

> Traditional engineers of audio gear spend weeks designing their
> physical user interfaces, while people in the *nix work seem to think
> that the same scrollbars that work for their sysadmin programs or text
> editors are automatically the right choice for a program designed to
> be intuitive to people *who don't use computers for other purposes*. I
> think this is arrogant. Those users are our friends. We're not winning
> any of them over by sticking butt ugly interfaces that even their
> Windows counterparts don't use onto potentially vastly superior
> technology.

? I question your assumption that any consistent/host-controlled
interface approach is going to be "butt ugly." For instance, I'm using
GTK+ for GNU OCTAL. Now while there are many silly/ugly GTK themes,
there are also quite a few *really* good-looking ones. It's clear that
the OCTAL scheme isn't the same as your scheme (no DTD's even) but I do
not think this is going to be butt-ugly. Early tests have told me quite
otherwise; that it will in fact look nice. No, maybe not revolutionary
or mind-blowing; but nice.

> all, so the appearance is irrelevant. If the user wants something
> different, provide a themeing/skins capability. But make the baseline
> GUI attractive, appealing, intuitive, immediate, stunning. I hope that
> nobody is claiming that these adjectives rule out the other important
> set: powerful, ergonomic, accessible, flexible. They don't.

I think you've got this all backwards. Taking your GUI example (above)
at face value, I'm a little unclear on why a normal scrollbar would need
to be different in different places.

And I mean functionally different, not just in appearance. For if the
widgets needed by plugins will only need to differ **superficially**,
the solution is themeing, which everyone on linux already has. This
could be implemented quickly in terms of existing solutions. The plugins
describe abstract parameters with defined semantics, and the host (or
some other module) manages the drawing of an interface using a more or
less portable toolkit such as GTK+.

If, however, the widgets will need to differ **functionally**, as in
"the reverb's scrollbar ACTS differently from the sine-wave generator's
scrollbar" we have a different situation. I think what you're saying is
that if plugin developers want crazy scrollbars, they should have them,
since this freedom is essential to creating chromey GUI's, and chrome is
good for attracting new users. Judging from VST, the developers will
sure take full advantage of this capability if it's included--lots of
neat interfaces.

The first approach corresponds almost directly to the GNU OCTAL
architecture. The second approach sounds more like what is being
discussed for LADSPA.

I am getting to my point now :-). You wrote above that people shouldn't
claim that "attractiveness, appeal, intuitiveness" etcetera are mutually
exclusive with power, accessibility, flexibility. You are absolutely
correct in that there is no such neccessary exclusion. However, you are
missing an important attribute that can cancel out all those you cited:
Consistency.

For example, the fact that the X Window System does not enforce or
provide any particular widget set or interface policy provides a great
deal of freedom and flexibility in building applications. But in the
worst case scenario, every application looks and acts different from
every other. It isn't quite this bad on Linux right now, but it's not
that far away either. Add to this the fun of window managers, and you
have a very daunting situation for the people "who don't use computers
for other purposes", as you described them. In fact, critics of X often
cite this as a primary disadvantage of the X model. (actually it is
difficult to think of insults that *haven't* been leveled at X, but
that's a separate debate).

Now of course we're talking about LADSPA hosts rather than X in general;
but I think the situation is analogous. If you're going to ensure the
ability to do chrome, I would strongly suggest a way to ensure
consistency in behavior and appearance between plugins. Or at the very
least, consistent behavior. Especially considering the user group you
say you're going for. I would also suggest you check in with plugin
developers to see what they want, as well as potential "newbie" users.

The "practical argument" I mentioned at the top of my post is that
excessive focus on chrome-freedom can tend to cause neglect of the
usability and consistency aspects, even if only because chrome can take
so much time to implement. I was not making the argument that these
qualities are mutually exclusive, nor did I make the argument that
somehow wanting a chromey interface makes you a loser (the "arrogance"
you cited above.) I said nothing of the sort--given that themes.org is
becoming its own mini-demoscene, I don't know how anyone could really
maintain such a position.

----

* This is a side issue, but I also object to your throwback stereotype of *nix people. If you entertain the (old) idea that *nix people can't be artists or musicians or poets or anything besides Un1x HaX0rz, I can't say that would be terribly inviting to a non-computer-savvy musician or tech who is thinking about switching from Win32 to your software on the UNIX or Linux platforms.

It was also uncalled-for. Sorry--this kind of personal jabbing and endless politicizing is actually one of the primary reasons why I continue to doubt the future of LADSPA.

-- @@@ david o'toole @@@ dto_AT_gnu.org @@@ www.gnu.org/software/octal


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri May 26 2000 - 00:57:27 EEST