Multiple pieces and multiple scores: a summary?

• Jun 9, 2010 - 00:56

Hi!

Now that the rush to get 0.9.6 out is over, perhaps it is the time to look and plan on new features.

The subject of this post is a topic regularly recurring: see an older post , this issue with an interesting proposal , another post , another post , a newer post and the others I am sure I'm overlooking.

The later versions have improved significantly, but there are still 'rough edges'. For my needs, I feel this is the biggest limit in current MuseScore (the limit with a general applications, there are other issues specific to the kinds of scores I deal with, which I'll address in separate posts).

I think there are at least 2 aspects of it.

1) Multiple pieces in a single file

When combining several pieces in a single MuseScore score, the limitations of the current implementation are:

* Necessity to turn off all courtesy key and time signatures in order to avoid them across pieces.
* Courtesy clef changes.
* Key signature of a following piece includes superfluous natural signs if 'needed' to turn off previous, different key accidentals of the previous piece.
* (Full) instrument names are not repeated (and have to be added manually with approximate results).
* Unclear behaviour of repeats of various kinds (see this post ).

I believe the best proposal remains David's idea of a section break similar to the existing line and page break, but more flexible. Each section break should include the following properties:

  • line break: boolean (yes/no) (default: yes)
  • page break: boolean (default: no)
  • courtesy time signature before it: boolean (default: no)
  • courtesy clef before it: boolean (no)
  • courtesy key signature before it: boolean (default: no)
  • add naturals to new key signature: boolean (default: no)
  • repeat long instr. names: boolean (default: no)
  • reset start repeat and D.C.: boolean (default: yes)

and, as I am at it:

  • pause during playback: number (in secs;)

This may look complex to implement, but I think most of the building block are already in place.

2) Multiple files for a single work

On the other hand, when actual chaining all the pieces in a single file is unpractical (file size, response degradation, clumsiness of navigation, ...), and the work has to be split across multiple files, the main issues are:

* No way to have multiple scores with a continuous sequence of page numbers.
* All formatting options must be manually set (and updated at each change!) in each file ("Save Style" and "Load Style" help, but not completely).

  • A quick-and-(not-so)dirty way could be simply the possibility to set the first page number of each document (and then chain the exported PDF's with some external utility)
  • another option could be implementing some kind of 'master document' referencing all the individual files, applying a single set of style values and sequencing all the page numbers (it may be assumed that the separation between files is always a page break). Seeing interactively the result would be a great bonus, but it is not really required, as the master document could be an export-only feature (to generate a consistent PDF, for instance); the important detail is that each document draws its style(s) from the master document, rather than from itself.

My main interest, it is clear, is about engraving better and more precise scores (I'm less exacting for other aspects, like payback), but I hope this summary of suggestions and requests could help.

Thanks for reading,

M.


Comments

A simple section break that is uses all the defaults that Miwarre mentions above without making these properties changeable would be better. For example, MuseScore already has a Page Break so add this option as a property of section breaks just provides two different interfaces for doing the same thing. Having two interfaces for the same thing means that both interfaces need to be documented, maintained, and users would need to learn (or at least understand) two interfaces for no added benefit.

Similarly the other section break options proposed above add complexity that isn't needed (as far as I can see). For example, I can't think of an occasion when you would want a new movement to start on the same line as the previous movement.

David, of course you are right generally speaking.

1) That a new section break is added to the existing line/page breaks or supersedes them (keeping all required backward compatibility) is mostly a matter of software architecture and coding style, as long as the intended result is achieved.

2) I know that this sounds complex, but it seems a needed complexity. Me too, I cannot think on the spot of a case where neither a line or a page break is wanted, but I kind of remember usuariomuse came up with one I cannot retrieve now and the creativity of users is so wild than, if such a thing be implemented without this property, someone would ask for it!

But for all other properties, there are actual needs: I met them in my work with MuseScore.

3) A possible intermediate solution could be having a single boolean property "Start a new piece yes/no" added to both the existing line and the page breaks: if "yes" they would internally set all the behaviours to the defaults listed above (except the first two, of course), if "no" they would invert all these defaults.

This would be simpler to describe and to document; however, it would be less flexible and only marginally simpler to code as only the UI wold be reduced, all the internal code would be mostly the same as the 'full' implementation.

4) It would be nice to have some comments on part 2 (Multiple files for a single work), which seems to be a less discussed aspect.

5) Xavierjazz: music notation is indeed complex; and here we are sticking to modern notation only (or mostly). Widening the temporal arc a bit to include, say, XVII c. music (so, not very back in time...) would open a whole lot of cans of worms!

Thanks,

M.

P.S.: Of course, speaking of "payback" in the main post, I intended "playback"!!

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