#417 Make Rosegarden auto-extend composition length

Staff Picks
closed
Ted Felix
None
1
2013-11-14
2010-06-28
Audiodef
No

The default composition length is 100 bars. It would be nice to have Rosegarden automatically extend the composition length when reaching the end of the current length. For example, when I copied and pasted a segment, the pasted segment was simply truncated at 100 bars until I set a new composition length. If Rosegarden instead would simply extend the composition length to accommodate new pasted segments and extend the composition length when recording new segments, this would make composing slightly less cumbersome.

Related

Bugs: #1407

Discussion

    • Group: --> Maybe
     
  • Indeed.

     
  • Ted Felix
    Ted Felix
    2013-10-30

    • assigned_to: Ted Felix
    • Group: Maybe --> Staff Picks
     
  • I seem to remember discussing this, but I don't see a note on here.

    Having the composition extend itself when you're drawing segments with the pencil or moving segments around makes it hard to maintain a fixed composition length. The slightest wiggle can accidentally extend it, over and over again. (Or could, back when this was possible.)

    It seems to me the thing to do is add something to the set composition length dialog where you can set the length to fixed, and make it become a hard limit. All these automatic resize triggers would then respect the hard limit, if it's imposed.

    Any thoughts on that, Ted? I can probably grab a minute to set that limit up right quick, and then you can test Composition::shouldExpand() or something in your various decision making.

    Not today in any event.

     
  • Ted Felix
    Ted Felix
    2013-10-30

    Yes. That's over on bug #1407. That's exactly where I'm headed. I've already added an auto-expand flag to Composition, and I'm looking at RoseXmlHandler right now to add read/write for the flag (and appropriate versioning, and anything else...). Once that's in place, the flag will be added to ChangeCompositionLengthCommand. Finally, the UI will be updated to provide access to all this hidden goodness. This will be a very educational tour through the code for me as I've not had an opportunity to add a field to anything yet.

     
  • Don't update the XML version. I can't remember the last time the file format version was updated, but it was an extremely long time ago. We seem to have settled for allowing new things to be lost when you load with an old version of Rosegarden and then save again. It could be worth debating that, but I figure we've done this so many other times there's little point in questioning it now.

     
  • Ted Felix
    Ted Felix
    2013-10-31

    I was just going to update the point version. That appears to be the right thing to do as it won't cause any sort of dialog to pop up, but it will document the fact that there has been a change. Losing this "auto-expand" setting is not worth a pop-up of any kind. The user will know. And they can turn it back on.

    I checked through the logs a little and it looks like sometimes the point version has been changed for no reason, and sometimes it hasn't been changed at all.

    The code seems to indicate that a minor version change results in a gentle warning dialog (some data might be lost) when loading with an older version, while a major version number change results in a severe warning to the user (under penalty of death and severe data loss and all that). So, that's really all that happens with this, and that's pretty typical. When used properly it is helpful to keep users from doing something stupid, like losing a lot of work.

    Proper handling of missing fields is assumed. Losing when loading is also assumed. It's all good. This is all pretty typical file format versioning stuff. We really should be using it as intended. To help the users.

     
  • Responding to a direct an unambiguous statement with a lecture is bad politics.

     
  • Ted Felix
    Ted Felix
    2013-10-31

    I know, and I apologize. Pontification and blatant disregard for politics are two of my biggest weaknesses. They seem to get worse with age.

    Further digging in the code has revealed that a major version change causes older versions of rg to refuse to open a file at all. So, that's to be used only in very extreme cases where data loss is guaranteed. I beefed up the comments in RosegardenDocument to include this tidbit.

    I've got ChangeCompositionLengthCommand modified to handle the new auto-expand field. Just need to regression test before committing, then it's on to the UI.

     
  • The biggest change we ever had was removing the handful of hard coded General MIDI controllers and replacing them with new, arbitrary, user-definable controllers. I still have files that old. They warn of "obsolete element types that may not work in the future" or something to that effect.

    In spite of the warning, those files still work in 2013.

     
  • Ted Felix
    Ted Felix
    2013-10-31

    That's interesting and somewhat confusing to me. This means there must be some code someplace to deal with loading older files and warning of potential issues. I suspect that might be some specific checks in RoseXmlHandler.

    The versioning code that I'm looking at is specifically related to loading newer files with older Rosegardens. And in particular, I'm reacting to r12468. r12468 appears to make a big change to the file format (linked segments), yet the major version number was not bumped. I might be reading this wrong, but that's a pretty big mistake. If a user creates a bunch of linked segments, then accidentally opens and resaves with an older version of rg, all their linked segments are gone. And there's no warning. With a major version number bump, the older Rosegarden will refuse to open the newer file for fear of damaging it.

    Again, I didn't dig very deeply into r12468, so maybe I missed something. Someone familiar with linked segments should be able to test this hypothesis easily.

    I agree 110% that every effort should be made to read old files successfully. So-called "backward-compatibility". The versioning stuff in RosegardenDocument is primarily concerned with the oftentimes impossible task of forward-compatibility (at least, that appears to be its intent). Although it could certainly be used to detect potential backward-compatibility issues, I'm hoping that's rare.

    Isn't there a page on the wiki about file format versioning? Maybe it was a discussion on the mailing list that I'm remembering from long ago. Maybe we should gather some guidelines together for future reference. E.g. two key rules:

    1. Make every effort to ensure backward-compatibility.
    2. Use the file format versions in RosegardenDocument to prevent data loss.

    etc...

    This is tricky and important stuff. It deserves some documentation.

     
  • The big controller change I was talking about bumped the MINOR version number. The linked segments thing is no more significant than that, and probably should have bumped the minor version also. I forget who did that, but he wasn't one of the major contributors, and that detail just got missed.

    Nothing in our entire history has ever been significant enough to bump the MAJOR version number, and it's highly unlikely that anything ever will.

    By your own admission, you don't even use Rosegarden. You're looking at this from a grand theoretical perspective of how things should be and what ought to work.

    I don't care about problems that are only problems on paper. I care about problems that generate support requests. I believe in taking a look into problems once they have generated support requests. If there are no support requests, it's not really a problem, except on paper. Maybe nobody is even using the feature in the field, and nobody cares. If nobody cares, why even bother?

    In the case of linked segments, what I'd expect to happen is some user goes "Holy crap, a lot of my segments are missing! I'd better not save this file, so it doesn't get messed up!" Then they'll come ask me, and I'll explain what happened, and everybody will carry on.

    I don't look at the failure to update the minor revision number for that as a major tragedy that we must rush to correct, I look at it as a sign that not updating that never actually affected anyone, so who really cares? By extension, what's the point of even worrying about whether to change this or not? If in doubt, just leave it alone.

    That's why I made the call I did. I was in doubt as to whether it was worth it or not, so I decided to leave it alone. If it was the wrong call, then that's my problem.

     
  • Ted Felix
    Ted Felix
    2013-11-07

    Implementation completed in r13542.

     
  • Ted Felix
    Ted Felix
    2013-11-14

    • status: open --> closed