Velocity: Offset vs. User — Paste issue

• Jan 8, 2022 - 03:52

When I copy/paste a note bearing a User velocity the pasted note gets a velocity type of Offset and its velocity = 0.

Is switching types as described a bug? If not, what is reasoning for this design?

UPDATE: It appears that User velocity is not commuted to the destination only when an individual note is copied and pasted to a rest.
Will keep an eye open.

I consider Offset velocity types more versatile in common usage because notes (with velocity type Offset) respond to dynamic marks—and that's a significant advantage

But I have a large library of MIDI files I created in sequencers, in real time, where performance velocity nuance was captured ... and refined if needed. The results have weathered the decades. So after importing to MuseScore I want to stay in the User velocity space. But with each paste I have to reset the velocity type to User and guess a good value.

There must be a less tedious workflow. I'm hoping I'm just in the dark here.

scorster


Comments

Are you literally copying and pasting individual notes as opposed to ranges? Indeed, normally, this preserves pitch only, by design - other properties like duration are maintained from the destination chord. Range selections will preserve all properties.

In reply to by Marc Sabatella

Marc wrote Are you literally copying and pasting individual notes as opposed to ranges?

Correct. No range selection involved. Sorry if I was unclear on that.

The behavior occurs when I copy a selected note, select a designation rest, and paste.

Marc wrote Indeed, normally, this preserves pitch only, by design.

I can see an advantage there, or more objectively stated, I see MuseScore's rather convenient approach that lops off any duration that exceeds the duration of the selected note. (Wish there was an override for that so I could paste the source duration if I wanted to!!)

But precisely what is the design intent behind always changing the velocity type to Offset on pasting an individual note to another note or rest? You can imagine, if I need to do a lot of small pastes like this, the need to reset the velocity type and guess a velocity value gets pretty tiring.

Do you recommend that I request and option for an Offset preserving paste?

A Paste Special dialog would do a long way in offering options to the user at Paste.

Thanks!

scorster

In reply to by scorster

Well, there is such an override - making a range selection.

The design isn't about velocity specifically but about the distinction between range and single/list selection the distinction between chord and note properties, etc. The design is that only pitch is assumed to be relevant when doing a single/list selection as opposed to range selection. The idea is that when going our of your way to copy and paste something other than a range, it's for a specific reason - that you want the properties of the destination to win out, but only take the pitch of the source.

I wouldn't personally be in favor of special casing velocity, to make it the on=e and only additional property copied. I'd rather understand the special use case that causes you to watch to copy pitch and velocity only but not anything else - in other words, why not simply make a range selection?

In reply to by Marc Sabatella

Marc wrote > >override [the default behavior] making a range selection.

But then I can only paste a range and clobber notes I want to preserve.

Marc wrote> >The idea is that when going our of your way to copy and paste something other than a range, it's for a specific reason - that you want the properties of the destination to win out, but only take the pitch of the source.

That's quite an assumption!

Also, I was not recommending special-casing velocity as the one-and-only property pasted. That would seem a quite narrowly aimed feature.

I was requesting the opposite: If by default MuseScores wants to covert User Velocities to Offset velocities, then a Paste Special dialog would show the user that this is the default and pending action and provide a way to opt out for this individual paste ... or perhaps include a toggle to make the new choice the user's "default."

Regarding use cases, I'll report when the situation is beguilingly before of me, probably tomorrow.

scorster

In reply to by scorster

Could you provide a minimal score showing your problem ?
Really a minimum one please, but that fully illustrate it, especially these two points : why isn't selecting your note as a range possible, and where in the inspector is the switched attribute ?
Thanks

In reply to by scorster

There is no “converting” of velocities going on here - that’s what makes it sound like you are talking about something unique to that property.

What happens is simple - a new note is created, using all default properties just as if you had entered it in note input mode, and then the pitch of the new note is taken from the copied note. No conversion of any sort - other properties of the source note are simply ignored.

If you have a special use case where it seems to make more to create a new UI for controlling which properties get copied - an expanded selection selection, say, that applies to single selections rather than ranges - feel free to propose a design and explain how it solves a real world problem more easily than existing tools like normal range selection. Then can begin to understand better and discuss the proposed feature further.

In reply to by Marc Sabatella

Marc wrote > >There is no “converting” of velocities going on here - that’s what makes it sound like you are talking about something unique to that property. What happens is simple - a new note is created, using all default properties just as if you had entered it in note input mode, and then the pitch of the new note is take ln from the copied note

Oh boy. Fair enough. My use of the term “Covert” inaccurately describes MuseScore's internal processes.

But I think it is clear I meant that I find MuseScore's exclusion of the velocity type frustrating when pasting single source note of type User. Hence my suggestion for a Paste Special dialog to provide an option to include velocity type on paste—along with note pitch (the default) and other properties left open to the users discretion. If Paste Special is on the horizon it would seem trivial to also include velocity type in the include/exclude lists.

Marc wrote > >No conversion of any sort - other properties of the source note are simply ignored.

Sounds like you’re saying pitch is the only conserved property on single note paste, meaning that MuseScore ignores all other source note properties. Is this correct and does the Handbook mention it?

Whatever the case, MuseScore has taken a more inclusive approach for pasted Range Selections, where many or all of the source note properties are infused into the pasted notes.

Surely MuseScore does so for good reason.

So why such a drastic distinction for single note pastes? That MuseScore preserves pitch on paste my seem odd to many, and what it discards may also seem odd or cumbersome.

Again, what’s the design principle for ignoring velocity type?

Marc wrote > >If you have a special use case where it seems to make more to create a new UI for controlling which properties get copied - an expanded selection selection, say, that applies to single selections rather than ranges - feel free to propose a design and explain how it solves a real world problem more easily than existing tools like normal range selection.

I expect to work on projects later today, and will likely encounter use cases if I work on a score with a MIDI file provenance. If so, I’ll post an example then.

In the meantime, here's the result of tangling with lots of pastes and resetting type and value so my score would contain notes that are 100% of User Offset velocity. Again, the reason for wanting the score to maintain User type velocities is my desire to preserve the velocities in the original performance, but this is at the expense of dynamic marks going zombie.

Best I can MuseScore offers no method for imbuing User velocities into Offset velocities score-wide, right? That would be an excellent option. Then I'd have the original expression and the option to employ dynamic markings.

https://musescore.com/user/35880724/scores/7370999

scorster

In reply to by scorster

Oops. That was a different rendition of the score with fuller accompaniment with melody for fiddle or mandolin.

The is the finger-picking version I meant to point to.

https://musescore.com/user/35880724/scores/7370435

Note that there's no way to opt out of the automatic compression that MuseScore imposes when generating the audio for MuseScore.com

The net effect of compression is that soft notes sound louder, so the subtitles are lost. So you'll need the original score if you want to hear. Presently I don't want to make the score downloadable on .com, but for a few days I'll leave a the score attached in an subsequent post.

scorster

In reply to by scorster

As far as i know there is no compression; maybe you are thinking of normalization? Relative volume levels should still be preserved. So there should be no difference whatsoever between the sound on musescore.com and locally that isn't completely equalized by simply adjusting the volume on your speaker.

In reply to by scorster

Yes, I am saying that pitch is the only property copied, but it seems I'm wrong - notehead is also, visibility too, not sure what else. Not sure what the Handbook says, but feel free to check and edit it to reflect the current situation.

In the future,more control could indeed be nice. But again, I don't think it would make sense to have velocity be treated specially. It should be something sufficiently general to handle other properties a user may or may not want copied. Most users probably never touch velocity, but they may well want control over notehead, or visibility, or color, or offset, or Play, or fix to line, or any other properties.

My point in asking for an example was to understand why you are copying individual notes rather than the more usual range selection. So what we'd really need is to see a very specific example that demonstrates that particular use case - which notes from which measures you are trying to copy, and why it doesn't work better to use ranges.

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