On Tuesday 31 July 2007 18:55, Chris Cannam wrote: > 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?
Yuck. There's a lot of complexity here. I can see this becoming a page-long list of ifs whenever we want to use a notation property. I'm thinking of all the command classes that access some property. I wonder if there's some better way to organize this. Giving NotationProperties some static "do the right thing" methods for commonly used situations? > 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. I think I see now. We have a nomenclature difference. Conceptually, what is a Track? I've been thinking of Track as a container of segments that all behave the same way (same instrument, same staff type, etc.) for viewing. Voices are "inside" Track. Your view seems to be the other way around. Track as a sort of synonym for voice, with our undefined container wrapping various tracks. Michael's take on voices seems to almost be as a property of a Segment (or Event). You seem to want each voice on a separate track in order to mix and match voices in various combinations in a notation view. Question 1: How useful is it to have voices as independent units to mix and match? I don't really see voices as independent units, but rather as a piece of a whole... (I want to say track or staff) ..Thingy. How Thingy is displayed depends upon what staff type it's given. If voice was a property of Event, then you could still display edit by voice. What you couldn't directly is say: Let's combine Track 5 (representing voice 5) with Track 8 (representing voice 8) and display. With a score layout mechanism, you could still achieve this by selecting some option on each track to say "only show me voice x on this track". Question 2, which is a more general restating of Question 1: What do we get out of 1 voice per Track (and implicitly 1 voice per Segment)? Question 3: If we have 1 voice per track, what do we call the Thingy that encapsulates a group of tracks for display as an atomic unit in a notation view. I like the idea of a voice property in Event. Dynamically allocated voice as a "property" of Segment is basically what we have now, which I don't like at all. A manually set voice property of Segment (Track x, Segment y) would be something I could work with. I see 1 voice per Track as a hassle both for user and programmer with little if any benefit. It doesn't impede anything that I'm aware of though. ------------------------------------------------------------------------- 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
