On Wed, Mar 25, 2009 at 5:35 PM, Julie S <[email protected]> wrote:
> First could you clearly define what you mean by 'device'?
>
> I'm guessing you mean an RG internal connection point that is named in the 
> studio like 'system device 2.'

Yes.  I've tried to be fairly consistent in any emails I've sent in
this thread, that "device" refers to something internal to Rosegarden
(which can be connected to any MIDI client), and the thing you connect
it to is referred to either as a MIDI client, or as something specific
like a synth.

> What if somebody saves their studio setup with that default pointing 
> somewhere else?

If we're loading a saved studio, we should honour whatever it says.
That does imply that we need to distinguish between a factory autoload
and a user-saved studio, which is something we don't currently do at
all.

> What happens next time I load rosegarden and the device is not present?  
> Maybe it is a USB interface device that is plug and play.  What would 
> rosegarden do with the connection?  Will is say 'not connenected,' or list 
> some other message, or try to reconnect to a different device?

Going purely on the logic of my point 2, we would bring it up with "no
connection" (because it had a connection in the saved composition, but
we have been unable to match it when loading) and then connect it only
if the user subsequently starts up a plausible MIDI client (of any
sort) without having connected it to something else first.  I don't
know how far that logic makes sense, though.

> Maybe the solution is to lock and unlock each device.  Once a device is set 
> to the users preference, the user can lock that connection, so that each time 
> RG runs its tries to honor the connection, but doesn't forget it if it 
> doesn't exist.  Maybe with a suffix in the connection box stating 
> 'un-reachable' or 'not found.'

That idea could have merit.

> Also say a device isn't plugged in, so the user makes a 'temporary 
> connection' just to get things running.  What should we do if the user then 
> subsequently saves the file.  Should we save the temporary connection, or the 
> studio defaults with the file?  Hmm...

In a situation like this, it's probably better to be consistent and
predictable than try to be too clever (look what a mess that got us
into last time around!).  So, I would say that we save the new,
temporary connection and the user just has to put up with it.  Of
course it still has all the same bank and program definitions and so
on for the old device, though, unless the user went and changed those
too.


Chris

------------------------------------------------------------------------------
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

Reply via email to