On Tuesday 31 July 2007, Chris Cannam wrote: > 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).
Having to do voices by manually combining different segments on different tracks (ie. merge staffs with same name or whatever at LilyPond export time) is a grotesque hack. I think it would be vastly preferable to have a system that managed overlapping segments in such a fashion that the user never had to worry that there was a v1, v2, v3, v4 version of what looked, felt, and moved like just one segment. They shouldn't ever have to muck about with more than one segment, and they should never have to manage multiple tracks, or merge options, and all that ugly nonsense we have in place because it's something that works today, not because it isn't a steaming pile of crap. No, I think it would be far preferable to have some kind of setup where you want to create notes in voice 2 of this segment, so we create an invisible overlapping segment to which you are completely oblivious as the user. I'm not sure what that would look like object-wise. Expanding Segment so it can contain layers, or else some invisible manipulation behind the scenes to chain segments of the existing and current type together. Along the subject of multiple voices, one seriously sucky thing about the current hacky state of affairs is the way you have to put all the chords in one voice in order for them to come out as chords. What about two voices that move in different directions, but occasionally come together on a chord? Those parts are bitchy and confusing to enter as it stands now, and I find this situation comes up again and again. Anyway, I'm looking at this from userland again. I have no idea what the internals look like, or what a hideously complex thing I think would be best, but I do strongly opine that continuing to have to twiddle multiple voices across multiple tracks is the road to crap. I also agree that manipulating overlapping segments is totally evil as it exists today. > 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. Sounds like the right direction, but not quite sure what you're on about. -- 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
