Fwd: we need a first-time wizard (from Rosegarden's mailing list)

["Herman Robak" <herman@skolelinux.no>]

I found this posting lamenting the state of the sound infrastructure
on Linux very apropos to the thread about a multimedia policy for
Debian.

Since the Rosegarden mailing list is available through Gmane,
I consider the posting below to be on public record, and repost
it directly for convenience's sake.


---- Forwarded Usenet-message ----
From: "D. Michael 'Silvan' McIntyre"  
<rosegarden.trumpeter-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Newsgroups: gmane.comp.audio.rosegarden.devel
Subject: we need a first-time wizard
Date: Tue, 17 Jan 2006 17:58:25 +0100
URL: news://<200601171158.25219.rosegarden.trumpeter@gmail.com>

I'm not sure why this never occurred to any of us sooner.  We've tried  
various
strategies to accomplish the same sort of job, with varying degrees of
success.  My book has gobs of info dedicated to get-sound-working  
questions.
Studio..to Go! has extensive scriptage to try to get JACK working out of  
the
box.  Musix has these scripts you can run that start QSynth with a  
soundfont
and start Rosegarden automatically (I think...  been awhile since I looked  
at
Musix, and I'm sketchy on details.)

All three of us have been trying to solve the same set of underlying  
problems
in different ways.  I'll just look at it from my perspective from here out.
What's the big deal with get-sound-working stuff in my book?  Why is it my
albatross?

The reason is because users have too damn many choices, and it's  
impossible to
write something that covers every eventuality while it maintains a tight
"code path" for the readers to follow through working out the particulars  
of
their specific situation.

I've had to walk people through the same Q&A questions so many times it  
makes
me want to vomit just thinking about it.  As have any of us who bother to
answer questions.

So it occurs to me what what we need is some kind of canned, readily
available, user-friendly runnable diagnostic tool to look at what they  
have,
and make recommendations what they should do next.  Eventually, through a
process of aggregating new cases as they arise, this tool could evolve  
into a
one stop shop that tells people what's wrong with their system, and exactly
what they need to do about it.  It would be impractical to support *every*
distro, or to keep it up to date with references to the latest packages for
the latest versions of the latest distros, but there's a lot of room  
between
totally generic and totally specific in which to build a useful tool that
takes a lot of the pain out of getting this crap to work, and out of  
helping
people get this crap to work again and again and again.

At the very least, we could do an analysis, and provide simple  
recommendations
in consistent language.  This would be a start, but probably not enough of
one, because then they would just turn here and say "Rosegarden told me to
run QSynth.  I'm running Rabid Cow Linux 0.3 from 1997 on a 286-12 with 4K  
of
RAM, and I can't figure out how to get this to work."  I think we need to
find some middle ground between a mere analysis and targeted, specific
recommendations.

I also think we need to draw some lines in the sand and say "Sorry, your
computer is [too slow|doesn't have enough memory|other] to run Rosegarden"
and just end it there.  That way we don't give anybody running on a PII-233
with 128 MB of RAM any false hope that they're going to get Rosegarden,  
JACK
and QSynth working on a stock kernel.  (I can't get Rosegarden, JACK and
QSynth working on a P4-2.6 with 1024 MB of RAM with a stock kernel.  Let's
keep this perspective realistic, rather than optimistic, folks.  It's  
better
to make it clear that anyone insisting on screwing around with something  
too
far to the fringe is pushing a boulder up-hill.)

Anyway, this is only the first nugget of an idea, but I'm thinking the  
perfect
avenue for this kind of detection/suggestion and even system modification
tool (when possible, like modprobing modules that already exist, for
instance) would be in the form of the same sort of first-time/bad settings
wizard that K3b uses.

If you start K3b with a bad setup, it takes you to a flummy that lets you  
use
its provided tool to chmod and chown various things as required to get your
burner working.  We can only solve a few audio-related problems through  
such
simple means, but we could still offer a useful, system-specific roadmap.

I guess the only problem is that if we had something that worked as well  
as I
envision, it might deprecate both STG and Musix.

Anyway, it would make writing a future Rosegarden book a much easier thing.
I'd have to keep some bits about how to work instruments and studio setup  
and
whatnot, but I could leave all the sound/MIDI/JACK/audio questions at the
door, and get straight down to business.  Without this albatross on my
shoulder, I might actually feel some inspiration to write again, whereas at
this point in time I really don't see any remaining future for the whole
concept of a Rosegarden book.

It may well be that I still don't, mind you.  This stuff, all of this  
stuff,
just changes too fast to keep up with.  A compartmentalized, tutorial-based
model might be more productive compared to a traditional, monolithic  
book.  I
have no idea at this time what future, if any, I have as a writer in
association with this project.  With my sales so abysmally low, and the  
luke
warm reception I got for this massive effort, I'm not much inclined to have
anything further to do with any of it, but maybe that could change if it  
were
easier to get started in the first place, without the hated albatross.

The biggest failing of the Rosegarden book was that it didn't answer these
questions satisfactorily, and I wasted so much time going over that same
material countless times, that it left little room for me to complete the
real substantive bits of the thing.  Hence some of the crap reviews I got
about being too elementary.

OK, now I've lost my way, and I'm starting to ramble, so I will shut up now
and go eat lunch.



--
Herman Robak
herman at skolelinux no