Fwd: we need a first-time wizard (from Rosegarden's mailing list)
- To: "Debian Multimedia" <firstname.lastname@example.org>
- Subject: Fwd: we need a first-time wizard (from Rosegarden's mailing list)
- From: "Herman Robak" <email@example.com>
- Date: Wed, 18 Jan 2006 22:48:31 +0100
- Message-id: <firstname.lastname@example.org>
- References: <email@example.com>
I found this posting lamenting the state of the sound infrastructure
on Linux very apropos to the thread about a multimedia policy for
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"
Subject: we need a first-time wizard
Date: Tue, 17 Jan 2006 17:58:25 +0100
I'm not sure why this never occurred to any of us sooner. We've tried
strategies to accomplish the same sort of job, with varying degrees of
success. My book has gobs of info dedicated to get-sound-working
Studio..to Go! has extensive scriptage to try to get JACK working out of
box. Musix has these scripts you can run that start QSynth with a
and start Rosegarden automatically (I think... been awhile since I looked
Musix, and I'm sketchy on details.)
All three of us have been trying to solve the same set of underlying
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
The reason is because users have too damn many choices, and it's
write something that covers every eventuality while it maintains a tight
"code path" for the readers to follow through working out the particulars
their specific situation.
I've had to walk people through the same Q&A questions so many times it
me want to vomit just thinking about it. As have any of us who bother to
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
and make recommendations what they should do next. Eventually, through a
process of aggregating new cases as they arise, this tool could evolve
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
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
people get this crap to work again and again and again.
At the very least, we could do an analysis, and provide simple
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
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
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,
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
to make it clear that anyone insisting on screwing around with something
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
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
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
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
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
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
just changes too fast to keep up with. A compartmentalized, tutorial-based
model might be more productive compared to a traditional, monolithic
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
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
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 at skolelinux no