From: alex s. <com...@gm...> - 2009-03-25 15:12:59
|
On Wed, Mar 25, 2009 at 5:51 PM, alex stone <com...@gm...> wrote: > > > On Wed, Mar 25, 2009 at 5:31 PM, Chris Cannam < > ca...@al...> wrote: > >> On Wed, Mar 25, 2009 at 2:22 PM, Chris Cannam >> <ca...@al...> wrote: >> > 2. If a new "plausible-looking" MIDI device appears while we're >> > running, and _if_ an existing device has no current connection at all, >> > connect that to it. Don't create any new devices. >> >> For what it's worth, I can think of several situations (including the >> Linux audio conference MIDI keyboard one) in which you wouldn't want >> this to happen. But I can also think of situations (including the >> starting RG first, then qsynth one) in which it could be frustrating >> if it didn't. Opinions either way? >> >> Point 5 might help in both situations: >> >> > 5. Make it simpler (somehow!) for the user to see and change >> > connections in the main user interface >> >> but that is _certainly_ in need of refinement... >> >> Thanks for kicking this thread off, by the way Michael. >> >> >> Chris >> >> >> ------------------------------------------------------------------------------ >> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are >> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and >> easily build your RIAs with Flex Builder, the Eclipse(TM)based development >> software that enables intelligent coding and step-through debugging. >> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >> _______________________________________________ >> Rosegarden-user mailing list >> Ros...@li... - use the link below to unsubscribe >> https://lists.sourceforge.net/lists/listinfo/rosegarden-user >> > > Chris, i think Julie nailed it best of all. > > Setting up big templates, and all the associated banks, patches, etc is > tedious at the best of times. It gets extremely frustrating when trying to > develop continuity across more than 1 app, i.e. LS, RG, and Ardour, when > there's no certainty that ports will react in the same way, or stick to the > plan/template. > > Going forward, i think Julie also has it right with an inbuilt synth for > those who want to plug and play. (Which is, in reality, the same as building > a common template across apps, then simply starting them all up and starting > to write. Like an extended plug and play.) > > So, what about, for discussion at least, having 1 port which is a dedicated > internal synth, have the ability to disable it at compile time, if we wish, > but leave the rest of the port structure as my option 4 in the previous > post. > > 1 constant synth. (Not midi ported out at all, but internal) > "Add new connection" (with the current list of available ports to choose > from.) > > I'd also ask you consider making save, as a rigid option. I mean a project, > once saved, ONLY has the ports/devices chosen, with only 1 added line in the > device window, "Add new connection." (Not 17, because RG is enthusiastic > about the other ports it sees.) > > I can't count the number of times i've had to reroute manually, because > General Midi Device insists on connecting to 1st Violins, even in the face > of rampant and persistent saving. > > Please, dumping autoconnect sounds like a great idea, and a simple solution > (from a user perspective) to one of the very few frustrating elements within > the current RG build. > > imho. > > > > Alex. > -- > Parchment Studios (It started as a joke...) > As a quick addition, should the RG team decide to go for something like this, i've been testing 64Studio beta 3, and as a result, I've uninstalled Timidity, for stability reasons. No offence to the Timidity devs, but something in there pushes the CPU usage up significantly, and decreases stability. (My subjective view only.) Others have since reported the same improvement in stability and performance when uninstalling Timidity, so maybe there's a challenge somewhere in the app. Fluidsynth seems to be no problem here at least, so maybe, as a default internal synth, this would be a better choice. Alex. -- Parchment Studios (It started as a joke...) |