8vb guitar staff and its linked tablature staff lack velocity synchronization
It's been stated that non-synced velocities between linked staves are by design I'd like to understand the rationale.
Treble 8vb - Tablature -- No velocity sync.mscz
As expressed in the attached score, I'm not suggesting that MuseScore change the default behavior. But given the option I'd definitely chose synced velocities (between linked tablature and the linked standard notation staff ) and make that my preference.
I can't think of a situation where I'd want independent velocities—but if I did resort to that, for some unforeseeable reason, I'm sure lack of synced velocities and dynamics would come back to haunt me.
scorster
Comments
Maybe I'm missing something, but doesn't only one of the two staves play? Velocities on the other would seem irrelevant. But anyhow, it's certainly by design that most properties of notes are independent, to allow for any number of effects that would impossible if they were linked. This is very obviously important for visible properties like offset. But I could imagine it having value for playback settings as well, like if you want to maintain a "clean" and a "humanized" version of a passage. Still, I agree it's probably not that common - but also, again, just not relevant that I can see. Ultimately, I hope to see MuseScore add the ability to break links on demand, then we won't need to err on the side of independence so often.
In reply to Maybe I'm missing something,… by Marc Sabatella
Marc wrote >> ... doesn't only one of the two staves play?
Correct.
Marc wrote >> Velocities on the other would seem irrelevant.
Precisely my point. If you think audible changes on the "other" linked staff are irrelevant then I'd think Musescore would disallow independent changes to audible properties, or better yet Musescore would maintain them as linked!
Marc wrote >> most properties of notes are independent, to allow for any number of effects that would impossible if they were linked.
Certainly, for visual effect, I can see that property independence makes sense sometimes. But for audible effects?
Given that only one staff sounds, can you list, as you stated: a "number of [audible] effects that would impossible if they were linked"? And why would someone want to accumulate lots of such effects on a staff that makes no sound.
Do you see anything detrimental in having linked velocities on linked staves? Do you think that it would be overly limiting and impinge on scorist's work? What's the harm in having a non-sounding staff linked in terms of velocity and dynamics. It would certainly make sense if the sounding staff were ever deleted.
Does the Handbook offer a comprehensive list of what is linked/unlinked between linked staves?
Marc wrote >> I could imagine it having value for playback settings as well, like if you want to maintain a "clean" and a "humanized" version of a passage. Still, I agree it's probably not that common - but also, again, just not relevant that I can see.
Sorry ... I don't know what that means.
Marc wrote >> * I hope to see MuseScore add the ability to break links on demand, then we won't need to err on the side of independence so often.*
I interpret this to mean you're in support of everything being linked between linked staves, but the user should have the option to override the link between particular objects. And you state that musescore "err[s] on the side of independence so often"...
... but still, overall, you're opposed to my request for the option of linked velocities between linked staves??
It seems in this exchange you're for and against both sides of the argument.
scorster
P.S. I notice that Line objects behave as if "partially linked" that there's some kind of threshold where, on edit, the Line on the other staff conforms to the left point, right point, or angle. I wonder why the Line object's visual properties are not all fully independent? Have you seen this? Would you want an example score?
In reply to Marc wrote >> * ... doesn't… by scorster
What I am saying is, since velocity is completely ignored on the second, what difference should it make if linked or not? It's completely irrelevant except for the whatever special cases might exist where you end up later somehow separating the staves somehow (by copying/pasting elsewhere, or deleting one staff, etc). Only then does it matter at all whether the velocities were lined or not. I just gave some specific examples of why in those particular cases you might well want them not linked. To me, that's about all the reason there needs to be not to link them. It's completely irrelevant 99% of the time. The 1% of the time the difference matters, chances are good you won't want them linked. In the case where you do, it's easier to workaround this by making the same adjustment to both staves than it is to come up with workarounds to break links you didn't want (invisible notes etc). Which is why I say, again, until there exists a way to explicitly break links where desired, it's better to err on the side of not linking.
So yes, for all those reasons, I think the only logical conclusion is that it is better not to link them until such a time as it becomes possible to break links on demand. Again, 99% of the time it just doesn't matter. For the 1% of time it does, some of those cases you want them linked (maybe half, maybe not, who knows), the rest you don't. No matter which way the default is, you need a workaround for the other cases. We have no way of knowing which case is actually more common - both are probably so rare as to be insignificant statistically. But the workaround to manually duplicate the velocity info is far simpler than any possible workaround to force them different (and probably a plugin could automate the former completely). So to me that wins: regardless of which of those rare corner cases is actually more common, one is much easier to workaround than the other.
And yes, in the long run, I'd like to see a way to break links on demand. Once that happens, that that changes the equation - now it does become relevant to actual which of those rare corner cases is more common.
Regarding the example I gave that you say you don't understand, could you be more specific? By "humanized", I mean one where you deliberately fiddled with velocity to sound more human. It's quite common to want to do that - in fact, it's probably single most common reason by far to mess with velocities to begin with,
In reply to Marc wrote >> * ... doesn't… by scorster
BTW - no, the Handbook doesn't have an exhaustive link of which properties are linked and which are not, because that is an implementation detail that changes over time based on user feedback. Often suggestions for change lead to discussion that results in a change happening,. This to me doesn't seem a good candidate, though, for the reasons I've stated.
Let's say we just use TAB staff: it is necessary to be able to use velocity (and other) properties.
When two staff are together like here, which one is linked to which is a bit problematic. Because, if desired, notes can be entered only on TAB staff, and in this case, the note staff becomes a linked staff.
It is also not possible to disable either (adjustments in the inspector), because it is not clear in advance which staff the user can use to set.
Let's assume that the bottom staff is a child-staff and can somehow inherit properties from the top staff (set in the inspector). What will happen if we remove the parent (top) staff?
For this reason, making the adjustments in only one of them seems like the most sensible way to work at the moment.
In reply to Let's say we just use TAB… by Ziya Mete Demircan
Ziya wrote >> Let's say we just use TAB staff: it is necessary to be able to use velocity (and other) properties.
I absolutely agree: A stand alone TAB staff should allow edits to velocity and other properties. If later the user adds a linked staff (like a guitar 8vb staff) note velocities would be linked. Simple as that. (UNLESS, an overwhelming portion of Musescore users need and expect velocities to be unlinked. As I've already stated, personally I still can't see a compelling reason for unlinked velocities in this context, but I'm open to hearing what those might be. )
Ziya wrote >> Let's assume that the bottom staff is a child-staff and can somehow inherit properties from the top staff (set in the inspector).
When Musescore creates a linked tablature staff it initially populates that tablature staff with velocities from the linked standard notation staff. (And this leaves the impression that velocities are linked.) But henceforth no velocity synchronization exists between those staves.
This is parallel to the creation of Parts—Musescore populates velocities into the Parts at their creation, but velocity linkage then abruptly ends. And there's no option to enable linked velocities between a part and the main score.
Ziya wrote making ... adjustments in only one [staff] seems like the most sensible way to work at the moment.
Well ... unless the velocities between linked staves are linked. Which is what I'm recommending.
Ziya wrote What will happen if we remove the parent (top) staff?
I view the relationship/functionally as Linked. Not as Parent/Child. Many attributes edited in the tablature staff affect the linked staff, so in terms of functionality, I can't consider the tablature staff a child staff, or visa versa.
Regardless—with respect to velocities—removal of either staff would not be an issue if velocities between linked staves were linked. The user could invoke a velocity-safe removal of either staff because Musescore would preserve shared velocity values in the remaining staff.
I'd still like to hear arguments in favor of velocities remaining unlinked between Linked staves. For instance, what are the positive attributes of setting independent velocities on a tablature staff that makes no sound?
scorster
In reply to Ziya wrote >> Let's say we… by scorster
Of course, in order for both staff to be fully linked to each other, the value entered in one must automatically reflect on the other.
But in the current situation, you can put p dynamics on the upper staff and f dynamics on the lower staff. However, shouldn't the dynamic value entered in one be linked to the other? This suggests that they are not completely linked. // Suppose velocity values were not linked due to the special case of the inspector, but dynamics should have been linked automatically. Probably the only things linked are the notes and the length values.
I just tried to understand and show the current situation.
The problem is that both of them are active staff.
If TAB-staff were used as child-staff, it could easily inherit values from the other and use other properties unique to itself. By making the Note-staff invisible, it would also be possible to easily use it alone.
The same is true for the opposite case (TAB-staff is parent, note-staff is child-staff).
But they have set up their logic and programmed it as it is now.
It's not wrong, but it has its cons. Just like what I suggest has its cons.
In reply to Of course, in order for both… by Ziya Mete Demircan
Ziya wrote>> Of course, in order for both staff to be fully linked to each other, the value entered in one must automatically reflect on the other.
Right. I think the general rule would be notational and audible aspects would be linked; layout aspects should not, jut as scorists often want independent control over layout and object placement in players Parts.
Ziya wrote>> ... in the current situation, you can put p dynamics on the upper staff and f dynamics on the lower staff. However, shouldn't the dynamic value entered in one be linked to the other? This suggests that they are not completely linked. ... Probably the only things linked are the notes and the length values.
Clearly the staves are not fully linked. And I'm not asking that they be fully linked. I'd just like an option to have velocities linked (as a musescore preference, a score style, or a linked-staff property.) I'm not asking for anything more.
But I gotta say, independent dynamics also strikes me as odd too. Thanks for underscoring that!
Again I'd hope that the Handbook somewhere lists:
... otherwise we're just guessing, or running a mine sweep to reverse engineer for ourselves.
scorster
In reply to **Ziya wrote>> ** Of course,… by scorster
The Handbook v3.5 states on Page 112:
And on page 37 the Handbook states:
![Linked staff - Handbook Page 37.png]( "Linked staff - Handbook Page 37.png")
These statements are not completely true, and as far as I can tell there's no discussion of the properties NOT linked between Linked staves. I think some caveat is in order.
scorster
In reply to The Handbook v3.5 states on… by scorster
I found more references in The Handbook v3.5 regarding Linked staves so I've combined them here with the one previously mentioned.
• Musescore does NOT sync velocities and dynamics between Linked staves statements like "any change you make" should read "any notationally visual change you make." Because audible changes like velocity or dynamics are not reflected in the linked staff. (Granted, in the entry on page 122 I suppose the term "notation" obliquely excludes the audible.)
The point of this entire thread is that I think this is unfortunate, and not what the average user would expect. But it would be best if the Handbook described the way things currently operate.
• I also think the Handbook should explain that playback is governed by the uppermost normal staff, or when no normal staff is present, playback is governed by the uppermost tablature staff.
On page 37:
On Page 112:
Linked Staves
The staves are "mutually updating": i.e. any change you make to the notation in one staff is immediately applied to the other staff as well.
On Page 172:
The score window
Linked parts are presented as part tabs within score tabs, but currently, there is no way to navigate these part tabs using the keyboard. The parts would not normally contain information different from the score; they would just be displayed differently (each part on its own page)
On Pg 205:
Save parts
Parts and score are "linked", which means that any change to the content in one will affect the other, but changes to the layout will not.
COMMENT: The two simple notions expressed directly above (between the commas) are indeed apochryphal, and rub roughly against the use of the term “normally” on pg 172. The also echo what is said on page 37 and 112.
In reply to **Ziya wrote>> ** Of course,… by scorster
I think we need to look at a regular staff and a liked tab staff as two different ways to show, graphically, the same stream of notes. Each note is represented by a symbol on each staff (using two different notation systems).
It would be convenient to be able to make changes in most note properties - time value, pitch, velocity, etc.) on either "presentation" (which one we would work on depending on our "outlook" at the time). (This is currently so for time value and pitch, but not velocity.)
At present, when we play the score, it seems that the two staves are like two piano players playing the same notes on a single piano keyboard. (The fact that if we poke a note symbol on either staff, when play is not running, the note "toots" seems to suggest that.) But it is the velocities set for the regular staff notes than control the velocities with which the "doubly-struck" notes are sent.
I'm having trouble understanding the advantage of being able to set the stored velocity separately for the note symbols on both staves, given that the stored velocities for the notes on a linked tab staff do not do anything.
Best regards,
Doug
In reply to I think we need to look at a… by Doug Kerr
Doug Kerr wrote >> It would be convenient to be able to make changes in most note properties - time value, pitch, velocity, etc.) on either "presentation"
It seems I've burried the lead here, which was: "Why I want velocities synced between Linked staves."
So I'll try to clarity that desire, which Doug Kerr nicely stated:
When editing a Guitar + Tablature score I want to set properties where I’m working, whether I’m focuses on the normal notational staff or the tablature staff.
If I’ve been working in the tablature staff (making string assignments, copying and pasting between tablature measures, etc.) it feels natural to highlight numbers on the tablature staff and adjust their properties, including velocity. It feels so natural I’m concerned I’ll forget that in v3.6.2I should never make velocity edits in the tablature staff.
Similarly I fear that other users will haplessly bump into this peculiarity, particularly given the current statements in the Handbook.
Additionally, in recent disussion Marc stated it was feasible and wouldn't be too much trouble to add show/hide functionality in the Instrument window, making it possible for any Instrument's linked staves to be shown or hidden. I strongly endorse this, but then a user working with the normal notation staff hidden should know not to edit any velocities. Right?
That’s why I care if velocities are synchronized between Linked staves.
In reply to It seems I've burried the… by scorster
I don't follow that at all. Quite the contrary - if we ever support the ability to show/hide staves within an instrument individually, it becomes that much more crucial to maintain the ability to have their properties be somewhat independent. Far from saying the user should know not to edit any velocities, quite the opposite - the user should feel confident he can change velocities on the visible staff and it won't affect whatever other velocities he set on the on the other staff. unless he wants them synchronized, in which case, he can do so manually, perhaps via a plugin. Whether you want the same velocities on both depends on why one is doing the velocity modification, so the user needs to be in control of that.
In reply to I don't follow that at all. … by Marc Sabatella
I am still a bit confused.
The symbol for a note on the regular notation staff and the symbol for the same note on a linked tab staff (the fret number) are, to a human performer looking at the printed score, two ways to show the same thing (perhaps in a way parallel to the instructions for setting a watch in text vs. the instructions in pictures).
When we ask MuseScore to be the performer, and to play from the score (via MIDI, into a synthesizer), I don't know the exact logic used in the program code, but the note it causes to be sounded is, as to most of its properties, either the note described by the symbol on the regular notation staff or the note described by the symbol on the tab staff. Most of the properties of the note (those indicated by its visible properties) are the same for either representation. A half note is a half note. A C4 is a C4.
But the velocity property can be different for the two representations (they are to a great degree independent), which is of course the topic of this discussion.
In any case, the velocity property of the sent note is based on the velocity property of the regular staff representation of the note. The velocity property of the representation of the note on the tab staff does nothing.
Now we have recently heard that it might be desirable to continue allow (perhaps optionally) the velocity properties of the two representations to be different, mention being made that the scorist might want to do this for reasons of subtlety of the performance that will be done by MuseScore as the performer.
But there are two things I don't understand about that:
• Why would the scorist not want to apply those subtleties to the velocities associated with the representations of the notes on the regular staff?
• Hey - the velocities on the representations of the notes on the tab staff have no effect on the play performance by MuseScore. So I hope our imaginary scorist hasn't spent a lot of time on those subtleties.
What’s lacking in this discussion—and what I’d find helpful—is a hypothetical scenario that illustrates any benefit in having independent velocities between a the representation of a note on the regular notation staff and its counterpart on the linked tablature staff.
Thanks.
Doug
In reply to I am still a bit confused… by Doug Kerr
I quote from Marc:
"So yes, for all those reasons, I think the only logical conclusion is that it is better not to link them until such a time as it becomes possible to break links on demand. Again, 99% of the time it just doesn't matter."
But in fact, 100% of the time it doesn't matter, since the velocity set for the note's representation on the linked tab staff has no effect on the velocity of the sent note.
And in that case, the matter under debate devolves only to, "It is more convenient to be able to change the velocity of a note (as we can change most of its other properties) whether we are working on the regular staff or the linked tab staff".
I can find no counterargument to that. To the scorist who says, "I don't need that convenience", fine. Don't take advantage of it.
The counterargument proffered seems to be, "But some scorist might want the velocities different on the two staves. Again I ask, "What could be the point - the velocity on the tab staff doesn't affect anything. As near as I know.
Now of course if I am wrong as to the latter, then the story might look different.
Doug
In reply to I quote from Marc: "So yes,… by Doug Kerr
My two cents...
Starting from a single treble staff guitar score with notes entered, if one spawns a TAB staff via 'Add Linked Staff' in the Instruments dialog, information like time value. pitch, velocity - heck, even invisibility - is initially passed to the TAB. After that, links to certain things like velocity (and even visibility) are no longer in sync.
While working on the TAB staff, I can appreciate the convenience of adjusting a TAB note's velocity right there. After all, it's a score for a single guitar, so why wouldn't a velocity adjustment to a TAB note (which the Inspector allows one to do) get passed to the linked staff?
No one here is saying to change anything other than synching the velocity.
@Doug Kerr...
You wrote:
The counterargument proffered seems to be, "But some scorist might want the velocities different on the two staves. Again I ask, "What could be the point - the velocity on the tab staff doesn't affect anything.
You are correct that the velocity on the tab staff doesn't affect anything. It only has effect if the treble staff is deleted.
So... and this is kind of far-fetched -- one can imagine a version with customized TAB velocities, different from the treble staff, but only able to be heard when the treble staff is deleted!
Who would want such a thing?
In reply to My 2¢... Starting from a… by Jm6stringer
jm6stringer wrote >> Starting from a single treble staff guitar score with notes entered, if one spawns a TAB staff via 'Add Linked Staff' in the Instruments dialog, information like time value. pitch, velocity - heck, even invisibility - is initially passed to the TAB. After that, links to certain things like velocity (and even visibility) are no longer in sync.
Exactly right, jm6stringer.
jm6stringer wrote >> While working on the TAB staff, I can appreciate the convenience of adjusting a TAB note's velocity right there. After all, it's a score for a single guitar, so why wouldn't a velocity adjustment to a TAB note (which the Inspector allows one to do) get passed to the linked staff?
Correct again. Thanks for reflecting my points. Even in Musescore parlance the Instrument window shows the linked staves as ONE instrument. The Instrument's linked staves merely show alternate notational views for “this particular performance” on this Instrument. The concept of linked velocities follows in the that spirit. I see definite advantages to the requested option of velocity linkage (via a preference or score setting) and no downside, no one gets roped into it, and it only affest those who knowingly opt in.
Mainly I want the option of making any necessary velocity edits at my point of focus—TAB staff or treble clef—knowing that the alternate staff will update accordingly. And it seems quite likely to me that other users would appreciate or expect the same.
So I'd like to underscore: It’s not inconsequential that the tablature velocities do nothing—in fact it can be a source of great confusion. One is free to edit velocities in the tablature staff, but Musescore doesn't log that or use it in any meaningful way. Unless I'm missing something obvious.
** jm6stringer wrote** >> No one here is saying to change anything other than synching the velocity.
That's right. I've only requested for the option to sync velocities between Linked staves. There's never been a request to change the status quo default behavior, though I do think that would be wise eventually. But I've encountered staunch, and to me, largely incomprehensible opposition. It’s as if I’ve said, “I’d like to move the desk to the other side of the room?” And the exasperated reply is, “Not a chance. We can’t turn the entire building!”
As discussed, if a future version of Musescore allows us to show only a particular Linked staff and hide the standard notation ... THAT would be wonderful! But I don't see how such a feature strengthens any argument for unlinked velocities. Rather I think it destroys the argument. In a scenario where I've hidden the standard clef, and my view is entirely tablature, I can't effectively edit velocities (in a manner that impacts playback or updates other staves), so then ... I'm supposed to got to the Instrument panel, reverse the show/hide state, and change the velocity on the standard clef? Then unwind all that to get back to my preferred view of the moment? Really?
scorster
In reply to jm6strnger wrote >> Starting… by scorster
Regarding: "Mainly I want the option of making any necessary velocity edits at my point of focus—TAB staff or treble clef—knowing that the alternate staff will update accordingly. " - yes, that is indeed the one use case I can think of where the opposite default makes sense. But to me it doesn't outweigh the other use cases or the vast difference in difficulty of the workarounds.
In reply to Regarding: "Mainly I want… by Marc Sabatella
scorster wrote >> "Mainly I want the option of making any necessary velocity edits at my point of focus—TAB staff or standard clef—knowing that the alternate staff will update accordingly."
Marc wrote >> * - yes, that is indeed the one use case I can think of where the opposite default makes sense.*
Thanks for hearing that, Marc. That's the single point that I've been repeatedly tried to convey. And I think it is a significantly important case, and surely worthy of the effort required.
The request has only asked for an option. "Outweighing" anything else is not an issue.
scorster
In reply to jm6strnger wrote >> Starting… by scorster
Scorster wrote:
One is free to edit velocities in the tablature staff.
Yes, and my point about the Inspector allowing it (rather than having the 'Velocity' spin box being grayed out) makes me think any changes should be honored (synched)... again, here we are talking about a linked standard/Tab staff score for a solo guitar -- and not a Tab only score.
scorster wrote:
but Musescore doesn't log that...
It's logged, but not honored during playback. In fact, if the standard staff is deleted from the score, leaving only the Tab, then those logged values are used during playback.
...or use it in any meaningful way.
Well, one can create a linked standard/Tab score, enter velocities on the Tab staff which can only be heard by deleting the standard staff. (A kind of hidden, phantom version of the score, only discoverable by someone 'in the know'.)
Doesn't seem like a meaningful use. (To me, this is like Marc's clean/humanized version of an unsynched score.)
As to the matter of convenience:
We notation-centric folk all know that after entering notes, many fret/string numbers need to be changed, especially for playing at different positions on the neck. So, with one's present focus on Tabs, it would be convenient to also change velocity when needed without having to go to the so-called 'linked' notation staff. (I know, I know, it is linked -- but not for synched velocities. ;-)
Tab-centric users who may be entering string/number Tab data to produce standard notation may fall into the trap thinking that their velocity changes to the Tab will be honored upon playback.
In reply to I quote from Marc: "So yes,… by Doug Kerr
Regarding: "But in fact, 100% of the time it doesn't matter, since the velocity set for the note's representation on the linked tab staff has no effect on the velocity of the sent note" - you might be misunderstanding my point. The 99% of cases I mean are, the cases where the user has created two staves and intends to keep those two staves and to simply hit play and listen to the playback.
The 1% where the difference matters is the cases where you are planning on playing interesting like deleing on or the other staff, or changing the order of the staves in order to affect the playback, or copying and paste the contents of one of the two staves to completely different instrument, or - in some hypothetical future - where you've managed to hide one of the two staves or include only one of the two in a part.
It's that 1% of cases - probably far less than 1% of course - where the difference does matter. but in those cases, it's entirely non-obvious which would be the desired result in the majority of the time. but as I said, given the disparity in how hard the workarounds are, right now it's not even relevant to ask which of the two cases is more common, Only if we someday provide the ability to break links would that become and interesting question.
In reply to Regarding: "But in fact, 100… by Marc Sabatella
This is dizzying ...
And there’s no point in repeating the comment:
Marc Sabatella wrote >> 100% of the time it doesn't matter, since the velocity set for the note's representation on the linked tab staff has no effect on the velocity of the sent note"
I believe everyone hear understands the point—it was mutually confirmed in the first two posts. And it’s a cornerstone point made in the post/request.
Marc Sabatella wrote >> The 99% of cases I mean are, the cases where the user has created two [linked???] staves and intends to keep those two staves and to simply hit play and listen to the playback.
Your 99% case scenario seems to hinge around the concept—where linked staves are involved—of simply starting playback to hear the playback.
a) I think everybody wants to maintain that simplicity. It seems that you're suggesting that linked staves with synced velocities interferes with that?
b) Your were speaking of linked staves, right?
c) What’s the concern? 99% of time users want … What? They want x but linked velocities would supposedly quash x? What’s x?—that linked staff velocities would be heard? (But with the velocities linked, only one staff plays, sothere’s only one velocity to hear, so that can't be it.) You're saying that velocities must be unlinked to preserve the option of having or doing what?
Regarding your “far less than” 1% cases
a) I can’t parse the middle of the first sentence: planning on playing interesting like deleing on or the other staff
b) You wrote changing the order of the staves in order to affect the playback. You're saying that the order of the staves (presumably in the Instrument panel) affects playback? If so, the order affect playback … in what manner?
Is that documented somewhere? I just created a non-tablature linked staff scenario, changed the order of the staves, and heard no difference. What am I missing?
Linked Staff order and unlinked Velocities.mscz
c) I’d like to understand b) before digging further in to the 1% arguments.
scorster
In reply to This is dizzying ... Marc… by scorster
I'm not quite sure how this become so complicated. To me it is quite simple. So let me try to start again:
For 99% of uses cases, it simply doesn't matter. People will edit velocity on the top staff, and get exactly what they want. For these literally does not matter in even the slightest bit if the velocities are linked or not. Do the normal thing, get the normal results, each and every time, no worries about what happens in the unusual corner cases.
With me so far? Most of the time it doesn't matter in any way shape or form. It isn't a problem for 99% of users now (as evidenced by the fact that I can't remember a single other request for this feature, ever). It wouldn't be a problem for 99% of users if it changed (I'll take this on faith, without evidence, although it's certainly possible there are more than 1% of people relying on it now - just unlikely in my opinion).
So, let's move on to the 1% (almost certainly far less) of cases where it does matter, then. Those are the cases where for whatever reason people start messing with playback properties on the bottom staff, and the behavior will obviously differ depending on whether the properties are linked or not.
Some people might mess with playback properties on the bottom staff deliberately, because they want independent control for reasons such as ones I've stated or others that haven't occurred to us. In those cases, it's great that they can have it. If the playback properties were linked, they'd be out of luck with only very cumbersome workarounds at their disposal. So for the people who choose to deliberately set the properties of the bottom staff, it is essential that they be independent.
Other people might start messing with velocities on the linked staff accidentally, because they have forgotten or failed to realize that nothing about the bottom staff of a pair is relevant to playback (not velocity adjustments, not "play" settings, not dynamics set to "staff" range, etc). And in those cases where people make this error and try adjusting the adjustment to the wrong staff, they will normally realize it had no effect, and hopefully figure out why, make the adjustment correctly, and get on with their lives. So it's harmless.
Now, it is certainly true that changing this property to be linked by default would serve as a sort of crutch, saving people from having to remember to make the adjustments correctly. Thus it would offer a slight convenience to these people. But it comes at a high price - really messing up the experience for the previous class of people who relied on the independent control
That is why to me the right answer is, leave the default alone until such a time as it becomes possible to break links on command. Then I would absolutely agree it might help "idiot-proof" the experience for people who might have otherwise made the mistake of adjusting the playback properties on the wrong staff.
In reply to This is dizzying ... Marc… by scorster
Sorry for the typo in one of the previous posts - "planning on playing interesting like deleing on or the other staff" - insert the word "games" after "interesting", and it should have been "one or the other" not "on or the other".
Regarding changing the order of the staves - it is the top staff that controls the playback, but this determination is only made when the score is laoded, apparently. I'd call that a bug. In your example, after switching the order, try saving and reloading. Then you get the correct results.
In reply to Sorry for the typo in one of… by Marc Sabatella
Hi, Marc,
You say:
"Regarding changing the order of the staves - it is the top staff that controls the playback, but this determination is only made when the score is laoded, apparently."
Tests done here suggest that, when we have a regular notation staff and a linked tab staff, and have moved the tab staff to be on top, and t4ehn save the score and reload it, then the note velocity properties on the regular notation staff affect playback, whether those velocities are placed on either staff before or after the interchange of the positions of the staff, or before or after the score has been saved and reloaded.
What am I missing here?
Doug
In reply to Hi, Marc, You say: … by Doug Kerr
I'm not sure what tests you mean, but if you try this with the score attached to the post I was responding to, I promise it works exactly as I said. When you first load the score,e it plays very quietly because of the -70 velocity offsets. Reverse the staves and it still plays quietly because of the bug. Save & reload, now it plays loud.
In reply to I'm not sure what tests you… by Marc Sabatella
This should do.
Doug
In reply to This should do. Doug by Doug Kerr
Somehow there seems to be a bug in that file, somehow the bottom staff seems to be "winning". Not sure why, but it works as described in the other one.
In reply to I am still a bit confused… by Doug Kerr
Indeed, I do think you may be confused, but I'm not sure about what, so that's makes two of us :-)
Anyhow, you wrote:
"What’s lacking in this discussion—and what I’d find helpful—is a hypothetical scenario that illustrates any benefit in having independent velocities between a the representation of a note on the regular notation staff and its counterpart on the linked tablature staff."
This is exactly what I explained in my very first response here:
"I could imagine it having value for playback settings as well, like if you want to maintain a "clean" and a "humanized" version of a passage"
That's but one example off the top of my head.
In reply to Indeed, I do think you may… by Marc Sabatella
Huh?...Is this what you consider a benefit of having independent velocities?...
Marc wrote:
I could imagine it having value for playback settings as well, like if you want to maintain a "clean" and a "humanized" version of a passage
OK...
So I have a solo guitar score with standard/Tab linked staves. I make a 'clean' version by setting velocities on the standard staff. A 'humanized' is made on the Tab staff by setting different note velocities there.
Playback only plays the 'clean' version.
Once that 'clean' version' -- i.e, the treble staff -- is deleted, only then can the 'humanized version' be played at all.
Hmm... Can you think of another off the top of your head?
In reply to Marc wrote: I could imagine… by Jm6stringer
For what it's worth, if we use the Piano Roll Editor to change the velocity value of a note on any staff, the change is also applied on all staves linked to that staff.
So far as I know we cannot change the velocity type (Offset vs. User) in the PRE.
The same is true of playback start times ("Positions") and durations.
Doug
In reply to For what it's worth, if we… by Doug Kerr
I reported:
>>For what it's worth, if we use the Piano Roll Editor to change the velocity value of a note on any staff, the change is also applied on all staves linked to that staff.
That is just incorrect. As far as I can tell, changes made to the note velocity on one of the linked staves, using the Piano Roll Editor, are not applied to the other linked staff(s).
I have no idea where I came up with this bum steer. Perhaps it came to me in a dream.
My apologies for any confusion this incorrect information might have caused.
Doug
In reply to Marc wrote: I could imagine… by Jm6stringer
Not just deleting, but changing the order. One could use this for more than just tab - one could use it for two standard staves, for instance, to customize playback of a piano or other score.
In reply to Not just deleting, but… by Marc Sabatella
Marc...
You wrote:
Not just deleting, but changing the order.
Try with this:
Linked.mscz
Only by removing the treble staff from the score can the Phantom score be heard.
Windows 10 MuseScore 3.6.2
In reply to Marc... You wrote: Not just… by Jm6stringer
See my comment above. There seems to be a bug where the order change doesn't take effect until you save/reload.
In reply to See my comment above. There… by Marc Sabatella
We're talking about synced velocities between linked staves here. Regarding reordering staves to affect playback, bugs, etc. let's bring the bulk of that discussion here.
Thanks!
scorster
In reply to Regarding linked staves,… by scorster
I've commented on the historical curiosity angle there. But it won't affect this discussion in any way whatsoever.
Bottom line:
MuseScore currently has a feature in which note properties can be set individually for linked staves/parts. This has a number of uses, whether any individual person happens to want to use that feature or not.
I will not support removing this or any other feature without a replacement.
We've been down that road too many times before - removing a feature for reasons that seemed good at the time, only to get criticized later and regret it. And in this case, there isn't even what appears to be a good reason.
So again: I will not support removing this or any other feature without a replacement. Period.
It's really that simple. I don't think I can possibly express it more clearly.
In reply to Not just deleting, but… by Marc Sabatella
Throughout these discussions I agree with jm6stringer and I appreciate that he has clarified a couple of my points.
Please see the second b) comment in the post above
In reply to I think we need to look at a… by Doug Kerr
Doug Kerr wrote, "I think we need to look at a regular staff and a liked tab staff as two different ways to show, graphically, the same stream of notes. Each note is represented by a symbol on each staff (using two different notation systems)."
Totally agree. This seems to me to be the best approach and is implemented in both Guitar Pro and TablEdit. Any other approach would be confusing. Fortunately I only use TAB so don't have to cope with linked staves.
In reply to Doug Kerr wrote, "I think we… by yonah_ag
Doug Kerr wrote > I think we need to look at a regular staff and a liked tab staff as two different ways to show, graphically, the same stream of notes.
yonah_ag wrote > Totally agree. This seems to me to be the best approach and is implemented in both Guitar Pro and TablEdit. Any other approach would be confusing. Fortunately I only use TAB so don't have to cope with linked staves.
==================
Here are use cases of particular significance (assuming that MuseScore aims to be the notation application of choice for tablature oriented scripts, which would garner a huge audience!)
To set the scene, imagine a scorist starting with MuseScore's built-in Guitar + Tab template, and also that this scorist prefers adding notes via the tablature staff. There's no problem with this initially, but:
1) If at any point the scorist carefully edit velocities in the tablature staff none of those velocity edits are back-synced to the Treble Staff, and in this manner Linked staves get out of sync. (One could argue, "Well, just edit velocities in a Part"—but we have the same velocity link/sync issue there as well.)
2) In another scenario, the scorist prefers entering notes and editing properties on the tablature staff (perhaps because they aren't fluent in Treble Clef) and once the score becomes large the scorist chooses to hide the Treble Clef to see more systems per page. (Well, sorry. Currently we don't actually have the option of hiding staves within a system, but it's been discussed favorably.) So, in the future, if the scorist achieves such a configuration, and is aware of the sync issues he or she must show the Treble Clef just to effectcly edit a velocity—in a manner that actually affects playback. Then to get back to the desired Tab-only work view the scorist has to hide the Treble Clef. Ouch. (Again, generating Parts would solve this issue by eliminating unwanted staves from view, but there's no option to have a separate Part for the Treble Clef and the Tablature. But even if Instrument staves could have their own Pars, there's still the Parts sync issue ...
3) The scorist simply doesn't know about velocity sync "non gratis" (to date I think it's unmentioned in the Handbook) and haplessly the scorist proceeds under the mistaken impression that it's okay to edit velocities in either staff. And a particular flavor of disorientation may ensue—because velocity edits work when made in the standard staff, but not when made in a linked tablature staff—leading to the questions: "Why do velocity edits only sometimes work?"
scorster
In reply to Doug Kerr wrote > I think we… by scorster
scorster.
A very nice synopsis. Thanks.
Doug