On Wednesday 01 August 2007 14:59, M. Donalies wrote: > On Tuesday 31 July 2007 18:55, Chris Cannam wrote: > > [...] 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?
Possibly, yeah. Perhaps it's better to resolve the question of how voices should be supported first, then. Looks like we're getting back into the "big plan" stuff with a vengeance. It may be that some of these questions become academic, of course. For example, the STEM_UP dilemma would become less important when Rosegarden automatically did the right thing for stems in regions that had two voices on the same staff (top voice up, bottom voice down). > 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. When I say Track, I'm thinking strictly of what you get on the Rosegarden main window, and that is defined by the "MIDI-sequencer- ness" of Rosegarden -- it's a set of segments that all play to the same MIDI device/channel target, with broadly the same properties (program, initial controllers etc). If we take the premise that separate voices on the same staff may want to use different MIDI programs or play through different devices, it follows that separate voices have to occupy separate tracks, or else editing them in a "MIDI sequencer" is going to be appallingly hard work (and I really don't think it would be a good idea to start messing about with the MIDI sequencer interface to make it work). But is that premise valid, or would it be reasonable to always insist that separate voices in the same staff play with identical MIDI channel and program? > You seem to want each voice on a separate track > in order to mix and match voices in various combinations in a > notation view. Right. Of course "my way" would introduce complications of its own, e.g. the one with stem direction changing between different views of the same segment. Still, I do think it's almost the case that voice support only really makes sense if it is also possible to do things like printing out individual voices on their own, or printing out a part score with one voice at the top in its own staff and all the rest in a smaller staff underneath. So: > Question 1: How useful is it to have voices as independent units to > mix and match? I think it's useful (examples above), but would appreciate input from other people who want to use voice support. > 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)? Besides the answers to question 1: Ability to play different voices (on the same staff) with different instrument sounds. Ability to record voices separately from multiple MIDI takes without confusing the hell out of yourself in overlapping segments or having to merge segments after recording. > 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. Staff. 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
