Looks like the GUI implies the wrong thing with a ratio. When I look back in time at this same parameter - the GUIs of past do not show this parameter as a ratio but instead as a longer-string "EG Time Velocity Sensitivity". And the impact of non-zero values of the Time Velocity Sensitivity value is to make the segment(s) faster or slower which could be an offset (adding/subtracting). There's not the detail to determine the math here. Results would seem to indicate add/sub rather than mult/div.

I'm guessing that the english use of "/" to shorten a list was used rather than trying to imply a ratio. Although I've been thrown off by this before too thinking a ratio was implied.

Bad form for literal interpretations - but I'm guessing this is more of an offset which wouldn't respect "0" except that the limit is 0 so this would never be subtracted from. Only added to.

I'm not going to defend the latest choice of GUI terms to represent this value - since I admit the departure from the previous chosen nomenclature compounds the confusion. However, I can say that this is a parameter that hasn't changed through the years - so it's not a bug as much as possibly a "typo" or lack of reasonable documentation to avoid the misinterpretation.

Generally, the way this works is that if you hit a velocity of 127 then the segment(s) chosen will be sped up or slowed down by the value given.

Say you have an attack time of 0 and you set the Time Velocity Sensitivity to +63. This won't do anything since positive speeds up the time and and a time of 0 is the fastest already.

Say you have an attack time of 0 and you set the Time Velocity Sensitivity to -64. This says to slow down the attack segment - which can be done. If you hit with a velocity of 127 then your effective Attack will be 0+64 = 64.

The only other thing I can say is that when you actually do hit with the maximum velocity - it seems like the note "hangs" for a bit before the ramp starts. Almost like there's a pre-attack fudge factor of time that gets smaller as velocity is lower. Normally if you set the attack time to say 63 and level to 127 for an EG - the ramp starts right away after striking a key. However, the Velocity sensitivity seems to be also a way at high velocities that the attack "waits" to start the ramp. This is more pronounced as higher absolute values of Time Velocity Sensitivity ("Time/Vel" ). For me this also assumes the EG Depth is set to +20.

So roughly: Time[Segment(s)] = Time[Segment(s)] - ( (Velocity_Struck/127) * Time_Velocity_Sensitivity )
... and then some pre-ramp fudge factor at very high velocities.

So negative values of Time_Velocity_Sensitivity ("Time/Vel" ) would add to the time - which means make the ramp slower. And hardest velocity struck would be 127 which would yield 100% of the "Time/Vel" subtracted value where lower velocities would scale this back.

You can more easily hear what's going on with PEG and then apply the learnings over to the other EGs (assuming they act similarly).

That's just a rough map. I haven't really checked that the velocities ratio out exactly like this - but a close enough picture to run with.

What a shame...

Many things of this nature plague the Yamaha user experience, and some cost much time and output.

This one has a clear identifier of its oddness, thanks to many of the arpeggios using 100% velocity (and me being an arpist, not an artist), otherwise it's unlikely I'd have ever absolutely identified this as the source of peculiarity at the extremity of note velocities (velocities that it's not easily possible to play and isolate, only to program), causing much head scratching as to why notes were "dropping" or sounding soft, or like they were bowed when they shouldn't.

This behaviour isn't linear and is absolute at maximum velocity, hence my suggestion that the Attack Envelope Time values are the subject of multiplication. I suspect there's a n x n x n form of exponential easing going on.

Sadly, this means it won't be corrected, and the empowerment, expressiveness and truth of having a true zero value (and very small values) will never be realised in these envelopes. Nor the UI corrected to display any modicum of the truer nature of these envelope modifiers.

It's only because I've had many of these sorts of moments in discovering The Yamaha Way™ that I knew to look for this flummoxing behaviour in a possible misrepresentation and, having confirmed it to myself and isolated the oddness, to frame this as a question instead of simply calling it out as a bug.

It also helps that I've used both sides of software, and worked with many companies developing software and services at a level sufficient to see how this comes about, so know that this isn't unique to Yamaha.

Many other users have likely felt similarly when using Blender, Reaper, Sibelius, Maya, Unity, all things Adobe and even all of Windows itself, as their management likely also encourage treating users in this way. They bank on an extra layer of abstraction in their users, from their art, and expect some division and application of their creative resolve, resolution, ingenuity and forgiveness to be generously supplied towards both their tooling makers, who are somewhat absent a sense of responsibility for the user's time, energy, spontaneity, creativity, productivity and (most importantly as far as I'm concerned) flow states, instincts and joys.

… a shame for us all.
​

I hear you and would still encourage using PEG on a reasonably pitch-stable sample (element) to quickly discover how values relate to real-world time (not integer parameters without units) and how level and other surrounding/related parameters interact. You don't have to necessarily map out all permutations - but quick work can give you enough of a handle to at least gain a better feel of the system and reach somewhere closer to the right end of intuitive vs. perplexed (those are ends of a spectrum/scale - not anywhere you necessarily rest).

I completely agree that some hurdles could be removed by better user design. Not seeing that taking a 180 anytime soon - there are some things (quick homework) that can be done because not all is a black box thankfully.