I'm just making an announcement. Nobody wants to read the 20-page discussion document I just wrote to think out loud.
The parameters in question are color, clef, transposition, and playable note range. Chris suggested that they should belong to the instrument, but I disagree. A single instrument currently consists of a playback device, an output channel, a program, and a set of controllers. With all of this contained in an instrument, there is no simple way to offer pre-selected alternatives in a sufficiently generic way that a number of users under varying circumstances can make use of them. About all we could do there is offer some way to load external parameters into an existing instrument. Something in the studio, perhaps, in addition to programs and banks. That is considerably more complicated than this needs to be to get the job done, and the less time anybody ever has to spend using our bank editor, the better. Plus, and most importantly, it does nothing in of itself to solve the problem of how to make these affect objects that don't exist yet, except that the instrument has traditionally been inseparable from the track, and is a de facto track property at this writing. Pedro wants to move the channel out to the track, and move the instrument to the segment. I support this effort, but I wonder how to deal with the fact that controllers are intimately associated with a given channel. Controllers should follow the channel, but they are also associated with a given device. Maybe that is why instruments always have included a device and channel in the first place. Think about that Pedro. He wants to make it so that Device A #1 could be a trumpet bank/program irrespective of any channel, and it could be possible to assign this trumpet bank/program to more than one MIDI channel, or to assign more than one bank/program pair to the same MIDI channel. Thus it becomes possible and useful to have more than #1 through #16 for instruments, and it suggests the instrument, on the far side of this shift, would be the ideal place for my parameters. However, even if all of that takes place, the instrument is still not a suitable place to put these, because even when an instrument can belong to individual segments, it will not belong to segments that do not yet exist unless it belongs to the track. The only place to affect things that do not yet exist is at the track level. If these parameters are to affect newly drawn or recorded segments, then they have to exist at the track level. The only way an instrument (with or without a studio involvement) that includes these new parameters can do something useful, without involving the track, is to make this instrument behave retroactively when it is applied to something that already exists. I take a bass part and switch it to a trumpet instrument (whether at the current/continuing track level, or at the eventual segment level), and the new clef/transpose go into effect. That sounds well and good, but just how is Rosegarden supposed to transform a bass part into a trumpet part? It is too much to expect Rosegarden to be able to always do sensible things by default, and if manual work is going to be required, it is better to do nothing at all, and leave the user to work out what she wants to do to make this bass part suitable for a trumpet. I conclude that while there are potential benefits to having a concept of an instrument that includes a bank/program and segment defaults, there is no practical way to make such a thing work retroactively. If it can't work retroactively, it has to happen at the track level regardless. It could come into the track through the track's default instrument, but it would still be impossible to create a new Eb clarinet segment on a track that defaults to a Bb clarinet. You'd have to change the Eb clarinet segment by hand, or change the track default so the next segment you create will be pre-selected for Eb clarinet. Therefore, I see no benefit to putting these any place but the track, as I started to do two days ago. I was right. The parameters won't, can't, and shouldn't affect anything that already exists (this is the road to madness), so I can easily switch my track from one to the other to the other in order to create a series of segments of a particular type without having to go back and diddle them all by hand. If segments can contain instruments, I can change the track level instrument default too, just as easily, and then go create a new series of muted trumpet segments (complete with their own instrument derived program changes) in the middle of a track that was previously creating new segments as a straight trumpet. So now that it's decided once and for all that the have to belong to the track, it remains to decide just how to do this. In the scenario I just outlined, if I want to pre-select for Bb clarinet, then Eb clarinet, then Bb clarinet again, I'm going to have to diddle all the track parameters by hand. The parameter templates do need to exist at some level that's external to all of this completely. The mechanism should be user extensible, so that does suggest some studio-like template library where you open a file dialog and load Bb-clarinet.rgt into this track. Along with a template editor. Damn. I can't believe I just came back around to that conclusion I've been trying to talk myself out of all along. Round and round she goes. I sat down to write the final solution to strengthen the strain, and I found another brick in the wall instead. I'm going to go get some fresh air, and fire this off for discussion. I'm 100% positive about these needing to exist at the track, rather than instrument level now, however. They *must* only affect things that do not yet exist. At least I have settled that much in my head, at last. -- D. Michael 'Silvan' McIntyre ---- Silvan <[EMAIL PROTECTED]> Linux fanatic, and certified Geek; registered Linux user #243621 Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/ ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
