On Fri, Sep 27, 2013, at 02:50 AM, Tom Breton (Tehom) wrote: > of one event works. It's the rest of the code that believes that > N-tuplets mean N events (or N events with distinct starting times)
There shouldn't be any code that wants N events for an N-tuplet -- things like crotchet-quaver triplets would have been a normal use case from the start. (Though who knows what cruft has grown over the years.) Might be worth going over some of the early docs for this stuff, which can still be found in Subversion at e.g. https://svn.code.sf.net/p/rosegarden/code/branches/obsolete/docs/data_struct/tuplets.txt (there are various other interesting antiquities in that directory... they're mentioned on the wiki but with broken links to SVN). As usual, much of this springs from trying to make a sequencer-with-notation rather than a score editor. Some salient points: * The initial idea was that you should be able to play the notes and get the right results even if you didn't know about tuplets, so the base timings stored were for the performed rather than notated tuplets * It was a deliberate compromise to have tuplets as a kind of beamed group, even though they aren't always beamed. At the time it seemed worthwhile to get only one overarching type of structure even though it wouldn't allow some more sophisticated arrangements * and of course there are no group "objects", only group properties on events in a structure organised by time only. The group objects are invented on the fly from the properties by the notation engine when it renders something. A problem of course with this, particularly the final point, is that there's no way to mark the start and end of a group in a way that remains consistent "by itself" when events inside the group are added or edited. Also, the whole mechanism for beamed groups suffered from being adapted to try to pick up multiple simultaneous groups (with different group ids) in different "voices" in the same segment -- this was before we resolved the display of multiple segments on a staff. The code could have been much cleaner without this confusion. So although the basic design in terms of properties isn't great, it can be made to work better than it does and I doubt if it's worth trying to change it now. But the code that does all the crazy stuff is crazy. Chris ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk _______________________________________________ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
