On Monday 01 February 2010, Chris Cannam wrote: > This was prompted partly by my experience at the Linux audio > conference in 2008... but having the instrument come up labelled as > unconnected would at least have made for a more obvious prompt as to > what was wrong.
So we have no detectable soft synth at startup, but we do have a detectable "input-only MIDI keyboard." Whether this would behave well or not depends on the nature of that keyboard. If it's truly input-only, then we wouldn't ever choose that for a playback port. No worry in that case. If it's a keyboard connected to the input side of something like my duplex UM-2, then we're going to pick that just before giving up with "no port." That would be wrong if there was no connection on the playback side of that hardware that could do something. Not connecting has a 100% chance of failing. What are the odds of failing if we do try to connect to that duplex USB MIDI port? That's hard to calculate. They could easily have a play connection back to the same keyboard they're using for input. They could have a play connection to a sound module. They could have the play connection dangling useless, with only the input side of that duplex port in use. What are the odds? I really don't know, and it would take a survey to get a real figure for this. So if it fails, is seeing that your playback is connected to "no port" more obvious than seeing it connected to "UM-2 MIDI 1 (duplex)?" That seems to be what you're arguing. This argument would be especially powerful if the user expected to be able to start QSynth after the fact and have it grab that empty connection that was left open when nothing plausible was found. The way things are working at present, that won't happen. In fact, if I go off and start QSynth while Rosegarden is running, Rosegarden never makes this choice available, even after refreshing the ports list. I can't connect something to QSynth unless I start QSynth before Rosegarden. That seems wrong, but I'm not inclined to do anything about trying to fix it. So as things stand now, whatever was there at startup is all we have to work with. It seems to me we might as well try to connect to *something*, even if it doesn't work. Not doing anything has a 100% chance of failing to come up with sound working. If, however, we had the ability to detect QSynth started after the fact, and connect device 0 to it *if device 0 was previously not connected* (because we ignored hardware), then it might be better to revert that part of the last commit, and never choose a hardware play device by default. (The odds of it ever being right are impossible to know, but they can't be very good.) I think as far as I'm involved from here, I'd just as soon go with the last commit for now. Since there's one and only one chance to get it right, we should do everything possible to avoid a 100% chance of failure. I do think we should eventually go back to detecting new clients, and then when that works, we should think about plugging the hole in an empty device 0 to the new connection when it appears. I'm not interested in working on that at this time, however. -- D. Michael McIntyre ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
