On Sunday 05 February 2006 7:26 am, Chris Cannam wrote: > > Resize from left works correctly now. > > Looks good, with one caveat -- during the drag, long notes disappear the > moment you overrun their left edge, whereas in the end result the notes > just get shortened unless you've dragged all the way past their right > edge.
Agreed. This is a bit misleading. The clipped notes reappear in the preview as soon as you "let go" though, and this is still an improvement, since the previews never used to appear during resizes from the left anyway. Resizing repeating segments seems to be considerably improved too. 1.0 would often just sit there with a big gap between the end of the newly-resized segment and the first repeat rectangle, and the repeats would not change to reflect the new reality. (I can't check what's actually happening in playback from here, as I'm running 1.0 on a mute box.) I can't seem to get the wrong thing to happen now. It's very consistent about making an instant adjustment to any change, and this adjustment is reflected in the sequencer immediately. One thing I notice that doesn't seem consistent is that resizing from the right always preserves the events in perpetuity, but resizing from the left, if I make a segment smaller from the left, the events clipped off seem to disappear permanently. This was true in 1.0 as well, apparently. Maybe I always knew that, and I now seem daft for pointing out the obvious. > > Haven't fixed the audio bit. > > I'll have a look if I find a moment (though don't let that stop you). > > Still can't reproduce this. > > More tests reveal it has to do with tied notes. The bits left behind > are the second-and-subsequent notes in any tied sequence. Yup. That's really freaky looking too, because just the tied notes wind up out there in space. With odd gaps in them too, apparently. A half tied to a quarter, the bit hanging out there in space appears to be two quarters separated by a quarter gap. Not sure what the current known state of audio is, but my findings anyway. Resizing from right, if I shorten the segment, the preview hangs out there past the end of the segment until I let it go. Going longer, the new fake flat line preview doesn't appear until I let go, which I think is probably perfectly acceptable. Resizing from the left side is a different matter. If I shorten from the left, all seems to be well as far as the previews, but there's a HUGE caveat. If I resize the segment *larger* from the left, the preview follows the left edge, and when I let go, the segment keeps its original length, with the start now in a different place (and the end in a different place too.) Resizing larger from the left is in effect a perverse move command. (Can't listen to the results as JACK is off at the moment. Wouldn't be surprised if it continues to sound in the old location, but that is untested speculation.) I think for dealing with this last thing, if it's a big problem to straighten out, it might be OK to restrict resizing audio from the left to a shrink only move. For that matter, it might be reasonable to restrict resizing from either end to shrink only. Expanding the length of audio segments is something I can't think of many really good uses for. Can anyone else? Shrinking, OTOH, and from either end, is definitely useful. I'd say we could live with everything here except for the terrible resizing-right-is-a-move problem, at least as far as an RC anyway. Nothing except that last bit is worse than 1.0, and most of it is nicely better, if still a little quirky. -- D. Michael 'Silvan' McIntyre ---- Silvan <[EMAIL PROTECTED]> Linux fanatic, and certified Geek; registered Linux user #243621 Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/ ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
