Snap To for glissando
Currently, it is possible to adjust the size of an arpeggio manually (not glissando, seemingly), but I think it would be better if it snapped to notes, instead.
This way, MuseScore will know how to process playback, layout and export.
For arpeggio, it would be applied to an entire voice - upon adjustment, it would spread to others and staves.
Glissando would function similar, except that you adjust what note it directs to, if there's multiple.
Both could be controlled akin to objects in Lines (e.g. ottava).
See original topic .
Using MuseScore 2.0 Nightly Build (06153cf) - Mac 10.7.5.
Comments
You could also control which forthcoming element (?) the glissando directs to.
Looking at keyboard 3 in this example, there appears to be hidden rests, but the glissando carries through to the next note:
It could also be used to control this?: #7662: Ability to add a glissando to an unique note
See this .
There has been a pull request for another issue, but both the latter and this are related.
See published examples for glissando:
#17351: Anchoring the ends of a line to two notes
Maybe both issues are related somewhat.
I don't currently know if it's proper notation, but I noticed this .
Pull Request with fix pushed to github: https://github.com/musescore/MuseScore/pull/2155
Please confirm that it does indeed fixes the issue, as I have only dealt with glissandi, not with arpeggios (which however do not seem to be actually discussed in the posts)
in ad30256 for 2.1 AKA master
and 11b8af8 for 2.0.3
Hi guys
Jojo: I think only glissandi may have been dealt with.
Miwarre: I didn't include arpeggio examples since I thought people would know about them, as opposed to the slightly rarer glissandi ones, but it might have been a good idea.
Cross voice:
Cross stave:
OK, I may have interpreted too much into a remark in https://musescore.org/en/node/86716#comment-382671 then
welcome back BTW ;-)
Thanks Jojo - it was just a quick post to address things, since I felt the issue was important (compared to some others, I suppose) and didn't want it to be missed, incase it was ever to be implemented.
Sorry but, as far as arpeggios are concerned, I do not understand in what the previous implementation, as well as the current one after this fix, fails short and which needs should be addressed in addition. The supplied examples can be reproduced with MuseScore 2.0.2 (and probably with earlier ones):
NOT FOUND: 1
An arpeggio cannot but apply to the whole chord it is attached to, it is not attached to specific notes, as glissando does.
I just checked using the latest stable version:
When dropping the arpeggio onto voice 1 and using Shift and Down, it works for cross stave, but not multi voice. Are you using the same steps?
Regarding your last sentence, can you clarify what you refer to by "chord" (arpeggio is applied to one voice, which can 'snap to' others in the stave, if desired, or all notes in a stave regardless of multi-voice)? I would prefer control by each voice - here's a published example in which two synthesisers share a stave:
Using MuseScore 2.0.2 - Mac 10.10.5.
A chord is all notes that occur at a given time position in a single voice, so the example in #13 is exactly how things already work.
I too am confused about the creating an arpeggio that spans chord in multiple voices, as shown on beat 3 of the second example in #12. I don't see how to create that except by adding the arpeggio in one voice than manually extending the visual appearance but not the actual attachment to make it appear to cover both voices. That's OK for now as a workaround, but it's not really the same as true multi-voice arpeggion support. Unless there is a way to do that I am unaware of.
@MarcSabatella: in #12 I just replicated with MuseScore the examples provided at #9 to show that they can be done with MuseScore. And yes, I dropped an arpeggio sign on a chord (namely, in beat 3 of the second example, on the chord of voice 2) and dragged its upper handle to encompass the note in voice 1 too.
If this is not enough, can you please elaborate a little about what you mean by "true multi-voice arpeggio support"?
At any rate, applying to arpeggios the technique used for glissando 'snapping' to note is not possible: glissandi use lines and lines cannot have a 0 tick span as arpeggios do. So, a different approach is needed.
In fact the two aspects, glissandi and arpeggios, are two rather different issues internally, their 'surface appearance' notwithstanding.
My suggestion is that:
1) A new issue is open referring specifically to arpeggios (in which case, it would be better to keep there any further discussion about it).
2) This issue is closed as fixed.
Thanks,
M.
If you dragged the upper handle, it was still logically attached to the bottom chord only.
The dotted line makes it clear the arpeggio is not *really* covering the voice 1 chord. That's what I mean by "extending the visual appearance". It's kind of the equivalent of extending a volta or hairpin or other by dragging rather than using Shift+Right - it looks right for now, but isn't really. In the case of the arpeggio, it means the playback won't be right, and it also means if you change the pitch of either the top or bottom note, the arpeggio won't automatically adjust properly..
To me, "true" support would mean a way of specifying the top and bottom note or chord for an arpeggio. I guess some would want to literally specify any particular note to be the top and bottom, so an arpeggio could cover just notes 2-4 of a five-note chord. I agree with the idea this is overkill. So instead of literally specifying the top and bottom *note* of the arpeggio, I think it would suffice to record a "track2" for the arpeggio and the semantics would be that the arpeggio would be assumed to cover all notes from the chord it is attached to but also all notes in all voices between that and the chord in track2.
@Marc Sabatella: ok I mostly see what you mean, but IIUC your description seems the opposite of your example: the arpeggio is attached to chord in voice 2 and it would be necessary to record a "track 1" (actually track 0) to cover all those notes. In practice, the arpeggio would be attached not to a single chord, but to two, a top chord and a bottom chord, possibly coincident.
Anyway, I still believe this to be quite a different issue from the glissando issue and the two issues should have been split since the beginning. So, I still suggest to:
1) Open an issue specific for the arpeggio
2) Close this issue as fixed
I agree the arpeggio issue is sufficiently different than the glissando issue (and more minor) so that this should be closed and a second issue opened if it is felt important.
My use of the term "track 2" was meant to mimic how it is used in spanners. All elements have a "track" member that records the track the element lives in, but spanners also have a "track2" member that records the track of the end point, if different from the start point. In my example, the arpeggio originally lived in voice 2, So "track" would start off as 1 (because tracks are 0-based). For an arpeggio like this that crosses voices, we'd also record the "end point" by setting "track2" to 0 (for voice 1). It wouldn't actually matter which track was which - the layout code would presumably draw from the highest to lowest note. But since the arpeggio was originally added to track1, I assumed it would stay there even if either handle was dragged elsewhere. Whatever makes sense implementation-wise; could be something entirely different. Like simply recording the top & bottom notes themselves, although it would be more work to keep this in sync.
Understood! (At last...)
Automatically closed -- issue fixed for 2 weeks with no activity.