On Friday 07 Oct 2005 23:26, Silvan wrote: > On Friday 07 October 2005 03:29 pm, Chris Cannam wrote: > > Or, we could make repeat marks that displayed and could be edited > > in Rosegarden's notation editor _and_ might even play, but weren't > > easily (meaningfully) displayed or edited in the sequencer bit.
Actually, I think that bit about "might even play" was probably wrongheaded. Displaying _something_ in the segment canvas, even if it can't be edited, is surely easier than playing it. In the case of something like alternate endings or DS al Coda, playback depends on what you've already played (i.e. you can't know which ending to take without knowing whether you're on the first or second time through) and that's a whole class of problem that we don't currently think about in the sequencer (and frankly would prefer not to if it can be avoided). I guess that's why we always expect the basic repeats to be expanded literally on the segment canvas if they are to be played -- which is impractical for long repeated sections and probably even more confusing for DS/DC. Doing both of these things "properly" is probably no simpler than doing a more general time-flow ruler type of concept in the sequencer in the first place. The sequencer itself still wouldn't have to support arbitrary programmed jumps, the GUI could still expand out the folding of time when it "programs up" the sequencer at the start of playback. That may actually have some mileage. > People could create segments, create > tracks, assign instruments to tracks and all that whatlike from the > comfort of a white page, without having to be bothered with the > details. In all of those cases, though, the work done could be immediately reflected in the segment canvas, couldn't it? That is, a nice GUI for doing all this stuff in the notation editor would be a tasty addition to what we already have -- it wouldn't necessarily have to supplant any of it. Actually it'd be great to see some mechanism for adding segments, assigning instruments and so on based on a score-type understanding of what they mean (e.g. add N bars of segments to all these instruments at once, in a very trivial case). We have a particular problem there with instrument management (the classic case where someone wants to be able to say "just play this on the damn piano" rather than having to choose a "MIDI Instrument" and then find a piano program -- something we can't do automatically because we just don't know what programs are available). > [...] But in this scenario I've just > envisioned, with all sorts of hidden virtual segments that don't > appear on the canvas in a useful way, it would be well nigh > impossible to tweak these events as events. Are there any other situations besides repeats where you would actually end up with "virtual" segments, in this model? > I agree. I was planning to do just that for the re-beaming stuff I'm > in the earliest stages of playing with. Why not create a > notation-hacking branch to work on all this stuff so we don't get > tempted to delay our impending release by another six months? OK -- consider the new "experiments" branch to be that (and anything else it might be needed for). Chris ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
