On Wednesday 01 August 2007, Chris Cannam wrote: > 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?
OK, I see where you're coming from on one voice one track. If I want to do a what do they call it SATB? score using Super Sampler Human Voice Pack 3000 XL, and I want the soprano part to play with a soprano, the tenor with a tenor, etc., then I could see where this might be a necessary way to get there. Also, if I wanted to do a fake MIDI rendering of the piece with the voices panned out, soprano far left, bass far right. Honestly, I think all of those concerns are probably an edge case. If I have a multi-voice part I really want to split out like that for playback purposes, then I can split it out into tracks that work independently of notation. That's clunky, but I don't think it will happen very often in the real world, because people who use the voices in this fashion are the least likely to be people who really value the MIDI performance as an end to itself. They'll be writing for real musicians to play off of paper scores. Why else would they care what the notation looks like? Besides, we already have established precedent cases that require the existence of one set of tracks/segments for notation, and one for playback. I forget when that's necessary. Probably for DS al Coda or something, as exemplified in one of the LilyPond directives demo files. So, considering all of the above, I'm still in favor of voices as a property of segments. (Not events.) I could see continuing to use plain ol' stock segments in some new way that manages chaining them together, or expanding Segment to be able to include multiple layers within itself. Whatever seems most prudent/easiest/most likely to actually happen. > 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. Why? Who does that? When I think of parts with multiple voices, I think of: * actual human voice music * music for polyphonic instruments that has different lines weaving around each other on the same staff (piano, guitar, organ, or even duets or trios that are printed on the same staff) * music for French horns (written with I and III on one staff, II and IV on the other) The only case where one might want to split things out might be when duets, trios, etc. are written on one staff, but if I were composing a duet I intended to be read on one staff, I don't think I would ever want to split that part into its constituent halves. If that's the only think you're worried about for splittable multi-voice parts, then we should go do some homework and see what Sibelius/Finale/etc. do. I would bet you can't split voices out into separate staffs with those high dollar big boys, but I could be wrong. > 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. Interesting point, this. I think real keyboard players would scorn the idea of having to record voices in separate takes at all. We've had lots of complaints about how we totally crap our pants in this situation, and just render some bunch of garbage with split and tied chords. We have a hack for trying to separate the right hand from the left after the fact, but absolutely no way to cope with voices. This is very lame, but I'm not proposing we actually do anything about this particular issue for my own sake. I have no vested interest in this wrinkle, since I can't play multiple simultaneous voices on a keyboard anyway. Not unless I do it by accident, which is the case extremely often. -- D. Michael McIntyre ------------------------------------------------------------------------- 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
