From: D. M. M. <mic...@ro...> - 2007-12-30 16:43:08
|
How did we wind up with this nomenclature? I was writing out a little quick tutorial on another list, and I realized that the workflow for using Rosegarden with ZynAddSubFX, for example, strikes me as needlessly tedious. 1) Start the synth 2) Go to Manage MIDI Devices, and find which "MIDI software device 57" is the one that got assigned to the new synth. (Or reassign "MIDI external device 43" to the new synth; whatever.) 3) Change the name to something that isn't nonsensical, so you can actually find the damn thing again 4) Go assign stuff to play with this newly renamed device It seems like we could eliminate that work by coming up with names that make more sense automatically. Something like "ZynAddSubFX" for example, or "ZynAddSubFX (write)," depending on just what's in the ALSA string. Going through my quick list of old favorites, it looks like both Zyn and Hydrogen have sensible names. QSynth calls itself "Synth input port ($PID_OF_SYNTH_INSTANCE:0)" which is not all that obvious, but is "MIDI software device 26" any better? I wonder what we could do. Pushing the ALSA port name seems as sensible as anything else to me, and if applications have stupid names, we could encourage the synth developers to tweak one line in their code somewhere, and many would probably comply. Looking at MuSE and seq24, that's exactly what you get anyway, so Rui really does have a valid reason to make "Synth input port" into at least "QSynth input port" to make everybody's life in all Linuxdom easier. I guess part of the idea here was about things like emu10k1 port 0 through 4 and whatnot, trying to make it more clear that that is a playable thing. But if anything, we know the emu10k1 is a dead end line that isn't going anywhere, and it's virtually the only thing with a playable in-the-chip hardware synth, so we could just hard code an exception to that one thing, anything with an emu but not a UART we call "Creative internal synth 0" or something? Discuss! (Please? I'm getting lonely in here.) -- D. Michael McIntyre |
From: Arnout E. <ros...@bz...> - 2007-12-31 12:14:10
|
On Sun, Dec 30, 2007 at 11:42:54AM -0500, D. Michael McIntyre wrote: > How did we wind up with this nomenclature? ("MIDI software device 57") The only problem I can imagine is when several devices using the same name - in that case it might make sense take the name and prefix the ID to it. Otherwise, using the names seems like quite a sensible idea. Arnout |
From: Chris C. <ca...@al...> - 2007-12-31 20:41:27
|
On Sunday 30 December 2007 16:42, D. Michael McIntyre wrote: > How did we wind up with this nomenclature? > > I was writing out a little quick tutorial on another list, and I > realized that the workflow for using Rosegarden with ZynAddSubFX, for > example, strikes me as needlessly tedious. > > 1) Start the synth > 2) Go to Manage MIDI Devices, and find which "MIDI software device > 57" is the one that got assigned to the new synth. (Or reassign > "MIDI external device 43" to the new synth; whatever.) > 3) Change the name to something that isn't nonsensical, so you can > actually find the damn thing again > 4) Go assign stuff to play with this newly renamed device What I usually do is kind of the other way around, and shorter: 1) Start the synth 2) Check which device is used for the tracks I want to play to it 3) Go to Manage MIDI Devices, and set the Connection for that device so that it points to the synth 4) Play (without reassigning anything) This mode of use -- leaving the devices as they are in the file, and just diddling with the connections to make them up to date with what's actually "plugged in" -- gets us part way to the reason it's designed 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. Rosegarden's Device (the thing that's named MIDI External Device 2 or whatever it happens to be) is intended to be the container for all the information that's under your control about what you want to play through. So you give it the name of the device you want to use ("My Boring Old GM Synth", "My Roland MT-32" etc), you set the bank and program names etc to match your hardware, and so on. This stuff consists of known quantities, a sort of "ideal environment". But, MIDI being MIDI, you can't guarantee that your boring old GM hardware module is actually there when you reload your file, or that it's on the same ALSA port numbers, and Rosegarden has no way to query whether it is or not, so that's where the Connection comes in -- the set of available Connections is exactly the set of actual MIDI ports right now; each Device is set to output to one of those; and you can change the mapping without losing any of the other stuff you've specified about the Device. That is, if your module is on the wrong port when you reload, or you want to use qsynth instead, it's intended to be just a question of changing the Connection for the device (it's still "My Boring Old GM Synth", it's just in a different place) and leaving all the other settings intact -- provided the thing you're playing to now is sufficiently compatible with what you previously configured. This goes double, in theory, when sending files to other people -- they know it's supposed to be a boring old GM synth, they just need to connect it to whatever they have available that most closely matches that description. Note that this paradigm breaks completely if you always load the default studio, because then your file doesn't contain any of the information you need to determine what it was actually supposed to be played through. (Though I can see why you might want to use that option in some situations given the shortcomings of the current system.) So the short answer to "why is the device not called ZynAddSubFX?" is "because it would be confusing if the device was called ZynAddSubFX and then it came up connected to some other synth because ZynAddSubFX wasn't running". Well, we could try to make sure it _didn't_ come up connected to something else if Zyn wasn't running -- but I guess we've taken the position that it's better to always try to play through something than nothing. Or we could rename the device if it came up connected to something else -- but then it would likely have the wrong set of programs for the sort of device it said it was. The device name has to stay consistent with the program names; we can't deduce the right set of program names from the ALSA port or whatever we're playing to; therefore the device name has to be distinct from the ALSA port name. > I guess part of the idea here was about things like emu10k1 port 0 > through 4 and whatnot, trying to make it more clear that that is a > playable thing. That's not really the motivation -- the names we have now are more a consequence of trying to find ways to make the system workable than an outcome of the reason for the system in the first place. If we were to take the Rosegarden approach to its logical conclusion, the default names for devices would be "Default Device 1", "Default Device 2" etc or something equally (even more than currently) hopeless, and you would be expected always to name them yourself. The reason we have any sort of meaningful name at all is to try to give a hint towards the sort of devices you might want to in your file, which you then (in theory) tune to your satisfaction, save in the .rg file, and send to your friends. In reality, of course, you curse and then ignore them. But for the reasons a little further above, I don't think it's necessarily the answer to always name the devices after their connections either -- though it's tempting, particularly for software synths. The current system might work much more straightforwardly if there was a simple way to change the connection for a device from the main window. But despite all our parameter boxes, we don't even have a box that shows the device and its connection in the same place, let alone allows editing them. There is no Device Parameter Box. 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: 1. At the top of the instrument parameter box, we currently have the connection displayed as e.g. [ 129:0 Synth input port (5065:0) ] This is basically the form [ Connection name ] We shouldn't, I think, make this directly editable as a combobox here, because that would suggest we were changing some property of the instrument for the track and that isn't the case. But we could show something like Device name [i] Connection name Where [i] is a push button with an icon representing connection on it. The button would have a tooltip saying "Change connection" and when clicked would call up the Manage MIDI Devices dialog with this device highlighted. 2. Make a policy of never (OK, hardly ever) showing device names without showing their connection as well. The displayed name of a device should be "Device name: Connection name" or some such, everywhere. 3. Make the default device names really short. Like, just 1, 2, 3 or A, B, C or something. They would still be re-nameable, but they wouldn't distract from the connection names per default. I can think of a few ways this might continue to confuse... perhaps we should try it on a branch. Any comments? Chris |
From: D. M. M. <mic...@ro...> - 2008-01-01 02:29:26
Attachments:
example.jpg
|
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 |