Break Every X Bars plugin behavior changed?

• Nov 13, 2014 - 17:28


I mostly use MuseScore for jazz lead sheets and transcriptions.

I noticed a change in the behavior of the "Break Every X Bars" plugin between 1.3 and 2.0 beta (I'm running Mac OS X 10.9.5 and OS X 10.10 on different machines and the behavior's the same, as expected).

In 1.3 it was possible to limit the scope of the plugin action by selecting a group of measures (so, for example, I start with the document at 4 bars/system, but I've got a set of 12 bars that's particularly crowded, so I could select that 12 bars and break every 3, leaving the rest of the document with breaks every 4 bars). This is very handy; for example, if you have a pickup beat that you don't want to count against the break structure.

Now, in 2.0 beta, it appears that the plugin ignores the selection and applies the break structure to the entire document, including the pickup beat(s) (when present).

Was this a conscious decision, and if so, what was the rationale? I, for one, would lobby for the plugin to act as it did for 1.3; it's much more useful that way.

Thanks for your thoughts.



In reply to by Jojo-Schmitz

I don't suppose it would break anyone's heart if I moved this into the main program? Meaning we wouldn't need a plugin for it any more. This seems like it would go well with the new Explode and Implode under Edit / Tools, as well as the slash notation functions that should also be appearing in that menu soon. Looking at the list of things that up until now have been done via plugins, and thinking also about the discussion I started a few months ago in, I think it's the biggest remaining thing that feels "core" enough to want to make native.

My plan is to add a new "Edit / Tools / Add/Remove Line Breaks..." dialog that would work just like the existing plugin, but would also add a "lock current layout" option to simply add line breaks to the current last measure of each system. Also maybe make the option to remove line breaks more obvious. Right now, you get that by specifying 0 as the number of measures. I'm thinking maybe three radio buttons, "Every X measures" (with a corresponding spin box), "Lock current layout", "Remove line breaks".

In reply to by Jojo-Schmitz

I thought of that too, but it occured to me its main use case (for me anyhow) is no longer applicable - parts are no longer separate files, and in any event are already handled by File / Export Parts. Not that the plugin can't be used for other purposes as well, but it starts to feel less "core" to me. That's not to say it won't make it at some point, but it doesn't feel as important to me right now as I prioritize.

In reply to by Jojo-Schmitz

Yes, I can see that being useful as well, but to me, that sort of feels like it "belongs" in a plugin, or perhaps even a separate utility / script / batch file that simply invokes MuseScore from the command line to do the conversion. Everything else in all the menus within MuseScore is assumed to work on the current score - with the exception of plugins the couple of file menu options that create or load scores. A function to go through the file system finding other scores to work on, completely ignoring whatever score you currently have loaded, feels a bit out of place here.

BTW, it now occurs to me the name of this plugin has been a misnomer all along. If we aren't talking about an operation on the current score, it's not really even an "export" we are doing - it's a "conversion". It really only made sense to call it "batch export" for the specific use case I had in mind in the first place - you have a score loaded, and now you want to export it and all of its parts to PDF. Even though the parts were literally separate files, it still seemed conceptually like they belonged to the current score so you were in a sense just doing a bigger export. Now that parts *are* contained in the main score and we have File / Export Parts for them, it probably makes sense to just rename this plugin Batch Convert, which makes it more clear this is something of a standalone converter as opposed to an operation on the current score.

In reply to by Marc Sabatella

Indeed Batch Convert would be a better name, I just kept the old name for backward compatibility
Doing it from the command line is indeed possible (I have a) a .bat file and b) a Makefile), and had been my workaround prior to that plugin, but has quite an overhead, you start a fresh MuseScore for every single conversion, and you can run into problems with spaces in filenames.
And you have additional dependencies (.bat is Windows only, Makefile Linux and Mac only, unless you have mingw or some such in Windows)

Do you still have an unanswered question? Please log in first to post your question.