On Wed, Mar 25, 2009 at 2:28 PM, Chris Cannam
<cannam@email-addr-hidden-day-breakfast.com>wrote:
> On Wed, Mar 25, 2009 at 2:45 AM, D. Michael McIntyre
> <rosegarden.trumpeter@email-addr-hidden> 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@email-addr-hidden - use the link below to unsubscribe
> https://lists.sourceforge.net/lists/listinfo/rosegarden-user
>
possible option 4?
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@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
Received on Wed Mar 25 16:15:01 2009
This archive was generated by hypermail 2.1.8 : Wed Mar 25 2009 - 16:15:02 EET