From: Julie S <msj...@ya...> - 2009-03-25 17:36:00
|
Hello All, Considering Chris C.'s five items. 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.' If that is true then just a generic midi device that follows 1 and two that you mentioned is fine. Chris wrote: > 1. On first startup with an empty composition, we should > have one > output device, connected to some plausible looking MIDI > client if > there is one. ("Plausible-looking" means that ALSA > reports it as a > software synth or a hardware port.) You want any more > devices in your > composition, create (and connect) them yourself. > > 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. > I specially like the idea of not creating any new devices. What if somebody saves their studio setup with that default pointing somewhere else? We need to make certain to honor that request not over ride it no matter what the configuration setting is in 3. say that their choice for the device is 'no connection.' Chris wrote: > 3. Make the auto-connect parts of 1 and 2 optional in > configuration? > > 4. When loading an existing composition, do our best to > connect the > devices in that document to connections that look the same > as the ones > they were connected to before it was saved. In the > ideal case where > all the MIDI devices are exactly the same as they were > then, we should > be able to do this perfectly... Well, 3 is fine, but like has been mentioned. The device must already exist in the manager and it must not be connected to any output. But without some kind of sanity check that may lead to some misleading connections as well. For instance, say I have a drum machine I connect occasionally to the machine. So I enter the info into the device manager. 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? 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.' I guess the default Studio file sort of does this. 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... I don't think RG currently keeps track of defaults. It just loads in a autoload.rg file or something each time a new composition is started or loaded. So this could be an issue as well. I guess we could always move a 'default' studio setup into the configuration file, that way loading saving and setting a studio file would have more staying power. Maybe I'm all wet on this one. I hadn't really reasearched this. Chris wrote: > 5. Make it simpler (somehow!) for the user to see and > change > connections in the main user interface, without having to > use the MIDI > device dialog. Adding and removing devices however > will involve the > dialog. Well, a dialog box would be nice, but again this action should be controlled as a configuration option. This is tough because, we can't just assume that a new device is for RG. Many people run multiple apps, and having RG connectying to them automatically or displaying some modal dialog could be annoying. Michael, I bet you just love the idea of all of these new configuration settings?! Sincerely, Julie S. |
From: Julie S <msj...@ya...> - 2009-03-26 00:29:11
|
Hello All, >From the discussion: > The IPB currently shows the ALSA port the instrument is > connected to. Just > make it editable here. Most users would never need to > use the device manager > ever again if... > I like that idea. > > > In no circumstance do we create or delete a device > automatically, > > except the very first one in an empty composition. > > ...if we DON'T enforce that rule. This part I don't > agree with. If a user > changes something while we're running, odds are they meant > to do that, and we > should act on it. If Hydrogen starts, and no device > lacks a connection, then > create a device for Hydrogen and connect to it. > Optionally we could ask, and > that's what Emanuel and I were thinking the other day, but > now that I've seen > how the "detected that you started a new synth" code runs > in an environment > that isn't trashed up with a bunch of extra garbage, I > think it is probably > safe to assume the user meant to do that in this kind of > situation, and it's > OK to be helpful. > > Especially bearing in mind rule 2. DON'T create the > new device for Hydrogen > if there's already something empty to fill. Here again, how do we know the user wants Hydrogren to occupy a device. Maybe the device was created for another purpose--like a yamaha sythn or something. Basically, we need to distinguish between 'no connection' (intentional) or 'no connection' (but available for what ever). I guess my thought is that if I name a connection "yamaha xg synth" and don't currently have it connected --therefore RG doesn't find it--I don't want Hydrogen filling the gap. We need a way to let RG know when to fill the device. So say I create and set the yamaha xg synth device. on another run of RG, If a new device is connected, it should first see if it matches the yamaha device criteria--whatever that is--and only connect to that device if it matches. But a device that is 'available for whatever' comes available can take the connection. I mentioned locking--which has some potential. But, I think just a two state system in the connection manager would work: "available": which means its ready to receive new connections "not connected": which means the device did not find a matching connection. ---actual verbiage is up for debate. Therefore, the logic for "auto sensing" would first attempt to match to "not connected" devices--checking connection criteria. If that fails, find an "available" device. How much logic do we can incorporate? I don't know. I don't really know the limits of what is communicated to RG. Michael says: > > But if there isn't, no, I don't think I should have to go > invoke the MIDI > device manager and manually create a device just because I > started Hydrogen. > Yes. I agree. But this still goes back to auto-connect issues. How do we distinguish between all the clutter that RG sees upon startup and a new device starting or being plugged in. Obviously timing. In one case RG is just firing up. and we can promise not to create devices at this stage. After RG is up and going, when it sees a new connection then it could be nice and 'create' a device. But I would want this logic to be very clear. Otherwise, we will end up with RG making devices all over the place. Also, I don't think this behavior is alway beneficial. But more often than not is. > Let me add here at the bottom that one thing all of this > discussion > presupposes so far is that the user has something "General > MIDI" at all. ... I like the idea that RG tries to establish a General MIDI connection if no devices are present. But beyond that it should not create any devices on its own. That will solve much of this. Sincerely, Julie S. |
From: D. M. M. <ros...@gm...> - 2009-03-26 01:06:23
|
On Wednesday 25 March 2009, Julie S wrote: > I like the idea that RG tries to establish a General MIDI connection if no > devices are present. But beyond that it should not create any devices on > its own. That will solve much of this. You raise good points. I'm getting a headache contemplating them though, and I think I finally reached my limit for today. :) -- D. Michael McIntyre |
From: Chris C. <ca...@al...> - 2009-03-25 18:47:18
|
On Wed, Mar 25, 2009 at 5:35 PM, Julie S <msj...@ya...> 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 |