A discussion of "Implode" and potential revisions to how it works
I’d like to propose some changes to the Edit / Tools / Implode function. Let’s begin by reviewing the current documentation:
Select a range of measures across staves that have substantially similar rhythms, run Edit → Tools → Implode. MuseScore will combine the contents of the staves into chords on the top staff - the opposite of explode. There is a special case if you select only a single staff - MuseScore will do essentially the same thing but combine the contents of multiple voices on that staff into chords in voice 1.
Let’s look at Implode with examples. As the documentation tells us, there are two modes. Here is an example in which multiple staves are selected ("before" on the left, "after" on the right):
Note that Implode combines only voice 1 in each staff. All other voices are ignored and unchanged. Voice 1 of the first staff is the only voice modified.
Let’s try an Implode with a single staff selected. This is only useful if we have more than one voice:
Voice 1 now contains the notes that used to be in voice 2, and voice 2 is gone.
Let’s take a look at a rather simple example that shows one of the big shortcomings of the current Implode:
What’s happening is that Implode uses voice 1 as a guide. It only looks at content on the other staves when voice 1 contains a chord. The documentation states that the measures must have “substantially similar rhythms” and one can certainly argue that an empty measure does not have the same rhythm as a measure with chords. Still, this approach makes a lot of reasonable combinations rather tedious.
The problem also occurs when a single staff is selected:
This is troubling in that even though the voice 2 and 3 notes were not combined, they were deleted.
Now, let’s look at what happens when the rhythms are not “substantially similar”. The first example is with multiple staves:
When a chord in staves 2 and 3 begin at the same time as a chord in staff 1, the notes are copied but their durations are (of course) the same as the other notes in the chord.
Let’s try it with a single staff:
The end result are quite different. When combining voices on a single staff, chords with same start time and duration are combined, chords with different start times, but which occur while a voice 1 chord is playing are left unchanged and chords that occur while voice 1 has a rest are discarded. In this example, nothing is actually merged, but some voice 2 notes are deleted.
Another problem (feature?) of Implode is that it pays no attention to the Selection Filter. If a single staff is selected, it tries to combine voices 1-4 into voice 1. If multiple staves are selected, it combines voice 1 of each staff to voice 1 of the top staff.
Revisions
The revisions I would like to propose are the following:
- Chords are favored over rests, regardless of which voice the chords occur in.
- In single-staff mode, all selected voices are combined into the highest selected voice. A chord is only deleted if its notes are copied into this highest voice or if the notes are duplicates of notes already in the chord.
- In multiple-staves mode, all selected voices are combined into the highest selected voice (as in single-staff mode), but nothing is deleted.
We still need to deal with notes with different durations and start times. One option would be to break chords into combinations that use ties and that can be merged:
There is another alternative: merge the chords that can be merged, and put the rest into additional voices. Only selected (by the Selection Filter) voices are considered. When merging a chord, look at all candidate voices in the top staff. If any of them have a chord with the same start time and duration, merge the chord with that one. If not, but one of the candidate voices has a rest that can accommodate the chord, copy the chord into that voice. If neither option is present, then we could discard the chord or apply the “tie” approach to the last candidate voice in the staff.
The current algorithm either changes the durations of chords with the same start time as chords in the top-most voice 1 or ignores chords with a different start time. This is possible because the top-most voice 1 is the “master”. I would prefer to use algorithms that don’t give preference to one voice over another (as much as possible).
I’m not sure if one of my alternatives is better than the other, but I hate to add a dialog that asks you which method you prefer each time you use the function. Perhaps, we could use a preference setting?
Thoughts? Should I pursue this? Are the other factors I should consider?
Comments
Thanks for the detailed description, it really shows the current shortcomings nicely and also your proposal.
I'd go with your 2nd alternative when combining stavesand maybe with the 1st when working in a single staff.
I couldn't say anything abut this yet when you first asked on the develoeprs' list because nothing was official, but now the the Google Summer of Code students have been announced, I can point out that there is now someone who will probably be working in this area. More information on this coming soon. My guess is that it would still make sense for you to do something like what you are proposing, but it should be a coordinated effort.
In reply to I couldn't say anything abut by Marc Sabatella
Ok. Where are the announcements? When will information be available?
On the developer's list, I saw that someone is aiming for the Holy Grail of Implode: the automatic piano reduction. This is a worthy task, if it could be done. I have my doubts, but I haven't seen the actual proposal.
I can only see two practical uses for Implode: for a piano reduction and to condense two one-voice instruments into one staff using the "1.", "2." and "a2" notation.
Can anyone think of any other real-world uses for either the current Implode or my proposed revision?
If the GSoC project is indeed the piano reduction, then maybe I should focus on condensing two one-voice instruments. I've thought about that algorithm for quite a while and I think I know how it could be done. I just wanted to tackle Implode first because it seemed like a simpler problem.
In reply to Ok. Where are the by freixas
See https://musescore.org/en/node/107871 for the announcement. More details still to come.
In reply to See by Marc Sabatella
Thanks, Marc.
The announcement says "Felix Brauchle (fbrauchle) will extend the existing tools for implode/explode and add the ability to create parts for voices. He will be mentored by Joachim ‘Jojo’ Schmitz (Jojo-Schmitz)".
This doesn't sound like the score-to-piano reduction project, which is probably a good thing. The other good thing is the mentoring by Jojo-Schmitz, since Jojo-Schmitz has already commented on this thread.
I'll see if I can find out what Felix is planning.
In reply to Thanks, Marc. The by freixas
Sorry I apparently wasn't fully awake when I wrote that. Your ideas still look good to me, but indeed this needs to get coordinatet and discussed wit Felix.
In reply to Thanks, Marc. The by freixas
Hey freixas,
sorry for answering so late.
First of all I'll post my proposal soon here in the forum, but I'm a bit busy at the moment.
To your proposal, I can find many of my own ideas in your proposal. For GSoC 2016 I wanted to improve the Implode/Explode tools to handle with different rhythms in the selection. This would be a first step to a pianoreduction tool, as I proposed in the mailinglist.
I wanted to handle with different rhythms as you proposed in your second alternative like Jojo-Schmitz already said, I think it would be quite better to read, even if we can merge max. 4 staves.
So for the Implode tool, I would have copied every voice in the selected staves to one voice in the top stave. Maybe it would be a improvement to break the chords into combinations as you proposed it, but I have my doubt if it would be this good regarding the readability. At the other side it would be possible to have more than four different voices (with different rhythms).
I agree with you to first check if the selected staves/voices could be merged to one voice if they have the same rhythms and also check if there is a note doubled, but I think it would be best to not delete more informations of the original than it's necessary, which would also be better in the second alternative.
So I think the issues about the rests, the voice 1 and the rhythms will be fixed with my ideas, but it will be restricted to max. 4 different rhythms in one selection. I think this would be a restriction we could accept.
If you have more questions, don't hesitate and ask.
I'll also give you a link of my proposal if it's online.
In reply to Hey freixas, sorry for by fbrauchle
Hi. Felix,
Congratulations on getting a GSoC project! Just so you know, I don't care who implements the changes to Implode. To be honest, I'd rather be composing than coding.
I'm happy to hear that we are thinking along the same lines. I would probably complicate things slightly by considering the Selection Filter. It exists, and it should not be ignored (in my opinion) because it makes our programming more difficult.
I would approach it as a case where we have some selected staves and, within, them selected voices, dynamics, fingerings, etc. The first selected staff is the target—more precisely, the selected voices within the first selected staff are the targets. Voices that are not selected should not be examined or altered.
For example, if voices 2 and 3 are selected and voices 1 and 4 are not, and if the first five staves are selected, then all voices 2 and 3 in the selected staves are merged into voices 2 and 3 of the first staff. This allows for no more than 2 different rhythms, but that's the user's choice. Because voices 2 and 3 on the first staff are processed first, there will be no information loss.
In Marc's implementation, he has one big advantage: since he uses voice 1 on the top staff as the "master", he does not need to consider anything except the notes. He doesn't have to worry about dynamics, articulations, ornaments, slurs, etc.
Trying to actually merge multiple voices is a much, much harder job than what the current Implode does. In this case, the Selection Filter could make your life easier by allowing you to ignore merging certain elements. You also have an advantage in that you only need to be better than the current Implode, which is very limited.
One possibility is: if a conflict occurs, merge the top-most element. So if you could merge two notes, but one is piano and the other is forte, you merge the notes and keep whichever dynamic you see first. Another approach would be to only merge notes when the chords being merged are identical except for the actual pitches present. Identical means that all the selected elements (per the Selection Filter) are exactly the same. Any differences require that an empty voice in the top staff be used. Obviously, this approach uses up free voices a lot faster.
The choice of which approach to use might best be given to the end user. Consider the common case where two one-voice instruments are merged into a single staff. Most professionally engraved orchestral scores I've seen use this two-instruments per staff approach. The algorithm for doing this is different from anything we've discussed, but the merge style where any difference requires using a free voice comes close.
Combining two one-voice instruments into one staff in orchestral scores is also the only practical case I know where one would want to extract parts from voices (I would like to hear if there are any other real-world cases where voices-to-parts is useful). This is really such a different problem that I think I'll post my thoughts on how that could be done. Implode, in my opinion, is best suited as the first-pass toward a piano reduction—and, for a piano reduction, I'm not sure I see the value of extracting voices to parts. I'm sure someone will correct me if I'm wrong. :-)
This entry is long enough. I'll post my thoughts on combining two instruments in a later post.
In reply to Hi. Felix, Congratulations on by freixas
Hey freixas,
First of all you're right the part creation hasn't to do this much with a piano reduction. But it fits to the Implode and Explode tool, so it'll be easier for me to do my tasks once I understand how the voices do behave and can use my knowledge for two improvements. I gave a quick look at how I want to implement the new Implode function in this post.
I think the implementation of the steps described in the workaround isn't this difficult. But you're right, regarding the end goal, the piano reduction tool, it would be better to make some more tests on what's really merged. As you said it would be good if there's a conflict with two different dynamics it should be a solution to use only one.
You thought about merging voices to chords if the notes have identical length in your new post in Measure 10 and 11. Seems like a good idea to merge them to a chord if voice 1 is above voice 2. Would you say this should be already included in the Implode tool? I'm not quite sure, because it will take some extra challenge if I have to check this compared to the implementation, when the voices are just copied to a voice in the top staff.
Another question: Are you thinking about a new tool or do you want to extend the Implode tool, so it creates for example the a2 notation itself automatically?
I think it would be better if the piano reduction tool and the two-voice combination tool are separate tools, so they use the general implode function but are analyzing the score more than it does the Implode tool. For example if there are some notes with the same length you can merge them in an additional tool, or you can check the dynamics of the selected staffs and make attempts which to use.
Hi guys,
I'm another GSoC student. I'll be working on something unrelated (note entry via MIDI keyboard) but I submitted a few proposals and one of them was related to this - it might be the "piano reduction" one @freixas was referring too, but I'm not sure because that wasn't the main feature.
My idea was that, rather than than trying to extract parts from voices, instead parts would be written on separate staves to begin with (and stored that way internally) but there would be an option to have them displayed on a single staff. Basically, each score would have a "Master Copy" (which is every part written on a separate staff) and multiple "Arrangements" that only include some of the parts and combine others on a single staff as the user sees fit. MuseScore would generate the combined staff automatically by doing an "implode" on the separate parts, but internally the parts would still be separate to allow independent control via the Mixer, etc. You can imagine how this would be useful for a choral piece:
In my opinion, it makes more sense to do it this way (i.e have the parts stored separately but displayed together in one staff, rather than having them stored together and then extracted) because the computer doesn't have to do any guessing since all of the information is preserved.
@fbrauchle, feel free to take a look at my proposal and to borrow/adapt any of my ideas if you think them useful. However, please bear in mind that lasconic reckons that some aspects of the implementation would involve major structural changes to MuseScore's code so may not be feasible for GSoC (which is probably why a different one was picked), but you might find that some aspects are feasible.
In reply to Hi guys, I'm another GSoC by shoogle
Hey shoogle,
thanks for your help.
It seems to be a really big change in the complete implementation as Lasconic said.
But I like the idea to say, not the staff in the score is original but the voices in seperate parts are original. I thought of something similar I call linked voices. But this would also be quite difficult to implement, because you often first edit the score and make two voices in one staff and then want the parts, so the parts should exist, since you have more then two voices. I'm not sure if this is the most efficient solution.
My idea in my proposal was to add a new attribute which says if a voice is visible or not. So it would be possible to leave the old part creation tool as it is and just extend it a bit, but as i already mentioned here , there will occur some problems.
I'll open a new Forum post soon to check the possibilities and get the best solution.
In reply to Hey shoogle, thanks for your by fbrauchle
No need to make a new post, just leave a comment under your original one so it's easy to find. Nobody else has commented yet so it won't get buried. Of course, you are welcome to make a new post if you want and just post a link to it on the old thread so it can be found easily.
I like your idea for the linked voices - it seems an elegant way to solve the part extraction problem and it would hopefully be quite manageable in the time available. My solution would enable both part extraction from voices and also independent Mixer control for each one (meaning that each part could have its own instrument sound and volume control - see the mock-up pictures in my proposal). Could your Linked Voices feature be extended in the future to allow for independent Mixer control of each part?
My intention was not to change the part creation dialog (i.e. the Instruments dialog) at all, but instead to have a new "Arrangements" dialog. This would allow you to give the arrangement a name, choose how many staves it should have, and select which parts from Master should be included and on which staff. For example, when producing a Vocal Score arrangement from a full orchestral Master, the Arrangement information would be:
Edit -> Arrangements -> New Arrangement...
Name: "Condensed Vocal Score"
Number of staves: 2
Parts included from Master - to be displayed in Staff & Voice...
All other parts are excluded - i.e. the Violin, Flute, Trumpet and all other orchestral instruments.
I promised to talk about the practice of combining the music for two instruments onto one staff. This is common practice for wind and brass instruments. In a discussion long ago, Marc mentioned that more scores are being produced with one instrument per staff (because most music software sucks at correctly combining two instruments), but I've found this to produce unwieldy scores—scores that I cannot reasonably print on my printer even on legal paper, even when empty staves are hidden.
In this entry, I'm just going to review the rules for combing two instruments in one staff. My reference is Music Notation: A Manual of Modern Practice by Gardner Read. In a later posting, I will describe the algorithm I've been thinking about.
Mr. Read points out that there are some other condensations of instruments; for example, A Piano-Conductor Score and a Condensed Score. In these scores, the reduction rules are a lot more complicated and include having to label notes to indicate the instrument to which they belong. I think I would want to see MuseScore correctly handle a two-instrument merge before tackling anything more complicated.
There are two approaches to combining staves. The Implode method is a "batch" conversion. The user selects staves and measures to combine, selects the merge function and the content is merged. In "live" mode (as has been referred to in this thread), the idea is that the two voices exist internally and could be displayed separate or combined (or both!). Changes to the combined version affect the separate versions and vice versa, since they are just views into the same internal structures.
I think the live approach may be a bit trickier than people might realize. I would be really happy if I had just the batch mode version. I'll point out some of the problems as I review how the merge works.
Here is some really boring music I wrote to demonstrate some of the quirks of combining two instruments.
Measure 1: both instruments play the same music. The display is as though only voice 1 is present. In "live" mode, edits to a single note in a section labeled "a2" must affect both voices. In addition, adding an "a2" label should generate some interesting changes. The effects of an "a2" label stops once a "1." or "2." label is found, but also where the notation shows that the two voices are no longer playing the same notes.
Measure 2: voice 1 looks like voice 1. Changes to the notes affect only voice 1. The rests for voice 2 are not shown.
Measure 3: voice 2 is displayed as though it were voice 1. It could be voice 2, but with the stem direction rules reversed and with the rests for voice 1 not showing.
Measure 4: the two instruments are not playing the same rhythms, so we revert to the standard two-voice system.
Measure 5: even when the two instruments are notated as two voices, there are some special rules to consider. In a two-voice passage, if the rests are common, they are placed as though there is only one voice. I had to move them down from the default location where MuseScore placed them. Even deleting the voice 2 rests didn't move the voice 1 rests into the correct position.
Measure 6: we apply the rule that, if a passage consists of mostly separate rhythms, the occasional common note is notated with both up- and down-stems to avoid cluttering the score with a lot of one-note "a2" markings. This is another problem with "live" views: to properly render the combined music, we have to consider groups of notes, not just single notes.
Measure 7: dynamic markings would normally go below the staff and that is fine if they are the same. When they are different, the voice 1 markings go above the staff.
Measure 8: slurs should be above for voice 1 and below for voice 2. MuseScore handles this fine.
Measure 9: this is the reverse of the problem shown in measure 7. Staff text goes above when common, but may need to be placed below for voice 2 when it applies only to that voice. I didn't cover all the elements that might require special placements. Lyrics and chords, for example, are usually not an issue in orchestral scores, but someone will try to merge two staves with these elements, so one would need to be have some answer for what will happen.
Measure 10: if two voices are identical in all ways except for the note pitches, they are shown as though they are chords in voice 1. In this example, both voices are playing staccato. If voice 1 were staccato and voice 2 were not, they would be displayed as two separate voices. In "live" mode, MuseScore would need new code to handle display and editing of this two-voice passage.
Measure 11: when the two voices are combined as in measure 10, voice 1 comes from the top note and voice 2 from the bottom note. If this is not the case, as in measure 11, we return to two-voice notation.
I hope this gives some insight into the requirements of merging two voices. What I've described is some of what it takes to get to engravings that meet current standards. It is possible to do all sorts of merging of voices that produce interesting results but which do not actually satisfy any real-world uses. For myself, I don't want an "almost correct" version of a two-voice merge, unless the "almost" part is within the bounds in which engravers may reasonably disagree.
I'd like to see a batch-mode merge before any attempt to tackle a "live" version. I guess I believe that a live version is complicated enough that it will either not happen or whatever is produced will have compromises so as to not actually meet generally accepted engraving standards (and what I really mean by that is that it is accepted by the conductors that I'm trying to talk into performing my music :-) ).
If no one is specifically tackling this problem, perhaps it would be something I could take on. More later.
In reply to I promised to talk about the by freixas
@freixas, thanks for your detailed analysis with examples! I agree that batch mode should be attempted before live mode, mainly because live mode can then simply borrow the batch mode algorithm. However, I think that there are two separate issues being discussed here, one of which is much easier to solve than the other. This depends on whether the goal of combining two parts on one staff is to...
Producing a reduced part is difficult just like you said, because sometimes multiple voices are needed, and sometimes they are not. However, by simply comparing the rhythms to see if they match it should be possible to create an algorithm that would produce a reasonable reduction most of the time, with the user maybe only having to tidy up a few bits here and there.
However, if saving space is the goal then this can actually be achieved very easily because the different parts can just be put straight in different voices in the new staff - no need to worry about rhythms at all! The only exception I can think of is when what is usually a single part splits into multiple sub-parts (e.g. Tenors split into 1st Tenors and 2nd Tenors), or when there are optional high/low notes. In these cases the sub-part or optional note is displayed in the original voice (like your "a2" notation). However, this does not pose a significant problem because these sub-parts or optional notes invariably have the same rhythm as the main part.
In reply to @freixas, thanks for your by shoogle
@shoogle: Thanks for taking the time to read my postings and thinking about the implications.
Actually, I think there may be a variety of goals, more than just two. In my postings, I have started to focus on a very specific type of staff reduction (unfortunately, I know of no official name for this). Yes, the goal is to reduce space. but to do so following rules that have been in place for a long time. Copying two one-voice staves into a single staff with two voices is an operation that can be easily done today. but that fails miserably at replicating what a professional publisher would do.
Do a web search for scores by traditional composers and check out the wind and brass parts. You will be hard pressed to find any that are professionally printed that don't follow the rules I posted.
I have tried reducing two instruments into one by copying one instrument into voice 2 and then trying to use the current Implode to finish the work. The current Implode is just not up to the task. A new Implode, along the lines I and others have mentioned would do much better. However, there would still be substantial amounts of work remaining.
There is also a significant difference between algorithms that create the desired result without any tweaking and algorithms that require some (even if minimal) cleanup. The difference is that, for a work in progress, you'd sometimes like to do the merge multiple times. Even when the cleanup is minimal, when you have the numerous instruments of a large orchestral score along with the numerous measures of a major work, even a little bit of cleanup becomes a major time investment.
For my own use, what I'd like is a perfect merge that follows all the rules of traditional engraving. What's more, I'd like to be able to define sets of instruments that need to be combined and process them all with a single function. For editing, I'd like to view all the single-voice instruments and hide all the combined versions; for production, I'd like to reveal all the combined staves, perform all the merging and then hide all the merged single-voice instruments.
I do like the idea of a generic reduction tool as well. Even if what it produces does not meet engraving standards, the tool could be used in creative ways as part of a work flow that achieves something that is publishing-quality. I have to admit, that most uses I can think of are for a piano reduction of some sort (2-hands, 4-hands, etc.). This might also be the only way to achieve the Piano-Conductor Score and the Condensed Score I mentioned earlier.
I am facing the problem that, this summer, I will need to edit a score I wrote, combining pairs of wind and brass instruments. I do not look forward to doing this with the current tools, which is why I have a high interest in adding this algorithm. It may be worthwhile for me to implement this, even if, in the end, it remains a tool only in my personal version of MuseScore. But I think it would be useful for others as well, even alongside an improved Implode.
In reply to @shoogle: Thanks for taking by freixas
My apologies - you are correct that multiple instruments are placed in a single voice when they have shared notes, providing this is indicated by what MuseScore calls "instrument change text". It doesn't usually happen for a single bar as your example indicated, but I realise that was just a demonstration you prepared rather than an extract from an actual score. It took a little while, but I managed to find some examples of parts jumping between staves and voices to minimize the amount of paper used. See the attached pictures, all from the same piece.
In the "separate.png" image the notes are sufficiently different that they have been written out on separate staves, whereas in the "shared-many" example the notes are the same so fewer staves are used and text is used to indicate the part the notes belong to.
In the "shared-individuals" example two parts share a staff, but they never overlap so instrument change text is used to mark the transition.
In the "separate-with-sub-parts.png" example the Tenor and Bass parts are on separate staves, but the Basses split into 1st and 2nd Bass - both in Voice 1.
Of course, these examples are rather extreme in terms of complexity, not least because they are from a vocal score so there is the issue of the lyrics as well as notes and rhythms. Orchestral scores are probably simpler than this, and vocal scores are usually much simpler too. However, it should still be possible to automate at least some of these space-saving techniques. I would still recommend starting with each part written (and stored internally) on a separate staff and only combining them for display. However, such a task would probably be beyond the scope of a GSoC project.
In reply to My apologies - you are by shoogle
Hey, thanks for looking into this! I just realized that my reference book, Music Notation by Gardner Read has a whole chapter on vocal music, something I've never tackled. I just tried skimming the chapter, but it's a bit too detailed for skimming. I picked out that there are different types of vocal music: chorales (with an "e"), hymns, chorals (no "e") and operatic scores, each with its own rules for the number of staves and how parts are merged.
In the ideal world, MuseScore might have plethora of merge tools for different kinds of music. Engraving reference books should be the guide for these.
Again, a good general-purpose Implode is probably a good tool to have in addition to all the specialized merging functions.
As for the live merging of individual staves, perhaps the best approach is to create some good batch merging function so that the MuseScore team can get a good feel for the functionality that might be needed to support displaying and editing a linked staff. Or maybe the first step (after batch mode) would be linked staves that can't be edited except in their single voice sources.
Just some thoughts.
In reply to Hey, thanks for looking into by freixas
You're welcome!
I agree that the batch merging function is a good place to begin. A quick-and-dirty implementation would be to simply automate the process of copying between staves/voices and then to disable editing, as you suggested. However, I notice that the existing linked-parts implementation does allow for editing, and even to have separate layout adjustments for the linked part vs the original, so perhaps there would be a way to make use of this existing mechanism.
Maybe we will find that it is impossible to satisfy all of the different rules for all of the different types of music, and that what the user really needs is a powerful, flexible way to define their own rules. Rather than having linked parts/staves/voices as proposed here, another way would be to enforce linking at the level of each measure. This is an idea I had a year ago. See these two posts (and the diagrams in their attached PDFs) for details:
https://musescore.org/en/node/71096#comment-327816
https://musescore.org/en/node/71096#comment-327831
In reply to Hey, thanks for looking into by freixas
Some general (and probably not very well organised) comments.
I think the idea of a completely general "merge" function is a well-meaning, but unproductive idea. There are simply too many completely different situations in which (in some sense or other) parts are "merged". But I do think the idea of "logical parts" is a very good one -- by this I mean that (as suggested by Shoogle), the underlying data for the whole score is what you edit, and then there are different possible "views" of this data, as for example the vocal score, the orchestral parts, the conductor's score etc. Ideally, it would be possible to have this so that at any point one could edit the 2nd alto divisi bit, and this would be properly reflected everywhere. But I think that the "visible/invisible" idea is usually bad one; as in practice almost every real-life use of "invisible" in Musescore is really a kludge.
To achieve the above, for example for an opera score, requires (at least!) a high quality part-combining function for orchestral parts - e.g. oboes I and II. It also requires an (at least "acceptable") piano reduction for rehearsal purposes. Since no algorithm is perfect (per Humperdinck's theorem), there will always be tweaks required, and thus is is also necessary to be able to save these as far as possible as annotations to the underlying parts.
Such an approach would mean that you could compose a choral work before deciding how to lay out the parts, whether as SATB four staves, or SA-TB, or with varying treatment throughout the work. (See example below for why this last may not be such a good idea.)
So I think that work on a really good handling of orchestral parts (oboes I and II etc) would be really valuable. Unfortunately the last time I played in an orchestra was about half a century ago, so I can't say more about that.
But I do have recent experience of choral (and opera) singing, and I would first comment that professionally published scores are not always kind to the chorus. Typically looking like "save paper" results, they jump between 4 and 2 staves, sometimes sopranos and tenors on 2 staves, sometimes tenors and basses; tenors have to jump from one clef to the other, even basses gets bits of unison with the altos in the treble clef. (These examples from Rutter's Gloria, published by Oxford, a particularly horrendous example.) Rather than try to emulate this sort of thing, free(dom) software should rejoice in the fact that scores aren't actually free(-money) because performers have to print them out, at which point the economics of saving paper are trivial.
About piano reductions: here is a sample system (2 bars, fair use, I hope, but out of copyright where I live) Nightingales from a part song by Gerald Finzi, SSATB plus bottom part labelled "PIANO (for practice only)". I think the problems are obvious enough.
Finally, despite what I said initially, of course a completely general "logical OR" operation will be useful as a general manipulation, but should not be expected to yield visually acceptable results. And can't in general be done (as I understand it) because you may run out of voices.
I just read Imaginatorium's comment and it occurred to me to comment on the "piano reduction" that we all (I include myself) wave so blithely about.
I have been creating piano reductions of my quartets and quintets and my experience is that it's not possible to automate. My workflow, as mentioned earlier, is to copy the instruments into voices in the treble or bass clefs and then try to use Implode, measure by measure, to reduce the number of voices, because multiple voices are really hard to read.
The end result is something that looks like a piano score, but isn't. Since I'm the composer, I can rewrite this mess into something playable. Sometimes I find myself having to create new music because what I was doing with the quartet or quintet just doesn't work on the piano, even if it looks playable (e.g. a piano can't crescendo on a single held note). Vice versa, the piano can play some heavy-duty chords and carry a melodic line or two—something that would be difficult for a quartet or quintet.
So, if anyone is thinking that MuseScore or any other piece of software could ever take an arbitrary piece of music and reduce it to something you could hand over to a piano player, think again.
Because of this, I would never view a real piano reduction as something that would make sense to have "live" linked to individual voices. It's a batch Implode followed by a lot of work. Once you're done, splitting the individual piano voices out into separate staves has little value.
Let me repeat this in terms of a piano reduction for a quintet. I want to merge the quintet staves (flute, oboe, clarinet to the treble clef, horn, bassoon to the bass clef, but sometimes the horn needs to be on the treble as well). After I do that, I do not want the piano part linked to the original instruments as I will edit it in ways that would make no sense to the source instruments. An improved Implode would be very helpful. Storing the music internally as separate voices and displaying them merged has zero value in this work flow.
Live linking to save space (e.g. combining two instruments in one staff in an orchestral score) is a great idea, but difficult to do right. Engravers have figured out some complicated rules for making the merged staff easier to read. These are easier to handle as a batch operation, much harder to process efficiently when someone is editing a live-linked voice. It's worth reading the reference manuals on this rather than trying to guess the proper rules, but it's more of an art than a science—the references usually give suggestions and guidelines, some stronger than others.
In reply to I just read Imaginatorium's by freixas
I agree that creating a true piano reduction automatically is not necessarily always possible - a naive approach might create things that are simply not physically playable. But I'd still vote for having that naive approach available as a starting point for editing.
In reply to I agree that creating a true by Marc Sabatella
I know I write long messages and may not make myself always clear.
Yes, I agree that a tool that can produce a piano reduction would be a good thing. It would be way better than what I do now.
My long-winded point is that this is best done a batch mode operation that produces a new piano part, not a "live" merge of the source staves.
On the other hand, a live merge of two one-voice instruments is useful, so I'm not saying that live mergers are always bad.
In reply to I know I write long messages by freixas
Makes sense to me!
In reply to I just read Imaginatorium's by freixas
I too agree that an live piano reduction will not be as good as a manual one (and perhaps not even playable at all!) for the foreseeable future, but that a batch reduction tool would still be valuable to have. However, even though you wouldn't want the reduced part to be linked to the originals, it would still be useful to have them stored in the same file so that they can be compared side-by-side and any mistakes found can be (manually) updated in both versions at once. This is where my "Arrangements" idea comes in: you have a "Master Copy" of the opera which vocalists + orchestra + piano reduction, and then you create a "Vocal Score" arrangement which only displays the vocalists + piano reduction, and an "Orchestral" arrangement which only displays the vocalists + orchestra. These arrangements live inside the same MSCZ file as Master, and simply specify which parts from Master are to be displayed and which are to be hidden.
In reply to I too agree that an live by shoogle
Hey, you're in luck! I think you can do this today (if I understand you correctly). When you create a "part", you can specify the instruments to include in the part—you can have more than one instrument in a part.
So, for instance, if I have a quintet plus a piano reduction in a single MuseScore file, I can also have parts that include only the five instruments of the quintet or only the two piano staves. The main score includes the quintet and piano.
In reply to Hey, you're in luck! I think by freixas
I didn't know that - thank you! This changes everything! There was a discussion about creating an archive of classical works in MuseScore format, but it was thought that MuseScore isn't ready yet - but now I think it is ready, or very nearly ready! Imagine having a *definitive* Master Copy of something like "The Marriage of Figaro" on MuseScore.com that people can contribute different arrangements to in the form of different parts. A conductor could just go and grab an arrangement for whichever instruments are available in his/her orchestra! All the arrangements would live in the same file, so you wouldn't get the problem of having to "patch" corrections in multiple "forks" of the project.
So now what is needed is a way to combine instruments from the master copy onto a single staff in the multi-part arrangement (although even this requirement will become obsolete eventually as people start reading music from tablet devices rather than paper). An "open source" archive effort needn't wait for this feature to arrive since the idea is that the combination could be applied retrospectively to the existing files, and may even be automatic via a style option or something like that.
In reply to I didn't know that - thank by shoogle
I think the reason to wait has nothing to do with staves or parts - it's because of the whole new layout algorithm being implemented for 3.0. Might as well wait to take advantage of that. Not that basic entry of notes couldn't begin now, but final tweaking should wait.
I'm not really understanding the bit about parts and staves, actually. I'd want the version of "The Marriage of Figaro" in any such archive to be as Mozart wrote it. If people want to create their own custom arrangements for different instrumentation, they could start from that, amke their changes, and upload to their own accounts on musescore.com. But the point of the archive being discussed in the thread you mentioned is to have one good "official" version ("professionally" edited, etc) for each a number of classic scores.
In reply to I think the reason to wait by Marc Sabatella
Of course, the original would be the default, but everybody would want a piano reduction so I think there would be room to put that in the same file. Perhaps you are right though, and arrangements other than the full orchestra and the piano reduction would be best kept in separate files. However, the orchestral arrangement would obviously be the starting point for any reduced arrangement, so what might would would be to have arrangements as "recipes" that describe how to get from the orchestral version to the arrangement. When the definitive copy is updated then the arranger would re-run their recipe to generate the updated arrangement.
I promised I would provide an algorithm for batch merging two one-voice instruments to a single staff. I don't know of any name for this style of merging, but for the sake of convenience, I'll call it an "a2"merge. Since there is some interest in live-linking voices, I'll mention a few issues to consider with live-linking.
Terminology
Selection and Error Checks
Creating an a2-style Merge with Linked Staves
The user somehow requests an a2-style merge and selects two source voices (not staves).
Basic Merge Types
The merger is done by comparing source voices 1 and 2. There are six possible combinations and I will assign each a label.
For comparison purposes, only elements allowed by the Selection Filter are considered.
When comparing a region larger than one chord or rest, the condition for each merge type (except v2) must be met by all chords and rests.
Merging and Displaying
There are some special rules for elements other than chords or rests.
Chunking
We don't want to produce a lot of "1.", "2." and "a2" marks. This is crucial to providing a quality score. Human engravers can look at the music and often easily determine how to group notes together. It may be trickier for computers. There are cases in which every engraver will agree on what comprises the best layout and cases in which even the best engravers might differ.
Here are the steps I'm considering:
Dealing with the small chunks is where humans will beat the computer until someone comes up with a heavy-duty musical pattern analyzer. I believe the approach above will work pretty well with most orchestral music.
The pattern analysis is what makes it difficult to create a2-style merges from live-linked voices. Any editing changes will change the chunking, which then requires re-examining the chunks, splitting and merging them as appropriate, determining the revised merge types, and then doing the final merging.
One potential problem I've though about is that, at any time X in the score, there may be a plethora of elements other than chords and rests and that these elements may not be ordered. For example, to determine if a staff marking in voice A matches one in voice B, we need to look at all the elements in voice B at time X (we can stop looking if we find a match). When we look at the elements in voice B, we will either repeat some comparisons or we need to keep track somehow of which elements were already matched.
Testing
In addition to whatever code tests are required for MuseScore code, the algorithm will require testing to see how well it matches professionally engraved scores. This will require finding scores using a2-style notation (which is very common) and converting them to MuseScore scores with the instruments separated out.
It is probably a huge advantage to prepare these test cases before coding the algorithm. Looking for and preparing good test cases will probably highlight deficiences in the algorithm even before it has been coded.
In reply to I promised I would provide an by freixas
I realize this is a topic with a lot of very detailed postings (with me being the main culprit).
I'm not sure if anyone is looking this far, but originally, I was looking for something that would both contribute to MuseScore and be personally useful. As someone is already slated to look at improving Implode, I proposed that I add a tool for an a2-style merge.
The first step should not be very controversial and so I might as well proceed with it: Create a test case—a score with two one-voice staves. There should also be a stave with the "right" answer. To create this test score, I would search for professionally-produced existing scores with music using the "a2" notation.
This professional score would be the source of the "right" answer. The two single-voice staves would be manually extracted from the a2 source in the score. The entire score need not be copied—just music that might challenge the algorithm. The test score will probably include music from different source scores.
I probably won't be able to start this until about a week from now. If there is any reason I *shouldn't* do this, please let me know.
In reply to I realize this is a topic by freixas
Seriously - go for it!
Make sure you read the instructions for developers if you haven't already, and ask on IRC (#musescore) if you need help.
In reply to Seriously - go for it! Make by shoogle
Will do!
In reply to I realize this is a topic by freixas
Make sure to coordinate with fbrauchle, to not get into conflict wuth his GSoC project
In reply to Make sure to coordinate with by Jojo-Schmitz
Absolutely!
In reply to I realize this is a topic by freixas
If I understand it correctly, you want to have an Implode tool, which implodes the two lines to one but inserts the notes in different voices for each line. This seems to be exactly the same what I want to do in my GSoC project. l think you could use this, but if you want to start in a few weeks I wouldn't have started implementing this. The rest of your ideas, which are sounding very good by the way, seem to have no conflicts with my project.
Maybe I could start with this the next days, so we don't have to implement this twice.
In reply to If I understand it correctly, by fbrauchle
@fbrauchle: Please, don't worry to much about this just yet.
First, I'm traveling right now and won't start for at least a week.
Second, I'll start by working on getting a good score for testing. Because there are a lot of knowledgeable people here, I will probably post the test score for review.
Third, I have never developed for MuseScore, so I need to get up to speed on the procedures, data structures, etc.
Fourth, I'm not worried about double-implementation. I work on the principle that the first attempt is a prototype. Refactoring is just part of the fun.
Actually, this is not correct at all. I've provided a detailed description of my algorithm and this is not a correct summary.
I actually don't believe our code will have much in common, but there may be a few common functions we can share. We might also want to have a shared user interface. I'm not too worried about it right now. I will look at your proposal and perhaps I will see more commonality. Or, once you and/or I have some code in place, we can review possibilities for creating a common tool. As I said, refactoring my code is not a problem.
To be clear: whatever gets accepted into MuseScore will be something that everyone agrees is a good solution. If I implement something independently, consider it throw-away prototype that will help us get to the optimal solution. Please don't feel rushed to start work on my account.
This is fantastic thread which demonstrates the work behind the scenes for those of us who do not operate on this level. Thank you.
I finally had time to look at creating a test score for an a2-style merge. I checked out scores from the library, some in print, most in PDF format:
I tried to pick a range of dates. It’s interesting that most scores don’t have a publishing date.
Instrument Labeling
There are several ways of labeling a a2-style staff. MuseScore can easily handle this version:
Here are some other styles I ran into. The screenshot is from my attempt to emulate these styles in MuseScore:
In the first staff, the word “Flutes” should be in one column, centered relative to the staff and the numbers I and II should be in a second column, with I and II on separate lines (not separated by the word “Flutes”).
In the next two staves, the word “Flute” should be exactly centered relative to the paired staves (it looks pretty close) and the numbers I and II should be centered relative to their respective staff (these are off). I might be able to do better if I created a text style. This solution fails if the staff size is changed.
The same approach works for the horns.
Line Breaks
When a line break occurs in the middle of an “a2”, “1.” or “2.” section, scores repeated the label on the new line. This is a layout, not a merging issue. When my algorithm merges two staves. it won’t know where the final line breaks will occur. The work-around is to hand-add the appropriate lables once the final line breaks are determined.
Complex Lines
When things get really crazy, the a2 notation is separated back into two staves. This always occurs on a line break. I managed to replicate this.
Here, the flute parts in measure 9 (first measure on second line), could have been displayed in a single staff using a2 notation, but because measures 10 and 11 needed to be separated and because measures 9-11 are on the same line, they are all separated.
I achived this by:
In the case where the a2-style staff can be used for the entire piece, the composer could choose to keep the original, separated instruments and just make them invisible in the Instruments dialog.
a2 Labels
It looked like everyone used “a2”. Some used “1.” and “2.”, some used “I” and “II”. For the horns, though, I also found “3.” and “4.” (or “III” and “IV”). It’s clear that the labels should be selectable.
Annotations (Dynamics, Staff text, etc.)
One item I was looking for was how various annotations were notated in the case where either a two-note chord or two voices were used. The Beethoven work provided some examples as did the Chopin/Stravinsky. When both instruments have the same notations, the notations are placed in their usual locations (e.g. dynamics below, staff text above); when the notations differ, they are all placed above for the first instrument and below for the second.
In Copland’s
Orchestral Variations
, I saw some examples where the music was written as two voices when it could have been written as one voice with two-note chords. In this case, I also saw that the dynamic markings were duplicated above and below for the two voices, even though the markings were identical for both voices. It might be useful to provide an option for always using two voices even when the notes could be combined into a single chord, as well as an option to duplicate notations even when they are the same.
Fine Control
While my algorithm tries to ensure that there aren't a lot of small chunks of a2-style markings, it may not always make the best determination. Since the user controls the content being merged, he/she may want to override the merging options for certain passages. In some cases, the choice of merger may depend on where the system breaks occur. The only option needed is to either merge in a2-style or merge as two voices.
The Test Score
As I am short on time and will be traveling a lot in June, I still owe the forum some test scores. These would be in pairs, with the first showing music written in single-instrument staves and the second showing the expected output of an a2 merger. Actually, if the merger includes some options, then I need to produce results that display the results of the each option.
Summary of Options
Additional Issues?
Does anyone have any additional issues related to a2-style notation, anything I've missed that I should be considering?
In reply to I finally had time to look at by freixas
I would like to close a loop. I had suggested above that I would code an "a2-style" merger and, it turns out that I will not be doing so.
The requirements I provided and algorithm I proposed still seem sound and will be useful should anyone else decide to tackle this project. Having performed a "a2-style" merge by hand, I would suggest that, to be done correctly, this feature needs to be a core part of the system.
The issues that require broad system support are:
A batch version of the merge might be better than nothing. It would require keeping the original staves for part extraction, manually entering markings at the beginning of each system, if needed, fixing the position of common rests, and adjusting the positions of text, hairpins and dynamics that need to go opposite their normal location.
The totally manual method that can be used today is:
I will warn you that for any typical orchestral score, your performance will suck big time (I'm talking about waiting 5 seconds for the system to respond and seeing the screen blank out before redrawing). You can copy the music to a separate file and do the merge there before copying back. This helps out the merger but styling the final document will go at a snail's pace.
In reply to I would like to close a loop. by freixas
I'd also like to see this, and I agree with all above except for one point. @freixas suggested that "Internally, the music should be stored as voices 1 and 2." While this would work, I think that it would be better if the two parts were stored internally as separate staves rather than separate voices. This allows independent Mixer control for each part, and means that the extra voices are still available for other uses (e.g. optional notes, 2nd verse notes, and differences in rhythm due to lyrics being translated into another language). What MuseScore really needs in these situations is a way to specify the purpose of the extra voices, rather than just the content.
In reply to I'd also like to see this, by shoogle
Allowing separate mixer control for the two voices is a great idea. The best way to do that might be to enhance the mixer to support a master setting for each instrument with optional tweaking of the individual voices. This might be necessary anyway to support differing dynamics on different voices, which I believe to be a requirement of merging the two staves properly.
For today's MuseScore, just make all the notes in the merged stave silent and play the notes in the source staves.