[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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" <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

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

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

Reply to: