Export unrolled score/pdf
I think with lots of people using tablets nowadays, there is no longer the worry about "saving paper", but there is the new concern about being able to scroll back to follow repeats and DSes and scroll forward to codas. I'm thinking that being able to export an "unrolled" score or pdf might be useful, since the players only need to simply continuously move forward sequentially through the song. I'm placing this feature request here to gauge feedback about usefulness.
Comments
Or a tool to unroll (the repeats of) a score
In reply to Or a tool to unroll (the by Jojo-Schmitz
good point, Jojo. Maybe the user only wants to unroll part of the score.
Would it make sense to do this as a plugin? To be honest, I never have tried making a plugin, but it seems like it could be done as a plugin, and that way musescore codebase doesn't get bloated.
In reply to good point, Jojo. Maybe the by ericfontainejazz
It might be possible to do this via a plugin, but I think it would be very difficult. I think this would be a useful feature for MuseScore to have internally. I think something like this is already done during playback, but only with the audio events, not with notation.
In reply to It might be possible to do by shoogle
yes. Playback has to unroll repeats according to the repeat list data structure. A score unroll feature would follow the same repeat list as well, and would simply be a matter of doing range.write() from each repeat into a new score. Sounds like would be too hard to implement as a plugin, now that I think about it a bit.
(I'm wondering now if could have an unrolled score "linked" to the rolled score. Of course I'm aware that linking brings a whole set of concerns about bugs. And of course would need to be aware elements in original score link to two or more elements in "unrolled score", and be aware that repeat elements in the original score would not have a corresponding element in the unrolled score to link to.)
In reply to yes. Playback has to unroll by ericfontainejazz
Sound like it would take at least twice as long to update a score by having liked scores and even longer when repeats are adjusted in any way. It sounds like you would have to update the note in the main score then update the note in the liked score, perhaps multiple times. I think it would be more efficient to dynamically create a linked score as needed rather than looking for the 3 places to edit a note when it is in a repeat section of a D.S. section every time a note is changed.
I'm not sure that this feature would be very useful except possible to some tablet users. Most people can read repeats and follow the flow of the music without relying on and unrolled version of the song. If they can't read this, then they are probably playing a song that would not implement them anyway. If you goal is to unroll a song with a complicated repeat pattern that MS can't currently follow, then perhaps the work would be useful in developing the system MS 3 will use to enhance the complicated repeats people often ask for.
In reply to Sound like it would take at by mike320
I was imaging that the identical notes in the unrolled score would be linked to eachother, so that modifying one would modify them all.
In reply to I was imaging that the by ericfontainejazz
I don't think you could link the scores via a plugin (unless it was hideously complicated), but I could see the "unroll repeats" feature being a button alongside the "play repeats" button. Pressing the button would once would unroll the repeats and codas, but they would remain linked so pressing it again would re-roll them.
It would be useful to have this in the main code because it would help with playback (the score would be unrolled internally before the MIDI events are created, instead of afterwards) and lyrics extraction in the Lyrics Editor (if one gets implemented).
In reply to I don't think you could link by shoogle
Good points shoogle.
Unrolling the score before generating midi events would fix problems:
#32696: Section break causes pause before repeats and jumps during playback
as well as the perpetual issue to have different dynamics on a per-repeat basis.
I also wanted to caution about issues with unrolling spanner elements that cross over repeats.
In reply to Good points shoogle. It would by ericfontainejazz
I'm thinking it will be impossible to edit an unrolled score. If not, then what would happen to the rolled score if the user added the tie he really wanted between the last occurrence of a note before any voltas and the note after the repeat.
In reply to I'm thinking it will be by mike320
"user added the tie he really wanted between the last occurrence of a note before any voltas and the note after the repeat"
I'm trying to parse what you are saying. If you are saying if rolled was:
and then unrolled would be:
then if user tried to add a tie here:
Then I could see two ways musescore could handle:
1. Prevent user from doing that (or any other actions in the unrolled score that would add a spanner across a jump in the unrolled score).
or 2. Allow for detached ties to be implemented (there is some french name for this terminology...and i know it is a musescore feature request). But anyway that would mean the resulting score when rolled again would be:
But I'm thinking 1. would be the safest, as I think 2. produces a score that is hard to read, anyways.
In reply to "user added the tie he really by ericfontainejazz
I'm talking about this unrolled.
The user really wanted the C in measure 1 tied to the C in measure 3. When you unroll this there are a couple of questions that must be answered. What will happen to the slur when measure 1 & 3 are consecutive and the invisible grace note and tie are removed and a tie entered connecting measures 1 & 3.
I think we were doing some typing at the same time or I missed something, but yours is even better.
In my opinion, your example shows a better problem that would fulfill the feature request. If the user added a tie unrolled, then when it is printed rolled, the tie leaving the note in measure one is considered a separate element than the tie going into measure 3. MS could display the tie at the end of measure 1 the same way it does at a line break
It is far more likely that the tie from measure 1 goes to the same note in both measures 2 & 3. In this case, MS would need to recognize this duplication and only display the tie going into measure 2. It should do the same with the slur/tie in my example. Only print the slur leaving measure 1 into 2, then display the tie in measure 3 the same way it currently displays a continuation tie on a new line. This is what I'm used to seeing in songs I have played. All of this discussion would apply equally to a slur going into measure 3 of course.
edit: BTW, the middle line is C for a Viola)
In reply to I'm talking about this by mike320
I do admit and was worried that allowing user to unroll, edit, and then reroll might be too complicated. But still my original feature request "Export unrolled score/pdf" I think is still reasonably doable. Worst case is to just duplicate the spanners whenever they cross a repeat/jump.
In reply to I do admit and was worried by ericfontainejazz
I was actually hoping for being able to edit the unrolled score, but it is very complicated for a programmer to roll it back up again and I wanted to help considered some of the worst things a user might try to make it do.
I'm curious what other spanners would cross the repeat and expect to be a continuation from before the voltas. (de)crescendos can already be easily continued if needed. I guess ottavas, but there should be no ambiguity with the current display or playback of those if you started one before the first volta and continued them to after the repeat. Trills would be in the same category as a tie since they often terminate in the middle of a measure during a volta and would be very unlikely to be continued to the start of a repeat.
In reply to I was actually hoping for by mike320
Yes it would be great if could edit unrolled and then reroll back. I think the worst case is ties across volta edges & repeat barlines. glissando are also problematic for similar reason. Of course these things are confusing notation to being with.
I am tempted to add that in most cases the unroll of repeats or da capo sections is quite easy to do manually by inserting measures at proper locations and copy/pasting repeated sections followed by replacing repeat signs with regular barlines.
I know this because I always unroll da capo sections manually (except in extremely short pieces) regardless of what the composer did (mainly to avoid backwards page turns).
So if programming this is anything but trivial (I don't know about that) I think one might safely bump it down in the priority list.
BTW in some pieces (e.g. variation movements) the repeats help understand the formal construction of the piece and should not be removed by unrolling without a good reason.
Also if you scroll a part while you are playing from it you actually don't know precisely where the continuation begins, so I see some practical problems with this for tablet users, especially in string sections where two persons share a stand or in this case a tablet. It may be preferable even for tablets to stick with pages with predetermined and optimized (by the engraver) page turns. This way you know you jump from bottom right to top left at every page turn.
In reply to I am tempted to add that in by azumbrunn
well sure in many cases you wouldn't want to unroll. But There are plenty of other cases where other would want to unroll. And sometimes unrolling manually is not easy.
In reply to well sure in many cases you by ericfontainejazz
Just for the sake of discussion, velochy on github implemented something related https://github.com/velochy/MuseScore/blob/master/mscore/linearize.cpp
In reply to Just for the sake of by [DELETED] 5
Well that seems useful. Is there a reason that hasn't been merged into official MuseScore?
In reply to Well that seems useful. Is by ericfontainejazz
Probably not merged as there is no PR?
In reply to Probably not merged as there by Jojo-Schmitz
I don't see much GitHub activity on that account, except for that on Oct 16 and some Mid April. I'm going to ping that user and see if they have been testing that feature. Maybe I can take a look at it and see if it works properly, and then I can just make a PR with that commit and maybe fix any rebasing that it needs. That commit is "notationist17 committed with velochy on Aug 11, 2016". Seems added files svgc.cpp json.cpp linearize.cpp mldata.cpp, but I think I would only want linearlize.cpp (I haven't taken a look what those other files do).
In reply to well sure in many cases you by ericfontainejazz
I think this guy https://musescore.org/en/node/184166 would find your unrolled score useful.
Velochy responded to my request to incorporate that git commit:
So looks like I'll test it out and see how to incorporate.
My two cents:
Sometimes (not seldom, not often ;) I'm using for arrangements hairpins over more than one repeat. More a positive side effect could for this feature could, that the musician (I mean in this case a nonprofessional) could get an imagination how this music part should sound (when they practicing the score at home).
I'm not sure, whether this feature can handle this special case (but it could be a work simplification in this case to unroll the repeats and inserting the hairpins again and saving the unrolled version as a new file).
Until that I create therefore a second version of an unrolled piece via copy and paste ;-).
In reply to My two cents: Sometimes (not by kuwitt
Indeed figuring out how to have spanners (which include hairpins as well as ties/slurs) work well across repeats and jumps when unrolled is a problem that needs to be taken into consideration.
It seems that trying to figure out how to "re-roll" is going to be too complicated and not worth the effort. But it looks like original feature request to unroll a score will be useful and is doable.
After talking with lasconic on IRC, I just wanted to summarize that:
- Tools->Unroll score will be useful
- wouldn't be linked
- Don't want to use velochy's commit because the score clone is costly and because it doesn't handle lyrics or spanners
- Probably a better way to implement would be to first create a template from the current score, and created a new score from that template, so will preserve all styles that have been incorporated into the score. And then copy all the elements