Section Break
I'm wondering if this has already been addressed, but I'll take the chance it hasn't and post a new thread.
The 'new' Section Break' tool is a great addition to 2.0.x, but it has some limitations. For instance, it is not currently possible to change the bracketing of staves after a section break without affecting the entire score. This means, effectively, that if a multi-movement work contains different 'concertino' and 'ripieno' groups from one movement to the next, the only way to format the score correctly is to create separate files for each movement. This is not the end of the world, but it is a relatively major inconvenience.
I am wondering if it would be possible to tweak the section break code so that ALL the initial elements of a score could be modified just for the section which follows it, without affecting the entire score. It would be very convenient, for instance, to be able to move a single instrument from the concertino group to the ripieno group and vice-versa. Imagine a concerto grosso wherein the concertino group in Mvt I consists of the woodwinds plus the first violin, while in Mvt II the winds are tacet and the strings and harpsichord--formerly the ripieno group--plus the first violin, become the concertino for that movement.
All that's needed to indicate that is the ability to change the bracketing of the staves after the section break.
Can this be done?
Comments
Anything is possiblw of course, but the current implementation of section break is nowhere near so sophisticated. It would be much more than a "tweak", in other words.
In reply to Anything is possiblw of by Marc Sabatella
Heh-heh! Knowing how good you guys are, I see that I phrased that 'is this possible' question badly. I should have asked if it were something with enough potential use cases to make it worth the work involved. (I'll address that in my reply to Nicolas, below.)
When I used the word 'tweak', though, I at first imagined something along the lines of grabbing big hunks of the existing code/framework and using the section break to trigger a dialogue to define which routines to use:
Maintain score parameters for new section? Yes/No
{IF YES>[run existing section break routine as currently constituted]}
{IF NO>[run a 'section' version of the existing score set-up wizard, so it applies only from that point forward]}
IOW, I had thought all you'd have to do is modify the score set-up wizard to shorten it some (no need for parameters which can already be anchored to a specific measure, like clefs, time sigs, and key sigs) and create some sort of 'anchoring' mechanism to fix the modifications to a certain measure and forward. So if the user clicks 'NO', the 'section' set up wizard could start by opening the Title/subtitle/composer/poet/copyright page, then bring up the Instruments dialogue, each dialogue being presented with the previous choices on it, all ready to be modified. And obviously, start-of-score elements which are thereafter created 'on the fly' at the head of each system (such as brackets--my particular need at the moment, which prompted this discussion), would behave as start-of-section elements when dragged to the first measure of the new section, since that measure would be 'defined' as a new starting point. Seemed simple enough (especially to my simple mind!)....
But after writing that bit out and looking at it prior to posting (good thing I did, too!), I realised that that sort of logic path would only work for new input. To make it work if someone decided to insert a section break to an existing score would have to be much more complicated. And would I be correct in assuming that there might also be issues with pasting in music from another score or section (which, I presume innocently, probably carries with it a lot of score formatting info that might cause conflicts)?
Does any of that even make sense? (You are allowed to laugh at my naïveté....)
In reply to Heh-heh! Knowing how good you by Recorder485
Since you brought it up, I'll try to explain a little.
Right now, attributes like bracketing - and many more - are basically score-wide. Two staves are either bracketed together or they are not. It's a constant throughout the score, meaning the information is stored in a single place. In order to allow things like that to change over the course of the score, we need to implement and manage a "map" specifying how that attribute changes over time. We do this for things like tempo, clefs, key signatures, time signatures, and - for the purpose of the "Instrument change" element - the instrument to be used for playback (and starting with 3.0, transposition).
Those maps were all in place before section breaks were a thing (well, the isntrument change might have been more or less simultaneous). So section breaks don't actually require much special handling at all. We already allowed changes to clef, key and time signature; section breaks basically just suppress the display of the courtesy element that otherwise would have appeared at the end of the previous system. OK, a few other things to like resetting measure numbers, but again, that capability was already in place.
In order for a section to allow changes to the basic score structure - number of staves, or how they are bracketed, or anything else that is normally score-wide - we'd need to implement maps for those settings as well. And change everywhere in the code where we currently reference those things to always do so by referencing the current point in time. That's a lot more work. Again, not out of the question, but it's a much more significant rearchitecture.
In reply to Since you brought it up, I'll by Marc Sabatella
Thanks, Marc. As usual, your explanation is clear enough that even I can learn something from it. ;o)
I'm going to experiment with setting up a 'dummy' staff within the ripieno group and set it to disappear when empty, and see if that could be a work-around for my current need. I still hope you'll consider the request for the long-term, though. I really do think it would be useful to a lot of people besides me.
In reply to Since you brought it up, I'll by Marc Sabatella
Well, the experiment with a 'dummy' staff/instrument works (mostly), although it's a serious kludge. To get the results I need, I had to create a duplicate first violin staff, bracket it with the ripieno group, set it to be invisible when empty, and then put 'dummy' notes (not visible, not played) in at least one measure of each system where I want that staff to appear even if the instrument isn't playing at the moment.
I also had to do those last two operations on the 'real' first violin part, which is bracketed with the main concertino group, so that it would appear when it should (i.e.: movements I and III) and vanish when it wasn't wanted (Mvt. II). And (easiest part of this slight-of-hand operation) I had to anchor the staff text reading 'concertino' for the second movement to the 'dummy' first violin part, and (obviously) cut all the music for the second movement from the 'real' 1st violin and paste it into the 'dummy' first violin.
Here are the results:
Naturally, the system breaks will change as I reformat and edit things, so all those dummy notes, etc., will have to be checked manually after each edit to the score. AND, it looks like those 'dummy' notes will have to be entered in Voice II so the visible rests in Voice I will be correct, AND I'm stuck with not being able to change the instrument names, so I'll have to go back and designate the Violino del Concertino as Violin I, and the Violino Ripieno as Violin II, for the entire score. Grrrr....
As I said, it's a big, fat, ugly kludge. My head has not QUITE exploded, but I've just asked the butler to bring me another glass of Tyrconnel...and told him not to go off duty for a while yet.... ;o)
It would be SO much easier if one could just change the bracketing and instrument names after the section break. How many lines of code would you have to re-write to 'map' those attributes to a designated starting measure? (And more importantly, what are the chances of persuading you this is a worthwhile project? I would TRULY love to help, but it's been 40+ years since I wrote my last line of hexadecimal code for the 1970s version of a text converter we used to capture faxed WP output and turn it into something our typesetting computer could read. I don't think you really want my thumb-fingered, age-of-the-dinosaurs help in that department.... ;o)
In reply to Well, the experiment with a by Recorder485
Well, if we went that route, we'd want to do it for more than just the order of the staves or the bracketing. Next step would be to allow the different movements to have different numbers of staves, perhaps different instruments entirely. And maybe different style options, so you could for instance have different staff spacing for different movements, etc. And while we're at it, probably also allow different staves to have different style settings, so you could have dynamics above vlocal staves for instance. It's kind of opening a big can of worms, as these are all things that have been request at some point, so if we're going to rearchitect things, we might as well do so to solve all these problems, or we'd be rewriting the same code multiple times. But that makes the project pretty big.
The right way to do this is to create two separated scores, one for each movement.
In reply to The right way to do this is by [DELETED] 5
I know that that's the only functional way to do this at the moment, but I would disagree with your choice of the words 'right way' to describe that. 'Right way' is a descriptive that begs more questions than it answers. Right for whom? Under what circumstances? For what type of score? Etc., etc....
In fact, if separate score files for each movement or section of a piece is the 'right way' to do this, why did you create the new section break tool for 2.0?
I happen to think that, along with figured bass, the section break is one of the best additions you've come up with since 1.3. Before 2.0.1, I was indeed obliged to create separate files for each movement of a piece, and the sheer number of files thus created (after weeks or months of editing and revisions, proofreading, and subsequent re-re-re-revisions) made file management a much greater burden than I can easily describe without using rude words. (It reminds me, almost, of the 'good old days' when we stored the typography for entire books and magazines on stacks of 8" floppy discs, each file having a maximum size of 8000 keystrokes, because that's all the 'bubble' memory on the motherboard could hold before we had to save to floppy, clear the screen, and start over. ;o)
My particular use case for asking to upgrade the section break tool concerns multi-movement works, and I realise that there are limits to that use. For my work, which is primarily Baroque music, it is rare to have more than 8 or 10 staves and even rarer for the total running time of a piece to exceed 10 or 12 minutes. My HP Probook handles that size file with no problem. But for people who work with full symphonic scores and classical or romantic-length operas, symphonies, or even solo concerti, the sheer size of the file gets to be bigger than most computers today can deal with without lagging. So yes, there is a case for separate files for separate movements being 'the right way.' But it is a limited case.
I think it far more appropriate to use the section break for shorter works, such as Baroque sonatas and concerti, but also for instrumental 'method books' which include a great number of short pieces, or collections of short works such as carols or hymns, movie themes, show tunes, jazz standards, solo fantasies and suites, theme-and-variations pieces....
In reply to I know that that's the only by Recorder485
*Next step would be to allow the different movements to have different numbers of staves, perhaps different instruments entirely.*
In this case, there are different scores. A score in MuseScore is really a a number of instrument in a given order (with given brackets, and barlines). It's a core concept. If we break this, we need to rewrite a lot. Or we need to invent a new super score structure that can list scores one after each other (and in this case, good luck with linked parts). So maybe "right way" was not the appropriate term but the simplest way for everyone is to consider that a given number of instruments in a given order is a score. If the piece you want to score doesn't fit this description, then you need to split it into different scores.
In reply to *Next step would be to allow by [DELETED] 5
Well, yes and no. I certainly understand the structural parameters you're using to define 'score' within the perspective of the program, but it doesn't reflect the structure of musical scores in the real world. As you know, I do not work with contemporary music, but it's hard not to be aware of the fact that contemporary composers can and do demand many, many things that are 'not standard' according to traditional western musical notation. That repertoire has, effectively, no rules which cannot be 'broken' in the search for new and possibly interesting music forms, etc., so the potential for encountering a score with a different instrument list or bracketing from one section to the next is obviously there. And that's just one example. I gave a number of others in my earlier post, most of them much more likely to be encountered by anyone except a specialist in contemporary composition.
I think this comes down to two basic issues: File Management, and Page Makeup.
As Marc has mentioned (quite rightly) a few times, MuseScore is primarily a music graphics program. That said, users should expect to be able to manage the graphics of piece of music in a coherent, efficient manner. If, as was required with 1.3 (or with very large scores, such as a Wagnerian opera--a separate problem having more to do with computing capacity than program structure), separate files need to be created for each section, two bad things happen: First, one single musical work could wind up generating a hundred or more individual 'scores' (files) by the time it is ready to print (many different edits and revisions, plus all the attendant parts for each, plus backup files for each!), and second, page-makeup of the final print version of the score becomes akin to the task Hercules faced cleaning out the Augean stables.
It's not as bad as it used to be; in the 'good old days' I mentioned earlier, when typesetters were the size of a 12-foot Böesendorfer concert grand and data were stored on 8" floppies, galleys for a short novel might have to be broken into 256 or more discrete files, and doing the page makeup from those raw galley files could take TWO DAYS working two or three shifts. In the early days, programs did not exist to apply headers, footers, and page numbers automatically, break the galleys into the proper number of lines per page, and control widows and orphans by adjusting line count on facing pages within 'exception' rules--generally plus or minus a maximum of two lines. It was all done manually. (And previous to that, it was done with a knife and hot-wax as a paste-up, and that took even longer!)
But even with today's programs and automatic page-generating, if I have to assemble a single, printable PDF file from three different 'master' files--one for each movement--I will have some fancy footwork to do in a PDF editor if the best page makeup (taking page turns into account, etc.) winds up with the first movement ending part-way through page 9, and I want the second movement to start on the next system, rather than on the next page. It is far, far, far easier to do the page makeup in MuseScore itself, but to wind up with a coherent, contiguous whole, I need to be working from ONE master file, not several.
As for really massive works such as full symphonies, operas, and so forth, unless one has a computer with multiple terabytes of memory (and a supercharged CPU), the computing capacity becomes the limiting factor, and there is nothing MuseScore can do about that. Such works will have to be broken into separate files unless and until that limitation can be eliminated by advances in hardware technology. But publishing an opera or a symphony is a different scale of project than publishing a songbook, sonata, or method book, and if each succeeding movement or act starts on a new page, that won't make as much difference in a 150-page score as it would in a 24-page score where adding one additional page means having to print an entire extra sheet of four pages, three of them blank (or with 'filler' material on them). In large publications, it is accepted that there will sometimes be blank pages required to fill out the printing signature. It's just the way publishing works.
In reply to Well, yes and no. I certainly by Recorder485
MuseScore 2 does make it a lot simpler to print a score from multiple files, though—see https://musescore.org/en/handbook/albums#print.
In reply to *Next step would be to allow by [DELETED] 5
I suspect a "new super score structure that can list scores one after each other" is not a bad way to think abut this long term. I can imagine all sorts of reasons you might want to assemble a "dynamic album" out of relatively unrelated scores, wanting them to flow naturally in a way you couldnt easily do assembling it after the fact in a PDF editor.
But indeed, linked parts seems almost inherently incompatible with this idea, at least as currently implemented. The solution *might* be something that was discussed a bit a while back - in conjunction with one of the GSoC proposals - where you allow a staff to be defined by having different measure ranges map to corresponding areas of different "master staves". Lots of major rewriting to make that happen to, though, I imagine.
In reply to I suspect a "new super score by Marc Sabatella
Lots of major rewriting to make that happen to, though, I imagine.
Indeed, and it will make MuseScore even more complex. Personally, I prefer to make MuseScore easy to use for most frequent use cases. The symphonies, contemporary music are not part of these use cases... and I'm fine if they need to use a desktop publishing suite to get the final result.
In reply to Lots of major rewriting to by [DELETED] 5
I do not disagree that symphonies, opera, and contemporary music are a small part of the use cases--for the reasons stated, I would not expect users to attempt to set full symphonies or operas as a single file anyway--but there are many more use cases that are NOT rare, and, in fact, are probably the most common type of music published today. Broadway, pop, movie theme, and jazz standards 'songbooks' come to mind immediately, as do method books and instrumental collections (24 Easy Pieces for Clarinet, The Joe Doakes Piano Method Book I) and collections of the shorter works of the masters (Trois Gymnopèdes de Éric Satie avec les orchestrations de Débussy).
I don't see adding either a 'super/master score' structure, or enabling local application of things like bracketing, instruments, and intstrument-name changes as making MuseScore 'even more complex' for the users. There are things currently in the UI that could probably be simplified to good effect, but in general you guys have done a VERY good job of making the program about as 'user-friendly' as it could be. I recently added a new associate editor to my staff, a long-time Lilypond user. The XML renderings of my mscz files as opened in his Lilypond were too full of collisions, exceptions, and general garbage for those files to be usable, so I suggested he download MuseScore, and he did. Within 2 hours, he was happily (and competently) editing highly-complex mscz files that I had sent him for revision/verification of the bass figuring. That speaks very well for you all, and I have complete confidence that if you decide to do this, you will find a way to do it well.
Please don't cop-out and shunt the load off onto some desktop publishing suite. No professional typography program exists today without including page-makeup as one of its basic functions. MuseScore already includes that function, and it is easier to use than many text programs. All that is needed is either a way to merge files into a seamless graphic unit, or a way to change the graphics (instrumentation, brackets, etc.) within files. There should be no need for an entirely different program--one that would NOT be able to edit the material it was managing--to handle that.