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. -- 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 Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
