stemlet (stems over rests)
Musescore currently allows beams over rests, but I would like additional ability to toggle "stemlets" for these beamed rests, which are short stems that are connected to the beam but do not reach all the way to the rest (image from http://micrologus.retmusic.com/tag/stemlet/):
This helps out in rhtyhmically complex music such as odd time signatures (where the beaming helps to delinate the rhtyhmic subdivision) or heavy syncopation (where it may be hard to determine where each beat starts).
For ui, I would say need a checkbox setting in rest inspector for "stemlet". Some way to control globally would be nice (maybe setting template, xml, or ini). Maybe the beaming ui could be enhanced to allow controlling stemlets (in addition exposing option for beaming of rests), so that user doesn't have to manually set the beam properties for each rest.
Additionally, would need to ensure sloping of beams works properly when rests are involved. I notice that currently if I have a rest inside a group of notes connected by a beam, then layout currently forces the slope to be horizontal:
But in that case should be sloped (depending on the rules):
Comments
The beam slope is already fixed in the current code - I guess your example above was generated with 2.0.2 or you'd see it. See #53271: Rests under a beam: beam should retain slope, rests should be moved to fit
I've never seen these "stemlets", but if they are really a standardized thing not a one-time invention of some paritcular editor, then sure, this would be good to add.
Thanks for informing me that the beamed slope has been corrected.
I've encountered them in handwritten charts. For editors, seems Sibelius 7 supports them (http://www.sibelius.com/products/sibelius/7/special_notations.html) and Lily Pond (https://searchcode.com/codesearch/view/20029983/), Finale has "half-stem" (http://www.finalemusic.com/usermanuals/finale2012win/Content/Finale/IDD…), and I found this comment for MusicXML here (http://forums.makemusic.com/viewtopic.php?f=12&t=2280)
Well, by "editor" I meant a person, not a software program. That is, I am wondering if that actually happens on a regular basis in real published music, or is it something one particular publisher did for one particular score. I guess Michael Good's comment suggests the answer is that it *is* indeed becoming common.
"editor" :)
I don't know if is in older published music. But I have seen it in (handwritten & typed) charts that I've played on.
Probably is a recent invention, but does seem to be somewhat commonly used. Enough that musescore should at least keep up.
This formatting technique is used in a published John Mackey piece I'm currently playing—along with triple dots.
On the other hand, the same editor forgot to add a time signature to the beginning of the piece (though it's obviously in common time.)
I'm making a note here that I think #52151: "Auto" beam setting for *Rests* should not beam (if no stemlets) should probably be aware of stemlets such that "Auto" beam setting should beam rests according to time-signature definition if stemlets are being used, but should not beam rests if stemlets aren't being used.
Also, if user clicks "Reset beam mode" when a stemlets mode is engaged, then I think the beams for the rests should be set to "Auto" and beam the rests.
However, we still need to figure out how the ui will be for stemlets. Could be either a global setting or a per-rest setting. (Maybe if expose the beam setting for rests, then setting a stem for a rest would mean stemlet).
I have seen stemlets used on several occasions in typed published music, namely in a piano piece called "Presso" by Denis Dion (a Canadian composer) as well as in Wyschnegradsky's 24 Preludes in Quarter-tone System (ed. Belaieff).
In the latter, the melody is very often passed between the pianos, since they are tuned a quarter-tone apart, hence the importance of the stemlets over the rests to keep track of the melody's rhythm.
I am currently working on a composition for two pianos tuned a quarter-tone apart similar to Wyschnegradsky's preludes, so the implementation of stemlets wouldn't hurt.
In reply to #5 by Isaac Weiss
He is his own editor, and self-publishes. I wouldn't use John Mackey as an example for good engraving in any universe, especially on stemlets.
In reply to He is his own editor, and… by Justin Tokke
Welcome to MuseScore. I look forward to your contributions.
Wow, I should have known that this is the question that would make MET/MES start bleeding into MuseScore. Welcome, Justin!
I'll add a situation where stemlets improve clarity, and where [I believe] they should be used by default:
This notation does not indicate the time-value of the rest in the beam, which it should to improve readability. You can manually add a 16th-note beam from the symbols palette, like so:
which is an improvement, but the unattached stem beam isn't really proper. This is the desired notation:
Here's an example with syncopation. Which is more readable?
The one on the left.
I would really love to see this feature. I oversee more than 1000 contemporary music score submissions per year, and I can say with confidence that not only is the requested stemlet feature—along with the existing beam-over-rests feature—is not only widely used, but indeed is an emerging standardized way of clearly defining beat groupings
In reply to I would really love to see… by datramt
I can only confirm that this is indeed the case. As a contemporary composer myself, I often employ this manner of writing. It was pretty much a defacto standard for writing complex rhythmic subdivisions already when I studied composition some 20 years ago. It might be that contemporary composers, with all their specific notational needs, are more likely to use admittedly more capable programs such as i.e. Finale and Sibelius, and thus are less visible in the MuseScore community. I would still urge the developers to implement this. MuseScore, though lacking in some specific areas, are still a much more modern program – not the least GUI-wise – than, say, Finale. It has a lot of promise and are truly worthy of a feature like this!
Attaching a snippet from the Elaine Gould notation-"bible", Behind Bars... [GOULD, E. (2011). Behind bars. London: Faber, p.165.]
Workaround is to use an invisible note with the 'Play' checkbox unchecked in the Inspector. Set beam to 'custom position'. Add rests in Voice 2.
Hack:
Result:
You can make small positional adjustments to the rests or invisible notes to ensure that the stemlets are centred directly over the rests if desired.
Related to #311175: [EPIC] Engraving issues and suggestions
In reply to Workaround is to by shoogle
Thanks Shoogle, but this seems much too arduous and time-consuming. Having just moved from Sibelius, I was hoping to leave such frustrating 'work-arounds' behind. Percussion and drum set notation often features 'stemlets' when beaming over rests. Is this a particularly difficult feature to code I wonder? Other than this, I'm so far very impressed with Musescore.
Arduous or not, it is nevertheless a workaround. If it wasn't arduous then it arguably wouldn't be an issue in the first place.
In reply to Arduous or not, it is… by shoogle
As a contemporary composer and professor of music composition, I'd like to support this addition. This is becoming a de facto standard in complex rhythmic notation in post-serial music. It started with composers such as Elliott Carter trying to clarifying their notation in more "pointilistic" passages. I tell my students who use MuseScore to use the "hidden voice 2" workaround, but having an option in Inspector to activate "stemlets" would be really great and a real time saver. Thanks!
This would be indeed a real time-saver, I use stemlets a lot and for now I also do the hidden voice workaround.
In reply to This would be indeed a real… by Gabriel Araújo 9
A good number the the members of the composer's group I belong to (NYCC) use stemlets. They make for easier reading, especially when attaching the rest to it's sub-beat in the hierarchy. I'd consider it a necessary feature.
In reply to A good number the the… by paljian
But there is (still) a workaround if you read further up.
Please Musescore team,
implement this feature! thanks!
Yes, please do implement it. I see so many composers using it, and it makes a lot of scores (and parts) a lot easier to read. The workaround produces acceptable results, but it's something that can go on for bars and bars in multiple parts, so it becomes hugely time-consuming.
How goes this threat?
The internal development team will not be working on this for MuseScore 4. If a community member wants to take it up then they are welcome to do so and we will provide design support.
In reply to The internal development… by shoogle
Mabye add it to the list of features for 4.1 then?! It would appear to be useful and needed by some.
Sorry - although I have programming experience, I doubt that I can do much with this particular issue. It would be easier for people who know the workings of the MuseScore system - and the language and coding standards used.
Having this feature would definitely be a help to me. I'm going to try using the workaround, but I'm not sure how well it will work. I personally would use this feature all the time.
Probably should get moved to GitHub
In reply to Probably should get moved to… by Jojo-Schmitz
> Probably should get moved to GitHub
I wonder. Which feature requests should be in this Bug tracker, which one should be in GitHub ?
The same for issues.
Is there any rule for this ?
This issue tracker here is being discontinued.