On Tuesday 31 July 2007 13:38, M. Donalies wrote: > First, automatically calculated notation properties must be local to > a particular type of staff (more specific than just TabStaff, since > we need the number of lines and tuning to determine HEIGHT_ON_STAFF.) > > There also need to be properties that the user can set (e.g. > STEM_UP) for a particular staff type. If present, these override the > corresponding local properties. These properties outlast a particular > view, so they are "global", but there needs to be a way to tag them > as applying only to a particular staff type. Use a prefix to indicate > staff type?
Yes, it sounds like we want a prefix (or other namespacing mechanism) encapsulating the type and "settings" that make up the staff. I don't think that quite describes it yet, though. Consider STEM_UP again for example; a user setting it for a note on a single normal staff might or might not expect the setting to persist when the note is next viewed on a grand staff. If voices are supported, then a note may appear in one staff with other voices and in another staff of exactly the same type without any other voices, and the proper STEM_UP value would be different in either case. Is there any way to deal with that? Also, although these properties are specific to the staff type in the sense that the user might want to set different values in different staff types, in normal use they're probably more likely to want to have a new staff type take its default values from those they set in any previous staff type. > Second, is Segment selection/viewing when the Segments overlap. It > seems what's desired is Heikki Junes suggestion that we have Track x, > Segment y, where x and y are numbers. Mmm, as you may have noticed I don't really agree that segment numbering is a good idea in that situation. You may want a numbering for the voices within a staff, but that isn't the same thing (they should be on different tracks anyway, if we supported voicing properly -- having to overlap segments on a single track is a grotesque hack that we should do away with as soon as we can). > For dealing with multiple staff types in the tablature > implementation, I've put a StaffType member in Track. I can't think > of a reason not to. Here are some: * It would be very reasonable to want to show the same segment in more than one sort of staff, maybe even at the same time. Copying it to another track would be a pretty lousy way to achieve that. * It would be very desirable for segments that share a staff not to have to always share a track (see above). If you have segments across multiple tracks on the same staff, it doesn't make sense to associate the staff type with the track. I strongly believe that the right container for staff-type information isn't the track or the segment, but something else that we don't yet have in Rosegarden which describes a relationship between tracks (or segment, but probably tracks) and staffs, which is the thing I was referring to as the "score" in the "Score layout" page on the wiki. Trying to shoehorn staff properties into either the segment or the track looks to me as if it will lead to some immediate fatal problems (I think both of the above two listed problems are fatal). I would strongly encourage defining this score mapping container (which doesn't have to be very complicated) first. If you don't get what I mean by this, or don't see the need, I'm happy to go on about it a bit more. Chris ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
