On Friday 07 October 2005 03:29 pm, Chris Cannam wrote: > Well, with regard to repeats in your first option, we _could_ quite > easily make repeat marks that displayed and could be edited in the > Rosegarden notation editor, and exported to Lilypond, but were not > actually played in Rosegarden. > > 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.
Thinking about that last point, I think the bottom line is that what we'd have to do in order to enable various actions is well within the means of our overall infrastructure, but the results would look bizarre and nonsensical on the segment canvas. Perhaps the solution is to do just that. I think a lot of notation users--William comes right to mind here--would dearly love a dedicated notation editor environment that can manipulate the segment canvas and all the other nasty main window bits without the user having to touch any of that stuff. 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. That idea has some real appeal, I think, but the big question is what to do when someone wants to exercise fine control. That's the whole point of a sequencer after all, and it's why MIDI put out by dedicated notation pacakges usually sounds like crap. If you don't like these particular interpretations, then go tweak the velocities by hand and what have you. 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. Maybe, then, the compromise could be a new kind of track. On the one hand, a conventional track with conventional segments that can be edited in the conventional notation editor, with certain limitations. On the other, a dedicated notation track that behaves differently, and can't be edited in a sequencer-like fashion, but it can be edited with the advanced notation editor. If you wanted to convert from notation to sequencer, it could make hard copies of all the various combinations of virtual segments onto a manufactured segment that could not scale out as notation, but would make sense from a sequencer perspective. This conversion would have to be a one-way process; probably something done as the final step before making a recording of the MIDI performance. If you had tweaked this generated track and then wanted to go back and edit the notation side of it, all changes would be lost, and you'd have to re-tweak the result of a subsequent export. I don't know, this was just a spur of the moment idea, and I expect you'll find dozens of things I haven't considered yet. One big thing not considered in the above muse is what to do with tempo, which people would like to be able to manipulate from this advanced notation editor, but which affects all things on all levels globally. Tempo is an ugly problem on many different levels. Another passing thought is that the above scenario is starting to sound like a new, independant, free-standing advanced notation editor to me. Putting it out into its own separate application might smooth over some of the rough edges to having two completely different ways of manipulating the same underlying structure. The sequencer-editor would be for people more concerned with the best MIDI performance (and audio and other stuff) while the separate, advanced notation editor would produce files readable by the sequencer, but not editable in a backward-compatible way. Or maybe one binary that can start in one of two modes with a switch. OK, that last thought is pretty far out there, I admit. > > Silvan's Short List of Why the Notation Editor Still Isn't Terribly > > Useful to Me: > > Good summary. Thank you. > I think it's about time we made an experimental branch for messing about > with notation stuff. One of the problems we've had is that it's too 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? I'd like to see a dramatically improved notation facility for 2.0, with a 2007 deadline for releasing it. > easy to break things, and in a way that can take a lot of time and work > to recover. I quite like the idea of being able to mess about and try > out no-more-than half-worked-out thoughts again. It would be especially useful to be able to commit such thoughts and then roll them back. One problem I've had in my own experimental work is that I never have actually done a branch before, even when it would have been a very useful thing. I'll code it this way, change my mind, redo it, and then have to go back to the first idea by hand, instead of just checking out a previous version. I really should take better advantage of what CVS can do. -- Michael McIntyre ---- Silvan <[EMAIL PROTECTED]> Linux fanatic, and certified Geek; registered Linux user #243621 http://www.geocities.com/Paris/Rue/5407/ http://rosegarden.sourceforge.net/tutorial/ ------------------------------------------------------- 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
