Cues
Ability to easily indicate cue notes at a smaller size on a part.
Do you still have an unanswered question? Please log in first to post your question.
Ability to easily indicate cue notes at a smaller size on a part.
Do you still have an unanswered question? Please log in first to post your question.
Comments
This should be possible already: select them, rightlick -> properties -> small
In reply to This should be possible by Jojo-Schmitz
you are right again. I was not aware of this and could not find it in the handbook or searching in the online help. Thanks so much!
In reply to cues by jsasso
This I couldn't find in the handbook too ;-)
In reply to This I couldn't find in the by Jojo-Schmitz
Fwiw,I wrote a little plugin you can download from the repository (click Plugins in menu at right of this page) which automatically makes notes small and also silent, which you'd also normally want for cues.
In reply to Fwiw,I wrote a little plugin by Marc Sabatella
Here is the plugin Marc is talking about http://musescore.org/en/project/cue
(Private Joke for Marc : Not typed from my iThing)
In reply to Fwiw,I wrote a little plugin by Marc Sabatella
OK, so that's the reason why it isn't in the handbook: cue notes are not (directly) supported by MuseScore, only via manual intervention or Marc's plugin.
In reply to Fwiw,I wrote a little plugin by Marc Sabatella
I don't see the plugin menu at the right of the page!
In reply to Fwiw,I wrote a little plugin by Marc Sabatella
Could you create a version that does not completely silence the parts or can someone at least show me how to do it myself? I still want to be able to hear the cues, and still have them in the smaller size.
In reply to Could you create a version… by OmniscientCameo
To play cues: select the measures with the cues, click the notes button in the inspector, check the play button in the inspector.
I don't see how to do that too,
Could someone help us?
In reply to I don't see how to do that by Rémi Marche
In 2.0.x select the note and in Inspector tick 'small' In the chord section and unlock 'play' in the note section, see https://github.com/Jojo-Schmitz/Cue. It Comes with a 1.x and a 2.0 verison
In reply to In 2.0.x select the note and by Jojo-Schmitz
Thank you, it's perfect!
In reply to Thank you, it's perfect! by Rémi Marche
Normally I work from a score and then create parts from that score. Making the cues in the score does not automatically propagate to the parts, whereas if I change a note or accidental this automatically propagates to the parts. A simple workaround is to delete all parts and create them again.
In reply to Normally I work from a score by SonomaStrings
Not sure what you mean about cues not automatically propagating - it should. Unless you mean that changing one part does not update the cues referencing that part, which is of course true.
If this doesn't help, please post the score you are having problmes with and steps to reproduce the problem.
In reply to Not sure what you mean about by Marc Sabatella
I think the issue is that making notes into cues—i.e., checking "Small" and unchecking "Play"—does not carry through the parts.
In reply to I think the issue is that by Isaac Weiss
Yes, Isaac is understanding the problem.
When I change a note in the score, or add an accidental, this propagates immediately to each individual part. (This is how the score should interact with the parts.)
I think I should be able to write cues into someone's part from the score (Copy the music, check "small", uncheck "play") and those "cues" should appear automatically (immediately) in each individual part, just like they do for notes.
To reproduce, create a new score with at least two parts. Write notes in one measure for Voice 1. Create parts. Note that Voice 1 has notes, the rest do not.
From the score - Copy the notes in Voice 1 into the other parts. They will be large notes. Look at each part - all parts have large notes.
Go back to the score - highlight the notes from Voice 2 - Check "small" and uncheck "play". Look at Voice 2's part, the notes are still large.
In reply to Yes, Isaac is understanding by SonomaStrings
This is distinctly odd behaviour, and I had not noticed it before in spite of the fact I put cues in my scores and parts quite frequently. A bit of experimentation shows why, however.
When I add a cue to a part, it is usually done during the page make-up stage, when I am formatting the scaling and stretch to get good page turns in the instrumental parts. At that point I can see if an instrument, the oboe, say, has been silent for 57 measures and needs a couple of measures of cue notes to help bring him in at the right point. So I go back to the score and find the right spot, copy the last two measures of the solo part, and paste it into the oboe staff. I can then check 'small' for the element group, and uncheck 'play' as well. And, as you say, the small and silent properties do NOT propagate to the part.
However: If I CUT that section (CTL+X) after I've made it small and silent, and then paste it back in, the small/silent properties come with it, and they DO propagate to the individual part. Go figure....
I only realised this because often, more than one instrument will be silent for a lengthy stretch, and thus several instruments will require the same cue notes. So I got the habit of setting up the cue--complete with a staff-text line over it--and then copy/pasting it into each staff in the score that needed it. Cues thus pasted in show up in the parts properly when I do this.
In reply to This is distinctly odd by Recorder485
I've noticed that oddness with copy and paste as well. Could you summarize your findings for anything that seems an actual bug and file it officially to the issue tracker?
The fact that changing size in the score doesn't affect the part might* be deliberate, as there may be situations where this is desired (just as the visiblity property definitely needs to be independent). But in general, we need a better strategy for deciding and controlling which properties are linked and which are not.
In reply to I've noticed that oddness by Marc Sabatella
I don't think there's an actual bug; the behaviour doesn't cause any crashes or corruption, even though it's inconsistent from one input method to another. I'd qualify this as more of an oversight, I think. Somehow those small/silent properties do not 'adhere' to an element group selection under all conditions, even when they're applied to it.
Here's another oddity, which I just discovered this morning: If you copy a section and paste it into another staff as a cue--the only logical way to do it--and then, without leaving edit-mode, while the blue box is still around the pasted-in material, apply the small/silent properties in the Inspector, THEN those properties will propagate to the linked part.
OTOH, if you paste the notes in, click somewhere else on the score (or hit ESC) to exit the 'blue box', and then re-select the element group to apply the small/silent properties, those properties get ignored on their way to the part.
There's obviously something in the copy/cut code that 'sees' properties of a saved element group that the linked-parts code doesn't recognise as part of a group which has been selected manually and modified but hasn't been saved to the clipboard. When Paste is used to put a saved, copied element group into a staff, all those properties remain embedded and they thus carry through to the parts. Does that make any sense? Sorry about my lack of proper code vocabulary. ;o)
The fact is (and we've discussed this before), MuseScore doesn't have an actual ossia or cue creation tool at the moment, so we're stuck using using basic tools to do the job manually. It would be better if we had a dedicated tool--one which would give the user a number of options as to how to apply it--but until that happens, it would be better if we could at least count on consistent behaviour for all input methods.
In reply to I don't think there's an by Recorder485
I'm going to look at it this way. Cues aren't officially supported in MuseScore, but there is a wonderful workaround that uses small/silent properties. Entering cues in this way has some part propagation consistency issues (not a defect, as it doesn't cause a crash or corrupt the file), but if you remember to create the cue first and then cut and paste the cue into different parts, it works well.
In reply to I'm going to look at it this by SonomaStrings
Yes, it works well...enough. Once you figure out the inconsistencies, of course. I've gotten used to doing cues with this workaround and it doesn't bother me that much. But I still think a real cue function which offered the user a number of options is something worth developing. Cues are an essential element of serious orchestral music, and no one intent upon producing professional-quality editions would want to publish a score without cues in the appropriate spots.
For instance (and I've had this discussion with Marc), it would be nice if cues could be set to appear in the parts but not in the score, if the user wanted to do things that way. (There are two camps of opinion on that, obviously, but chacun à son goût, as they say.) Presently, to make cues invisible in the score without leaving totally blank measures in their place requires putting the cue into a separate voice, and leaving the whole-measure rests in Voice I visible.
At some point, all the extra work of kludging up the required visual result becomes a problem worth solving.
In reply to I don't see how to do that by Rémi Marche
And the list of all existing plugins (but also for older versions of MuseScore) can be found on https://musescore.org/en/plugins.
When you look for plugins working on 2.0.3, look for downloads that have a .qml-file in them. The .js versions are for 1.x only.
In reply to And the list of all existing by jeetee
OK, Now I understand. Thank you!
The one thing that I notice that doesn't look right in that example with cues, and that hasn't been addressed in the thread, is that the measures with the cues pasted in are missing the bar rests.
When we have an oboe part, for example, and after a long multi-rest, there are a few measures with a clarinet cue before oboe resumes playing, that clarinet cue appears in one voice, but there are full bar rests in the other (either below, or above, depending on what is practical). MuseScore needs a lot of manipulation in order to pick a source for the cue (clarinet), paste it in the target part (oboe), make it small, make it not play in that part, hide it from the full score, and insert full-size rests in the second voice.
Commercial tools attack this problem in different ways, but tend to provide much greater automation of the process, leaving very little to adjust manually.
In the ideal world, one would be able to choose the threshold for the number of bars of rests (say, 8 measures in a normal tempo) above which the module for automatic insertion of cues would kick in. This might be some colour-coded highlight in the score at the spots that need cues. If I were to imagine the user interface for this, these colour-coded highlights would act as check boxes, which user could check (one or more, if the same cue goes into multiple staves) and then highlight the passage to be used as a cue, then activate the function "paste cue" (key combination, menu/toolbar item, etc). The application would then simply paste the cue into the selected staves in appropriate measures, make them cue-sized, send them to voice 2, hide them from the score and make uncheck their playback. If I were to make this truly ideal, these cues would behave as aliases, in that when the user makes a change to the original staff (clarinet), all cues derived from it are changed as well.
Having said all that, I'm pretty sure this is, as a challenge, beyond the feature list even for the big guys (none have a solution that automates the process as completely as I had described it here). But it would be really nice to have it.
I have seen too many scores / parts brought in front of musicians that don't have any cues whatsoever. They most often come out of Sibelius (or Finale), and those who prepared the parts simply didn't want to bother with cues. The value of cues simply cannot be overstated. They provide immense help to winds and percussions in a full symphony orchestra, where strings play through, and others count rests. It would save a lot of time to be able to automate the process of making them.
In reply to The one thing that I notice by Predragvasic
That's why the plugin exists. Read the discussion next time.
In reply to That's why the plugin exists. by DustyC7
Plug-ins are not always accessible for the mainstream user, who is not necessarily sufficiently computer-literate to deal with installing and running them.
And there is no need to be rude.
In reply to That's why the plugin exists. by DustyC7
It seems to me that you hadn't read my comment. The plugin referenced above is great for what it does, but doesn't come all that close to automating cues. You still must manually identify spots where the cues are needed, manually select source for cues (one by one), manually select destination (one by one), manually copy, manually push cue to the second voice, so that the full bar rests stay in the main voice.
I'm not that familiar with the internal architecture of MuseScore and it's APIs for plug-ins, but from what I've seen I don think a fully automated solution is possible via a plug-in.
In reply to The one thing that I notice by Predragvasic
I agree with everything you say except for the part about it being 'beyond' the feature list for the 'big guys' (meaning, I presume, Werner, Nicolas, Jojo, and Marc). I would not say that this is 'beyond' what they can do, but rather that due to the lack of staff and time, they have had to set priorities which prevent them from making the required effort to solve this problem.
In my world, cues are an essential element of most scores I produce, and I would truly love an automated cue feature that I could control through the UI in something akin to the manner you describe. But it is entirely possible that the bulk of (present) MuseScore users do not produce scores and parts for orchestral works, but rather are working on 'song-sheets' or scores for small ensembles, most of which do not require cues.
Unless and until enough MuseScore users manifest a desire/need for this function to 'move it up the list,' it will (unfortunately) remain a relatively low priority on their too-lengthy 'to-do' lists. The only other alternative is that someone with both the technical skill and knowledge to write code for the program and the need for cues in their own scores, will step up to the plate and do the grunt work to enable its incorporation into the next stable version.
Might I make a sort of 'Call to Arms' to those users who need a cue function to manifest their interest here, or even better, to qualified programmers willing to take this on? Having an elegant cue function would be one more reason for professionals to prefer MuseScore to 'the High-Priced Spreads' such as Finale and Sibelius....
In reply to I agree with everything you by Recorder485
You may have misunderstood me; when I said "big guys", I meant Finale and Sibelius. Neither has a proper, full support for cues, nowhere near the way I had described. Both have functional work-arounds that use additional voices / layers to insert cues into parts, but the procès is still largely manual. There is a plug-in for Finale that brings a certain level of intelligence into the automation, identifying automatically, based on preset criteria, spots that are good candidates for cues, as well as staves that are good candidates for source(s) for those cues, and allows the user to either let it do this completely automatically, or decide for each instance. The final result is still a kludge that essentially simply copies notes from one stave into another and adds a layer in order to display rests above/below the cue.
It is unfortunate, for users like me (and you) that a feature that could significantly improve our quality of life (by saving significant amounts of time) is a rather obscure one that few other users need.