On 11/23/2012 12:32 PM, Tom Breton (Tehom) wrote: > What do you think? Obviously I wouldn't do this on trunk because it's > experimental.
I finally got time to sit and read. I'm still not 100% sure I'm following you with all the bits about ornaments and trigger notes and so on. Sort of. The GIMP analogy... What I'm kind of getting my head around is a world where every segment is like an individual XCF file that can have layers. Lay down a base layer, that's the background. Put variations for a couple of notes into individual layers, and what's on top covers up what's below. Every segment could become something like, oh, maybe a Leatherman tool. They all, every copy of the same master, have the same widgets inside, but you can vary their individual behavior by reconfiguring which widgets are poking out, and which ones are folded. That sounds very plausible. One specific thing I wonder about is the whole business with polyphony. It could be possible to have the foreground layers transparent with respect to the background, so you wind up with those variations playing along with and on top of the base layer. That could obviate the need to work with overlapping segments in the conventional fashion to achieve this kind of notation. I think on the whole it would probably be more practical to implement the segment layers thing in such a way that foreground layers always fully cover whatever is under them, and leave polyphony to the existing mechanisms. It would be both simpler to implement that way, and it would avoid any big paradigm shift. On the other hand, a fully flexible new paradigm would probably be a much cleaner way to go in the long run. Full control of "opacity" in the layers. Either this one fully covers what's blow it or it just sits on top and beside what's below it, at the user's control. That would do away with all the overlapping stuff that you find displeasing, but I think it would be impressively hard to design a way to edit and control all of this that makes intuitive sense to use. We'd be talking about seriously having to invent some new wheels in terms of implementing the editor interface, to say nothing of the backend guts. Anyway, no matter how it goes, it seems like the whole thing could easily take place in such a way that it has no appreciable impact on anybody who doesn't want to use the new stuff, and just wants to go on using Rosegarden like they always have. It definitely sounds like something worth tinkering around in a branch with, and it can very likely come to something worthy of becoming mainstream. Very interesting vision, Tom. Assuming I'm even getting somewhere close to understanding what you were talking about. -- D. Michael McIntyre ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
