On Friday 20 January 2006 05:33 am, Chris Cannam wrote:
> To that end, we probably need to start trying to write down (purely in
> text I mean) what things we know of already that can be wrong, and what
> we can suggest is done about them. If it turns out that some of the
> suggestions might actually be helpful, then we have something to go on.
You're all missing the point to some extent. I realize we can't *fix*
everything automatically. That's why I spoke of fixing what it was possible
to fix.
Here are some things we *can* fix:
We can modprobe snd-seq-midi or whatever if the module exists for the kernel
they're running (this one has been cropping up quite a lot since people
started switching to udev). This should be done in some kind of context like
"I detected you didn't have module blah. You need this module for the MIDI
infrastructure to work. I can load it for you now, but you should go do
bliff (1) to avoid this coming up again next time."
We can detect if they have an emu10k1, but
a) don't have the necessary utils installed
solution: apt-get install awesfx||urpmi [syntax] awesfx||emerge
[syntax]
awesfx
b) don't have a soundfont loaded (`asfxload -M|gawk '{print $5}'` == "131068")
solution: Tell them to go get a soundfont, offer to configure
Rosegarden to
load it at startup, even offer a link to one on the web, or hell, a script to
wget it (like the Debian packages that download things like non-free plugins)
and install it for them some place we know about, and can make Rosegarden
aware of automagically (~/soundfonts/some-font-we-snarfed.sf2)
We can detect if they have an AC97 or other card with a hardware port, and
just simply *ask* them if they have a MIDI keyboard or synth module hooked up
to it, then recommend a solution if they don't. The solution could be
similarly automated.
Some things we can't fix:
Bad kernel. This would be one of the trickier things, since kernels evolve
comparatively rapidly. We can speak of the past, and speculate about the
future. Kernels up through 2.6.13 (I think) won't run Rosegarden + QSynth +
JACK on a 2.6 GHz 1024 MB machine without realtime-lsm. No realtime-lsm,
they probably have a crappy kernel. Timer set wrong, they definitely have a
crappy kernel. All we can do is make broad recomeendations here.
Alright, I'm not out of thhoughts, but the ddoubblingg thingg is happenign
again and none of my usual voodoo tricks are getting this damn editor to
become responsive. I'm going to quit before Ii throw something. I think
I'll gou pgrade KDE and see if it finally fixes this fscking probleem..
1) Spelling out "bliff" is tricky, admittedly, but it's probably possible to
come up with a set of generic instructions that will work for most of the
users most of the time, and if there is a large segment of users for which
the bliff instructions don't work (which we will hear about in due course),
then it becomes worthwhile to start writing in distro-specific instructions,
and detecting what distro they're running.
cout << "You need to ";
switch (userDistro) {
debian: cout << "edit /etc/debian-whatever"; break;
fedora: cout << "edit /etc/fedora-whatever"; break;
default: cout << "edit /etc/the-usual-whatever"; break;
}
--
D. Michael 'Silvan' McIntyre ---- Silvan <[EMAIL PROTECTED]>
Linux fanatic, and certified Geek; registered Linux user #243621
Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
