On 09/27/2013 01:11 PM, Tom Breton (Tehom) wrote: > When you add another tripletted note to that crotchet-quaver triplet, RG > believes that the new note is the third note in the triplet. Gives it the > same group id, so display groups it all as one triplet.
Enter as 8-4 in a triplet, and all behaves well. Enter as 4-8 in a triplet, and you always get the spanner encompassing a spurious dotted rest, and if you enter a note where that rest is, it becomes part of the "triplet" of a totally incorrect duration. I tested entering with the I-II-III keyboard shortcuts to ensure that "hold your mouth right when you click" wasn't a factor. The insertion point should be moving with mathematical precision, and the numbers are skewed in this case. If you avoid that rest, you can enter anything to the side of this figure, but you can't delete compress or quantize that rest away. Noticing this entry pattern might lead to a clue. What happens when you place the triplet 4 and then the triplet 8 that doesn't happen going the other way? > In a similar vein, it's possible for tuplets to just start at a bad place. > Make a tuplet, cut it, put an eighth-note rest at the start of the bar, > and paste the tuplet after it. Where should the tupleted group start, > displaywise? There I don't think we have much choice but to display a > bizarrely-timed tupleted group. Some of the evil examples are just the > user's own fault and if they look bizarre in the display, so be it. Moving segments, cutting out a range, pasting a range... All kinds of ways to shift things by a fraction of a something and send the whole thing cascading all to hell. This is one of the huge thorny things about notation-on-sequencer, but there is no easy to answer to a lot of this but the undo and quantize functions. > All that leads us in the direction of complete ~laissez faire~, but ISTM > that's not ideal. Reasonable tupleted groups ought to start neatly on > beats no matter how they came to exist. Tuplets ought to be enterable > normally regardless what else is in the Segment. Ought to be, within the limitation that users will still be expected to tread carefully. A notation-driven application would have more options for subtly shifting everything by 1/3 beat somewhere, but our start times are anchored to absolute MIDI time. If you overrun your gap, or don't fill your gap, you get into the same consequences as moving a segment or myriad other subtle things that can knock everything out of whack. > So ISTM we should do more work to figure out healthy tuplets and less > micro-management of them in the various other code. I've sketched some > code but I'm not satisfied with it yet. I've gotten busy at work again, so any hope I had of getting involved with that particular code is diminishing rapidly. I still plan to twiddle a few things, and I have a mind to push the release back to December and make it an interesting one this time. -- D. Michael McIntyre ------------------------------------------------------------------------------ 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
