On Wed, Mar 25, 2009 at 5:31 PM, Chris Cannam
<can...@all-day-breakfast.com>wrote:
> On Wed, Mar 25, 2009 at 2:22 PM, Chris Cannam
> <can...@all-day-breakfast.com> 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
> rosegarden-u...@lists.sourceforge.net - 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...)
------------------------------------------------------------------------------
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-devel mailing list
Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
