MuseScore 3.0 smart layout and general work flow

• Jun 5, 2018 - 15:41

I have seen your video about the coming smart layout. I think it goes into the right direction, that MuseScore does as much layout automatically as it can do. In another post of me here I had a discussion with a user what could be the best solution to have multiple voices with same rhythm on one staff.

The problem I had in this post was, that I have a handwritten A3 landscape score with 18 instruments + the piano staff. Normally too much for an A3 landscape paper, when one uses the default page scale setting. There are some instruments that has same rhythm and they are merged into one staff, so that I have two voices on many staffs. This was made to save space on paper. I learned now also from the other user that this is also normal when one creates an orchestral song with 50 instruments. They want also less paper and write multiple voices into same staff.

So now my problem here was, I wanted that the voices does not look like normal voices, where all beams of voice one goes upwards, and all beams of voice 2 goes downwards. Because of space issues it is often better that the stems of both voices goes in same direction, so that they look more like chords. This is so in my handwritten score. Now I had the problem that I needed many manual settings, like changing the stem direction and switch things like flags, beams and rests invisible for one voice. I needed to manually move the rests of voice 2 in the middle of staff, so that they look like a shared rest for both voices. Later I saw that my manual work is more than I thought at beginning. I needed also to manually relayout the length of the stems of voice one, because they was too short to reach the notehead of voice 2, there was some ugly looking space. I needed to manually change every stem length separately, because there is no length property that I can change by multi-selection. This works needs to be done for every extracted part too, which is very time consuming.

The user pointed me also to the continuous view, which also looks interesting to me. But in the current MuseScore 2.2.1. it does not help me really with my described problem.

I stopped now this solution because the reformatting takes too much time. Now I use one staff for one instrument and use a page scale of 1.3, so that the 20 staffs matches the A3 landscape. This makes it also easier to extract a single voice. In the attachments you will see both versions, the first file it that how the manual written score looks, the second is now my preferred solution where every voice is on a separate staff, this prevents the manual reformatting.

Why I write such a long story?

I hope that my detailed problem story helps to think on such problems when you develop/design the smart layout. Maybe it gives you another directions how the smart layout should work or how the workflow should be changed. Of course my goal is possibly also not the standard way to mix voices in that way, but this is what my old school teacher has written. I just make the paper digital, because I cannot read the manually written one :-)
I need to have the full score for him on A3 landscape and for me I want to extract only one voice on A4 with bigger notes.

I got also an idea how the workflow could be to edit a score. I think one should enter notes always in the continuous view, where paper size does not matter. Every voice should be entered separately in an own staff, so I can concentrate me only on this voice and all its slurs, dynamics etc. The smart layout can make look that nice too of course. I would see this view like a "resource view", where I can build my paper-based scores from.

When one makes now an extraction one should be able to select the staffs from the continuous view and merge them into something what I would called "virtual staff". This virtual staff does not copy the content of the continuous view, it references only the staffs from the continuous view. The virtual staff needs also some configurable options, where I can control the rendering. As example for my described problem it could have options like "share stems", "share flags", "share beams", "share rests" etc. With these options a smart layout knows if the voices are layouted with different stem direction or not.

Maybe if my words are not really understandable you can have a look at the instrument dialog. In that dialog you see on left side a big list of all available instruments. From that list you select something and create a staff with it. My described workflow works in the same way. You create first your resource staffs in continuous view, later you select and combine them into virtual staffs for paper printing.

Just an idea, you don't need to find it good :-)


In reply to by Louis Cloete

I know that I can do that, but this is not an option, because i need the possibility to extract the single voices later. I want to print the full score with all instruments and I want to print a single instrument/voice so that I can display it bigger/better on an eBook reader. Extracting from chords would be not easy, because you have no chance to distinguish the notes by voices anymore. Possibly you lost also all other voice specific things like different slurs, dynamics etc.

In reply to by unique75m

In principle, this wouldn't need to be an issue. A sufficiently smart part extraction facility could sort this out. If it sees two note sounding at once, it would split those into two parts regardless of whether they are a two notes in a chord or two different voices. Only real complication would be ow to handle things like string double-stops, where two notes might be meant for a single part or two parts. I believe shoogle has proposed algorithms for handling cases like that by tracking text like "div" and "unis". I am a little skeptical but open-minded about that, but aside from that case, I'm definitely confident this is doable.

In reply to by Marc Sabatella

From my personal view I think it is easier to express everything as separate voice, also the notes of a chord. A chord with two notes is the same like two voices. The chords have only a special rendering, where stems/flags/rests are shared.

If you merge two voices into a chord with two notes, you will lost the information what is for voice one or two and then you have all the problems you described. If you don't do that and just add the voices into a VoiceGroup, you do not lost the special voice informations. The VoiceGroup needs just some configurable rendering options if stems/beams/rests should be rendered as shared things. If you enter a chord then this VoiceGroup object can be automatically created with default settings for chords. Of course the VoiceGroups should be combinable recursively like this:

             VoiceGroup A (with voice rendering settings)
                   Voice A1
                   Voice A2
                   VoiceGroup C (with chord rendering settings)
                         Voice C1
                         Voice C2

The VoiceGroup can easily splitted again, just extract a voice from them, that's all. The selection would also work much easier, because you have a voice object which you can select or also the VoiceGroup object. And of course a smart layout algorithm can also better work on the existing voices to make some calculations. If you mix everything to one bunch of data, you lost all that useful information.

The workflow I described would make use of that architecture:

  1. you write staffs with voices or chords (which are also voices) in the continuous view
  2. you select such voices and merge them to VoiceGroups into new staffs for paper output
  3. you can change the rendering options of every VoiceGroup, so that they look like chords or like voices

Because you do not make copies/redundant data of the voices, but only references them, you can edit something in continuous mode which is automatically reflected on the paper outputs.

In reply to by jeetee

Currently the extraction in 2.2.1. is more like "select some existing staves you want to wish to see". You cannot change the order of staffs or mix them. It is not like I described, where you should be able to create N staffs, edit voices in there and later select different voices from different staffs to mix it into a new staffs for paper display.

That means you:

  • create staff SA with voices SA1, SA2 in continuous view
  • create staff SB with voices SB1, SB2 in continuous view
  • create staff SC with voices SC1, SC2 in continuous view

  • now you create a paper output staff PSA with voices SA1, SB2, SC1 and display them as chords

  • now you create a paper output staff PSB with voices SA2, SB1 and display them as voices

Normally I would edit only one voice per staff in the continuous view, except chords which are in my thinking also expressed just as voices. Later I mix them together to real paper staffs. The example should show you only how it could work, independent if that is a good example or not or if it makes sense from music composition aspect.

I do not know if you that mean what the GSoC has made, but possibly it is also just a "select something to display, but you cannot change or mix the existing"

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