On Wed, Mar 25, 2009 at 2:28 PM, Chris Cannam <cannam@xxxxxxxxxxxxxxxxxxxxx> wrote:
On Wed, Mar 25, 2009 at 2:45 AM, D. Michael McIntyre
<rosegarden.trumpeter@xxxxxxxxx> wrote:> Discuss.
No argument about the need to try to improve on the old experience.
I do think though (as I mentioned the other day in an off-list email)
that any time the user has to go to the Manage MIDI Devices dialog,
the terrorists have already wo-- sorry, I mean, the rest of the
interface has failed.
That joke was a bit old. I apologise.
This I think is the use-case in which I think RG 1.x fails most
seriously (because it fails in bad and unpredictable ways, and because
it's a common use-case):
1. User starts RG
2. User starts qsynth, timidity, or some other software synth (this
might happen before 1, but the result is similar)
3. User wants to play their composition through that synth
RG 1.x fails this for two separate reasons. First, if it creates a
new device for this synth, the device will have some totally unhelpful
name because RG is too non-committal to give it a sensible name.
Second, even if you were prepared for that, it's just as likely to
connect the synth up to some device that already existed but was not
connected before.
It should not be necessary to go to the Manage MIDI Devices window to
make this one work. I suspect that a lot of casual users never even
find that window, apart from anything else, before dismissing the
program as impossible to use.
Removing device auto-creation doesn't really help with that one. The
critical part is being able to select your target synth using a
meaningful name (not just some virtual RG device) directly in the user
interface, preferably directly from the track header. This could mean
either auto-creating a device with the right connection and just
naming it more sensibly, or making it simpler to select the
_connection_ rather than the device (i.e. to redirect an existing
device to a new connection).
Here's the other big important use-case:
1. User uses RG for something, saves file
2. User loads file later, presses play
3. User expects file to play through same synth(s) as before
(assuming they are available).
Removing device auto-creation _does_ help with this one, but it still
won't guarantee we always get it right -- we'd still be at the mercy
of the auto-connection-to-similar-sounding-connection-name logic,
unless we expected the user to always restore their connections by
hand every time they loaded a file. At least, removing device
auto-creation should make it easier to fix this situation if the
defaults come up wrong.
I was hoping to be able to link to an illustrative video about this,
but I can't find it any more. At last year's Linux audio conference I
had to go up and help out Julius O Smith (noted Stanford DSP guy)
during his presentation because he couldn't get Rosegarden to play to
the synth he was trying to demonstrate (a software synth of his own
devising). The cause of the problem was that, although he'd carefully
saved his composition with the right device connected to the right
connection, a new USB MIDI device had been connected at some moment
between his last successful test and the live demo, and the track was
playing to that instead. Worse, the USB device was a controller
keyboard with no synth (it was playing to the keyboard's MIDI output
port to which nothing was connected). Two people failed to fix this
before I went up.
Removing device auto-creation would go some way to solving that
problem, but only to the extent that the device came back up connected
to the right connection even though the available ALSA MIDI devices
had changed and re-ordered since the devices were set up. If that
failed, it would be much more apparent how to fix it if the connection
was more obvious and more easily editable in the main GUI itself.
Just for completeness, there is also a third use-case which was
prominent in our minds when we first (mis-)designed this stuff:
1. User makes composition
2. User passes composition to friend
3. Friend lacks same MIDI devices, but device names in composition
help friend work out how to recreate the setup
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-user@xxxxxxxxxxxxxxxxxxxxx - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-user
First opening of the midi device manager shows GM device, and an extra entry, titled "Add new connection".
It does precisely that, and the user selects from a dropdown list of connectable devices, that RG has detected.
And as each connection is added, the "Add new connection" option stays in view and ready to rumble, at the bottom of the list.
Another vote here for user creatable jackmidi ports. (For future consideration.)
Alex.
--
Parchment Studios (It started as a joke...)
--
Parchment Studios (It started as a joke...)
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
