OK, I see what I was failing to understand about this before. Having a working GUI to look at certainly helps, quite apart from anything else. Maybe it's a good thing I haven't actually been following the discussion!
This looks like good stuff, anyway. I still want to get my head around what exactly is being controlled here, so here we go. These parameters are purely a set of default values for some other parameters of a segment. Right? Earlier you wrote, > However [...] 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. If we have per-segment instruments, we'll still need a per-track instrument (to be the default for new segments on that track). So that part doesn't make much difference. And if we have a per-track instrument, then that instrument does affect all segments that haven't yet been created on that track. However, both instrument parameters and track parameters (apart from the new ones you're adding -- by "track parameters" I'm referring to the first couple of things Pedro stuck in the track parameter box) both affect segments that have already been created as well. What you're doing is really a different category of thing than either -- it's a set of defaults for a set of segment parameters. Given that this differs from both existing track and instrument parameters, it doesn't make much difference (functionally) whether the set of defaults is associated with the track or the instrument: in either case the behaviour (acting only to prototype new segments created on that track or using that instrument) is the same, and is different from the behaviour of the previously existing track or instrument parameters (which control properties of the existing segments on that track or instrument as well as of new ones). The choice of whether to associate this stuff with track or instrument, therefore, should probably be down to where the user would expect to find them, rather than any particular functional meaning. Either way, these "defaults for segment parameters" will presumably need some associated actual segment parameters. For example, if you can set the default colour for a segment, you also have to have a colour parameter in each segment so that you have something to set, and in case you want to change it later. Similarly, the highest and lowest pitch are presumably going to end up being stored in the segment. What happens if you set the playable range on a new segment, and then decide to change it later? Or if you simply want to be able to _see_ what playable range is in effect on a particular segment? Or you want to copy the segment to another instrument (using "instrument" in the sense of "oboe or French horn or whatever" rather than Rosegarden MIDI instrument) that has a different range? If the parameters in this box are just defaults for some segment parameters, then they'll also have to be present in the segment parameter box so that you can review and change them. I realise that you also said something about how making it possible for these things to change for already existing segments would lead to madness, but I guess I don't quite see how it works to make it impossible for them to change, either. Of course if they can be changed after the fact, then maybe they should behave more like traditional instrument parameters after all. I realise your heart is probably sinking or your ire rising as I'm going over some circular route that you've already argued back and forth repeatedly, but please indulge this train of thought if you can... Chris ------------------------------------------------------------------------- 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 Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
