Re: [Rosegarden-devel] MIDI external device 43

[D. M. M. <mic...@ro...>]

On Monday 31 December 2007, Chris Cannam wrote:
> like this in the first place.  Let me go over this again because I
> think the logic makes some sense, even though I completely agree it
> works very badly in many common situations in practice.

I understand where you're coming from with trying to keep the "slots" vague=
=20
enough that you can plug some suitable alternative in, but my contention is=
=20
that the names are so vague that they don't give any indication what might =
be=20
suitable.  You also miss out on the advantage of having the first segment=20
carry a hint in its default label.

We never did come up with some kind of pop-up info window where you could=20
leave a note to future generations, so these little hints are really quite=
=20
useful when trying to figure out how to make something of someone else's=20
file, or something you last worked on a year ago. If I rename the device=20
to "ZynAddSubFX" then go create something, people get a hint, as demonstrat=
ed=20
in this real world example:

(example.jpg)

But skipping ahead through a lot of back and forth stuff where I started at=
=20
the top with arguments that you had refuted by the time I read all the way=
=20
down, I do see where you're coming from.  Even in this example, knowing the=
se=20
tracks were intended for ZynAddSubFX doesn't suggest anything about what=20
patch to use.  There really isn't any way for me to send you this file and=
=20
have you play it without making, say, a project package including the .xmz=
=20
and a README file.

Then the temptation to use the name for soft synths really breaks down in t=
wo=20
cases I can think of.  First, we need a GM here, and that could be external=
=20
hardware, internal hardware, or QSynth, so calling the device "QSynth" (or=
=20
whichever other of the three the composer was using at creation time) isn't=
=20
really all that helpful.  Second, what if it's really supposed to be QSynth=
 +=20
SomeFont.sf2, where an emu10k1 would be a fine stand-in, but an external GM=
=20
synth would not.

It's kind of dead end thinking where the easy thing I want to grab onto fir=
st=20
doesn't really lead to a viable solution without hacks on top of hacks to t=
ry=20
to address special cases.  Touch=E9, touch=E9 indeed my friend.

> In the spirit of trying to make the best of what we've got, let me
> suggest the following relatively simple set of adjustments to the
> current system:

[...]

> I can think of a few ways this might continue to confuse... perhaps we
> should try it on a branch.  Any comments?

It's hard to think through all the possibilities without a field test, but =
it=20
seemed sensible enough I didn't see any need to address specific points.

Not that this issue is suddenly an end of the world matter to me in any eve=
nt,=20
if you don't have time to bother with this just now.  But it does seem like=
=20
we could manage something better than the present scheme.  The ensuing=20
conversation on the other list seemed to support the idea that there are=20
other users who find the current scheme too obtuse.
=2D-=20
D. Michael McIntyre=20