mike320's wish list for version 4

• Aug 12, 2020 - 19:23

These are things I've wished I've had over the past few years of using MuseScore. Most have been asked for by others and I'll do my best to not duplicate existing feature requests. I'll add them to the issue tracker as needed. I'm curious what others think about these ideas. I haven't included things I know are being worked on, like duplicating system items on lower staves. These are not in an order of priority, just the order I remembered them.

  1. Ability to merge two staves into a grand staff and split a grand staff into two instruments

  2. Ability to have dissimilar instruments on the same staff

  3. Ability to easily add a new instrument definition

  4. Local times signatures that work

  5. Allow more flexible parts to be written in conductor's scores.

  6. diatonic notation

  7. make it easier to have temporary divisi sections for the strings

  8. slurs and ties that skip voltas or end in both the first and second volta

  9. accidentals (that work) on trills and turns

  10. do things fewer than every time.

Now for explanations.
1. I've seen various questions in the forum where the answer for a piano score was to split the staff into two instruments to overcome a problem. Unfortunately I can't remember a specific example right now. The suggested solution came from a pianist, not me. If this could be done temporarily (starting here the staves are two instruments) it would be great but doing it for an entire instrument would work. It can be a PITA to copy notes from one staff to another at times. This could be used for other instruments as well. It's not uncommon for Horns to be written on a grand staff but certain sections would be easier or even possible only with two staves.

  1. It is very common in symphony scores for the 3rd trombone and Tuba to share a staff. Making both instruments play their own sound is a PITA.

  2. It would be nice to not have to edit the sparsely documented and mostly confusing instruments.xml to add an instrument. There are some uncommon instruments that people write for and the list of instruments continues to grow with every release. People could then easily add instruments as they like. I want to be able to add horn written an octave lower than sounding in the bass clef as is very common for 100+ year old scores. Horns come in about 10 keys and I never know which one I'm going to encounter next. Being to add them from within the program would be a big plus.

  3. The current code for local time signatures needs to be thrown out and the need to not be based upon the tuplet code. It should be possible to copy and paste to and from the same time signature all of the time and it would be nice if there were options to copy and paste between measures with different local time signatures. Currently it is so tedious to manage 20 instruments that change time signatures in different measures that I've given up on scores like that. I you do it wrong you will either cause a corruption or not be able to add and remove time signatures.

  4. The title is probably obscure but the explanation should be clear: Allow the user to have "a 2" sections for (e.g.) both flutes or even have the notes written as chords for the two parts as is common and still be able to accurately extract the parts for each flute.

  5. The is no support for diatonic instruments. You must define them as chromatic and then be responsible to not enter an illegal note. Also, many diatonic instruments are string instruments and have their music written on unique tablature staves. The user should have the ability to define the symbols used on the tablature for each note. See https://musescore.org/en/node/88646#comment-679091 for a proposal I made several years ago.

  6. There is some work planned for version 4 that will improve this, but I want to point out a common notation in scores with string sections in particular. Single staff may be labelled

Violin I (followed by a staff)

When it gets to a divisi section it is common for the staves to look like this (without the dashes)

-------------Desk 1 (staff 1 goes here)
Violin 1
-------------Desk 2 (staff 2 goes here)

This is not currently automated and difficult at best

  1. This is mostly self-explanatory but the workarounds for the ties don't work for playback

  2. You can currently put accidentals on trill lines only, but they are decorations rather than functional. Accidentals need to be able to be put on the ornaments (trills, turns etc.) and affect playback, both below and above in the case of turns and reverse turns.

  3. I've seen things like 1st Clarinet only second time, p (f second time), 8va second time and so forth.

Comments

• Aug 14, 2020 - 15:52

You just did.

Beams over barlines and system breaks is one I really want but didn't think about. They are totally rewriting the code (mostly cosmetic changes but some other changes from what I've seen) so perhaps they will totally rethink their approach to beams so this can be fixed at last. The original bug had an issue report number of under 2000 so it's always been a problem.

Could you explain what you mean by first page layout problem? I have my own ideas and I believe the plan is to address them in 4.0 so I didn't mention it.

I was hoping to get people like you to add ideas and discuss my ideas so people like @okotophonie, @tantacul and @anatoly would see them.

Reply

• Aug 14, 2020 - 16:17

The "first page layout problem" describes the situation that the first page in a score usually has title, composer, lyricist, score/instrument name mentioned somewhere, which is why the staves on the first page have less space available then usually.
Currently that means that staff spacing has to be configured for the first page, and on the following pages many, many system spacers have to be used to spread the staves apard again.

EDIT: I just saw that there is a spacer that can narrow down the distance between to staves! Yeah!!! New to me!

I'd like to add more things to your list, if I may:

  • Staff lists (like Finale has; for adding Tempo, Rehearsal Marks and the like to selected staves (instrument groups));
  • Multiple Font usage in Text Fields (currently only 1 is allowed and the look of a Tempo indication using a note is horrible!);
  • Special vocal staff, where dynamics, articulations, tuplets etc are automatically placed above the notes;
  • Many more features to the QML plugin system (especially path handling, a better inline editor (that also recognises changes in dependency files), a way to integrate Musescore with the QT Creator IDE...);

Reply

• Aug 14, 2020 - 16:36

I do like the fixed distance spacer you can use to pull staves together but I would prefer the first page have it's scaling adjusted to autofit or have the option for the layout to be unique for the first page of a score and after a section break. There are plans to improve the automatic layout of a page so I didn't include this on my list.

There are several proposals about how to allow system items to be repeated on lower staves and I'm rather confident a method will be in 4.0.

Multiple fonts are something I've never heard mentioned or thought about. As for the ugly note in a tempo, I turn off bold for notes and dots to make them look better.

Having default locations by staff for a dynamic is something I've wished for and heard about often. I suspect there is a plan to address this, but I'm not sure.

I don't mess with plugins so I'm not one to discuss the specifics these at all. I've seen your other posts concerning this. There are some people with a lot of interest in this subject, but they seem to have their own agendas. They've done a lot of work to improve plugins since about 3.1, but it was so they could create the plugins they wanted. I suggest you examine some of BGS's plugins to see some of the capabilities and how they might be used. It's unfortunate, but this is the ways plugins have been documented from the beginning.

Reply

• Aug 14, 2020 - 16:54

@First page layout: I agree with you, of course, if there could be a better solution, maybe even one that is not fixed to the first page only (thinking of multi-movement compositions...)!

As for the Tempo indication: I really wish there was a nicer option available. Switching off bold does not do it, the note – if one is used - needs the get special treatment. Currently it looks "vertically challenged"...

Maybe you can find out something about the staff list idea? It seems you have quite some insight in what is going on.

Plugins are great when it comes to contemporary notation. I used Lua a lot with Finale and would love to provide some in QML, but most if them need config files, so I need would need quick files access (quick save-to-same folder, which seems to have been there already in v1, but got lost somewhere on the way to v3 – at least that's my impression so far, because most plugins use FileDialog (where you can use a tmp folder or you have to search through your desktop all the time you want to save you config - very cumbersome).

However: great that you put together such a list!! Thank you!

Reply

• Aug 14, 2020 - 17:37

I think ctrl+end ctrl+v should append the measures on the clipboard with everything as you suggest. This should be the easiest part to implement but I haven't seen it often mentioned.

Pasting into the middle of a score can be a bit of a mess. There is not currently an insert paste function, which would be closely related to to what you mention, but I think it should satisfy most peoples expectations for a paste all. If they want to replace measures, they can delete the measures either before or after the paste or even allow the paste all to replace selected measures.

Reply

• Aug 20, 2020 - 14:31

I'll also hope to distinguish turn on one note and between two notes, in which the latter is called a delayed turn, which has a formal Musicxml equivalent. Now only visual appearance is available, both playback and Musicxml export are incorrect, and this brings trouble for braille music transcription.

Reply

• Aug 28, 2020 - 13:13

About this, there's a discussion on the issue tracker here https://musescore.org/en/node/16332

I propose there some kind of "paste insert" (as Mike just said) that would do that either at the end or even in the middle of a score by inserting the needed measures, but is not trivial to implement, at least for me.
I wonder if there would be an easier shortcut in the code... like, just copying a chunk of the whole data structure. In any case this is a high priority feature for me too - working on large pieces with time sig changes is a PITA.

Reply

• Aug 28, 2020 - 14:00

There are things the user can do to emulate this insert measures command. Here are the actions the user can take, so MuseScore has the capability already the only problem is putting them into action for the Insert-Paste command

The user can select more than one consecutive measure and select a time signature from the palette. The result, will be the new time signature at the start of the selection and the original being switched back to immediately after the selection.

The user can insert one or more measures at any point. The default shortcut is ctrl+insert on non Mac computers.

I don't see why these would be too difficult to tell MuseScore to do these actions for a paste insert command. The only new thing left would be all of the other system items like tempos, rehearsal marks and system text among others. Marc said at one point that these can already be put on the clipboard. I do realize writing code for this has it's own challenges (like undo must undo the entire paste at once, not the insert then the measures and so forth). I also realize you would need to consider that there may be time signature changes at every measure (which is something I would absolutely use this for!). Finally the selection filter would need to be properly modified to handle system items. I think a design ideas discussion should be put in it's own forum. I suspect this would be a rather active discussion (but you never know).

Reply

• Aug 23, 2020 - 13:56

A built-in OCR function based on AI would be nice. OCR programs seem to work as if they are myopic and have to analyze every pixel of a screen or memory object from extremely up close. There should be a "take a step back" approach to OCR, where the program looks at the big picture the way the human brain does.

Reply

• Aug 23, 2020 - 14:00

I realize the import PDF function has a lot of problems and I know there is work being done to improve it. OCR (or OMR) is really a major undertaking by itself so I would be rather shocked to ever see it built into MuseScore. I'm not extremely familiar with Audiveris (the company MuseScore uses) so I'm not sure if there is something you could do to help like testing fixes and giving feedback.

Reply

• Aug 27, 2020 - 23:34

Editing the .mscx file?

That's such a user friendly thing to expect a user to do. All they have to do is learn musicxml. Learning musicxml is so easy that only one programmer associated with the MuseScore project will touch musicxml import and export issues.

Reply

• Aug 27, 2020 - 23:59

The wish list isn't just for me and there are some things on it I'll probably never use. I'm certainly not looking for how to do these things in version 3. Many of the items in this list are in response to seeing a bunch of people asking "How do I...?" and the answer consists of a workaround or it's not possible. Editing the .mscx (which is very close to musicxml with more additions than subtractions) is a workaround I've seen suggested before but most users wouldn't have an idea of how to go about doing that.

Reply

• Aug 28, 2020 - 13:49

I was trying #2 some days ago.
I came up with this mock-up of the Instrument Change inspector (still 3.x tho).
To begin with, I think the inspector should show what instrument is this, instead of just the button "Select Instrument".
Then I think that an Instrument Change should have the option of being added to all tracks/voices, OR choose to which ones. Then this should be reflected on the staff long/short names as in the picture. It would take a hidden instrument change at the beginning of a staff if that's all you need but also allow changes mid-score.

(This would also need to allow more than an Instrument Change in the same tick/chord).

instrument change on voice.jpg

Attachment Size
instrument change on voice.jpg 32.76 KB

Reply

• Aug 28, 2020 - 18:45

All of those suggestions sound good. Let me add to your number #2. I am guessing you mean dissimilar instruments that play at the same time. You can already change the instrument at the beginning of a measure BUT it changes it from the previous instrument.
I would like to add: Ability to have dissimilar instruments on the same staff with dissimilar staffs. This would be important for the percussionists if you wanna change bass drum to chimes. ( wanted to do this but couldn't. Had to add another staff)
I have a new suggestion that I have discussed before but it was poo-pooed (yes, I wanna use the word "poo-poo"). My suggestion is to be able to drag a note (any element really) left and right and notes/elements in the way just move out of the way so you can drag a note somewhere without having to cut-paste. It would intelligent enough to adjust the spacing/timing of the notes in the measure.
Definitely agree with your #8. I wanted to do that, but couldn't. There is a fairly simple workaround, but still.

Reply

• Aug 28, 2020 - 19:10

There has been a lot of work done in the last few weeks to make it possible to switch between pitched and unpitched instruments with different stave. I knew of this work, so I didn't include this in my #2. I suspect it will be in version 3.6 when that comes out and have no doubt it will be in 4.0 when that comes out.

My #2 was related to different pitched instruments as in my example. This is possible to a certain extent, but it could be made easy. As for dragging notes around to a new beat, I don't care about that but you're not the first to suggest it.

Reply

• Aug 28, 2020 - 19:30

The short version is use an instrument like the C trumpet that has 2 channels. Assign one instrument sound to the normal channel and one to the mute sound. Use staff text to set voice 1 to normal and voice 2 to mute and each voice will have a different sound.

There are insurmountable obstacles to this because you cannot properly notate a C flute and Bb Clarinet on the same staff.

Reply

• Aug 28, 2020 - 19:48

Mike,
You say, it is very common for 3rd Trombone and tuba to share a staff. OK. I don't know symphony scores well enough to argue that point. However, Is your suggestion JUST so you can duplicate the look-feel of a symphony score? Other than "look-feel" who cares if they share a staff or not? I DO see a need to change instruments on the same staff, but that is not what you are suggesting. I really don't care one way or the other, I am just playing devil's advocate to understand need for the suggestion. BTW: Definitely agree with your #5.

Reply

• Aug 28, 2020 - 20:08

People do want condensed scores where several instruments are on a staff. Putting similar pitched instruments on a single staff is definitely not unheard of. One situation I see in symphonic scores is the piccolo and a flute on the same staff written as unison but played as with the piccolo an octave higher. The same is quite common with the cello and contrabass, their notes are also an octave apart.

There are a couple of reasons for doing this. First, it allows for more instruments on a system. At times, page space is at a premium and putting the flute and piccolo on the same staff might make enough room to allow for another system without needing to shrink the score. This is related to the fact that people like to make their scores look like the historical prints. I've seen people who do a beautiful job of this since version 2 but playback suffers as a result. Probably most important to me is that when I make scores intended to be converted to Braille (which is now every score I do), the Braille is being made so a blind musician and sighted musician can look at the same score and refer to something on page 83 and be on the same page. If I can't at least have the same pagination the work arounds aren't pretty.

Reply

• Aug 28, 2020 - 20:36

You know. You are right. My brother plays flute and I think I have seen piccolo on the same staff as his flute. I just thought they did it because the flute player can also be the piccolo player. Didn't think about two different players. You may also wanna do it with Bassoon and Double Bassoon?

Reply

• Aug 28, 2020 - 22:12

I haven't seen a flute and Bb Clarinet on the same staff written in their respective pitches so perhaps that's not something that would be worth the effort. Instruments of the same pitch or octave transposing instruments are things I've seen quite a bit in all of the examples I've given. If the capability were added, it could automatically be applied to bassoon & contrabassoon even though I don't remember seeing it. One this I saw recently for the first time was viola and cello on the same staff written in unison presumably meant to be played as octaves like the others. That would also be possible if this were implemented.

One related thing I've rarely seen is horn 3 playing on the treble clef and horn 4 on the bass clef written on the same staff. Perhaps that's pushing it. If this were implemented I suspect the workaround would be rather easy and worth it for the few times I've seen it.

Reply

• Sep 11, 2020 - 17:35

I have finally seen an example of two different instruments notated on the same staff. One is a transposing instrument. I saw Trumpet and Oboe on the same staff in an original Baroque score I was looking at the other day. BTW: Scores from 200/300 years ago were very beautifully engraved. He also put Violin and Oboe (non-transposing instruments) on the same staff. Odd. It looks like the composer notated the instruments in Concert pitch, so the player would have to transpose on the fly when playing. Unless they played from individual parts, which I guess is what they did.

Reply

• Sep 11, 2020 - 18:16

I haven't seen the score (could you post a link if it's online?) but my guess is that it was written for a trumpet in C. Non-valved instruments (like trumpets and horns) of this era used tuning crooks to allow the musician to play in a variety of keys.

Reply

• Sep 12, 2020 - 19:53

Thanks for the music history lesson. Would you know why they used flex ensembles? I do know that 100's of years ago it was a lot harder to find talented musicians (school educated) than is it now. Wonder if that had something to do with it. Have to admit, not a big fan of Baroque music, except by the giants (Bach, Handel, Vivaldi, Telemann). But I do like the Fanfare by Mouret, which is the piece I was referencing in my post.

Reply

• Sep 12, 2020 - 20:00

Instruments simply weren't standardized the way they are now, nor were ensemble configurations. There days you can write music for a string quartet and you know that there are thousands of such groups ready to play your music, and they all have instruments with the same basic design. Same with "marching band", "brass choir", or a bunch of other ensemble types. That just wasn't necessarily the case 400 years ago - this stuff was still in the process of being invented.

Reply

• Sep 12, 2020 - 20:01

Organized orchestras were rarer in the Baroque era than the Classical era so it was more common to write flexible scores that could be used by a variety of instruments. This leads me to believe the score you are working on has the Trumpet part written in C but the musician would more likely play it on a trumpet tuned to D and transpose it.

Reply

• Sep 12, 2020 - 20:14

Thank you for the music history lesson. Hard to believe with such Giants composing during the Baroque era, they had a hard time finding orchestras to play their music. Another oddity I found with that Baroque score, the Key signature notation, on the treble clef only, was on the A and D rather than the C and F. Wonder if that was the standard way back then.

Reply

• Sep 12, 2020 - 21:30

I'll return to my previous request. Could you post a link to the score if it's online or even the source score itself?

In the Baroque and early classical eras it was common to use a variety of transpositional clefs to avoid ledger lines. Some of these are still common today, especially the alto and tenor clefs. MuseScore has a wide variety of these clefs. Another possibility is that you simply have a typo on the score. It would be difficult to tell for sure without seeing the actual score.

Reply

• Sep 12, 2020 - 21:39

If you are looking at IMSLP#601917 the "treble" clef is what is identified as the French Violin Clef in MuseScore. Everything is written a line or space lower than on the modern Treble clef. We used to get people using this a lot by mistake and asking why there notes are in the wrong place. It's still in the advanced palette.

Reply

• Sep 12, 2020 - 23:13

It's not that the composers had a hard time finding orchestras to play their music; it's that orchestras weren't standardized. So, one orchestra has one set of instruments, a different orchestra has a totally different set of instruments. So you needed to write music flexibly. Somewhere in the 1600's is when this started to get more settled, but in the days before modern mass communication, and also during changes to the nature of the music itself, this process took many, many years.

Reply

• Sep 1, 2020 - 19:31

I didn't expound on #10 very well. The things mentioned are things I've seen to do after a repeat. Since I posted this list I've seen 2 or 3 people ask about doing this in the forums. This doesn't make it the most popular request but it does tell us that it's a feature people want.

Reply

• Sep 2, 2020 - 08:47

The repeat rewrite for 3.5.1 does some behind the scenes preparation work to be able to enable this in the future. I'm (slowly) working towards this (at least technically, it'll need design input for usability :) ), but need to wrap my head around a big chunk of the playback code, which I currently don't have a grasp of.
It might also "complicate" the interaction with things like the PRE, which currently match "written notation" of the "every time" case.

Reply

• Sep 2, 2020 - 14:34

I do realize this isn't in MuseScore because it is no small task. As for writing code, I'm not very useful there. Coming up with pseudo code logic I can help there if that's the design input you want. If you want your PRs tested before they are pushed, write the code and put it into a 3.5 build and I'll test it for you and give feedback for both usability and stability. I'll try my best to break it but obviously won't come up with every strange idea someone might come up with.

Perhaps the PRE can use a type of unroll technology for the parts of the score that are identified as first or second time (etc...).

Reply

• Sep 2, 2020 - 15:07

The basic approach would be to move the RepeatList as currently existing for Volta's up the chain to be available on all score elements (this is the easy part).
Then upon generating playback events, we can use the "unwound" repeatlistsegments (← technobabble, I'm aware) to filter the events by the current repeat number. (this is the part I need to figure out).

As for usability I meant more in terms of UI design. While the current RepeatList field "works" for a Volta, I can imagine this to be less user friendly for all other elements.

The intent is that this internal approach would allow specifying for each element/articulation/dynamic on which repeat playback of that measure it should be applied. Leave the property blank for the current default of "every time".

Reply

• Sep 2, 2020 - 15:51

I was imagining adding a "Play on repeat..." list to things like dynamics, ottavas, voices (perhaps as a staff text property like for pizz.). I guess it would apply to voltas as well since an entire part might only be played the second time only. UI wise, it seems the inspector is the place the designers want to put these things, though staff text properties are currently accessed through the right click menu. That's a mess I'd rather see avoided (some properties in the inspector others in a popup).

Reply

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