Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Velocity is backwards #389

Open
sense-amr opened this issue Jan 26, 2019 · 83 comments
Open

Velocity is backwards #389

sense-amr opened this issue Jan 26, 2019 · 83 comments
Labels
Breaking Change In order to close this issue we need to make a breaking change (no backwards compatibility) Feature Request New feature request UI Issues related to UI look&feel UX Issues related to user experience (UX) - mouse, touch, keyboard, MIDI inputs, etc.
Projects
Milestone

Comments

@sense-amr
Copy link
Contributor

sense-amr commented Jan 26, 2019

Velocity .. its a tool many musicians use to "express" the note in more ways than just ON/OFF... it typically allows a musician to vary the volume of the note .. and most Daw's support the function of allowing a note velocity .. to which the Synth then responds via .. whats commonly refered to as "Velocity Sensitivity" ..

In surge this is functioned by the Slider next to Gain in the AMP EG section .. as pictured below .. it is labeled "Vel"

vel <---

Typically 100% ie, Vel slider being all the way up referencing in the case of surge 0.00dB .. would mean the user has the Highest amount and thusly MOST velocity sensitivty from a note in a DAW sending velocity information ..

In the case of surge as referenced from the manual we have .. a difference case..
It's backwards..

velmanual

As mentioned above and also noted (pardon the pun) .. by several users on the Slack ..
It is expected that velocity = 100% sensitivity rather than "Neutral" .. at Full Vertical deflection of the Vel slider..

I propose that we have this ammended.. in the interest of very easy and functional use of the Velocity response capabilities that i know Surge .. truly has ..

NB: I have provided some testing Proof that the velocity response is infact backwards to what people would normally expect.. in the following bitwig file .. for your own testing purposes..

sense_surge_VelocityTest.zip

@esaruoho
Copy link
Collaborator

esaruoho commented Jan 26, 2019

@baconpaul imho, any change like this should be configurable in the settings menu. Because, there will be people who have built presets and whole songs based on Surge working one way, and if this, second way, is implemented, all their tracks will break.

@sense-amr
Copy link
Contributor Author

incidentally the Patch reference for this i believe .. is
<a_vca_velsense type="2" value="0.000000">
in the FXP file ..

@sense-amr
Copy link
Contributor Author

I have to say i think this is a reasonably important thing to address as it has already been noticed by several casual users of Surge .. and although i would highly doubt many of the existing preset included patches even vary this value <a_vca_velsense type="2" value="0.000000" .. there might be some who do and who want to use Velocity sensitivity to add expression to their patches.. and for those .. who do it should be allowed in a normal way that is typically 100% Vel = 100% Velocity sensitivity.

@kzantow
Copy link
Collaborator

kzantow commented Jan 26, 2019

@esaruoho there would be a migration so existing patches sound the same, just with the updated behavior

@sense-amr
Copy link
Contributor Author

sense-amr commented Jan 26, 2019

@kzantow which is pretty easy right ? running a script on existing patches with regard to <a_vca_velsense type="2" value="0.000000">

and shipping further builds once Velocity is ammended in the code.. with those ammended patches too.. right? thusly removing any need for any fear of patches breaking that are "old" which are now .. not old..

@esaruoho
Copy link
Collaborator

@esaruoho there would be a migration so existing patches sound the same, just with the updated behavior

i don't see how this doesn't ruin songs made with user-defined Surge sounds saved into the song and sounding a specific way..

And let's not forget, we have no control over Surge preset packs that were made with Surge 1.52 on mind. what happens when you load those preset packs in, and the patch does not sound like it should?

@sense-amr
Copy link
Contributor Author

<a_vca_velsense type="2" value="0.000000"> that doesnt exist in a FXP on surge 1.52 presets?

@sense-amr
Copy link
Contributor Author

sense-amr commented Jan 26, 2019

and it kinda makes Zero sense that you cant "access" Surge 1.52 presets @esaruoho because all you need to do is load it then save it again and you have an FXP..

and if someone wants to furnish me with a list of such "Surge 1.52" patches.. ill happily "convert" them to 1.6 patches

@esaruoho
Copy link
Collaborator

and it kinda makes Zero sense that you cant "access" Surge 1.52 presets @esaruoho because all you need to do is load it then save it again and you have an FXP..

and if someone wants to furnish me with a list of such "Surge 1.52" patches.. ill happily "convert" them to 1.6 patches

Tell me how you will "convert" to 1.6 patches this package that is being sold, and is on a server that you have no access to.
https://www.mysteryislands-music.com/product/vember-audio-surge-residue-soundset/

You will do no such thing. Because you don't have access to each and every preset pack downloaded by each and every downloader of each and every preset pack that exists for Surge.

We're talking about basically ruining people's songs when they switch from 1.52 to Surge 1.6. This is not something to be spoken about lightly and in a jokey manner.

If the plugin breaks songs, users of Surge 1.52 who used it years ago, will not want to upgrade to a Surge 1.6.

@sense-amr
Copy link
Contributor Author

Neither is Velocity 100% = 0

@sense-amr
Copy link
Contributor Author

sense-amr commented Jan 26, 2019

oh more insider information.. i had no idea surge packs for a now FREE OPEN SOURCE SYNTH will be SOLD.. nor did i know theres some hidden super special STASH of "1.52" Surge patches! ..

But hey if there is .. if SOMEONE would like to furnish them to me.. ill be more than happy to CONVERT Them to 1.6 surge .. by loading them and saving them? oh thats right.. 1.52 patches PROBABLY wont work anyway will they ? since they were made with an OLDER version of surge .. and surge is in 2019 now.. with 1.6 ..

But hey if there is MAGIC afoot with for some unknown reason shipping 1.52 patches of Surge for 1.6 Surge .. that OBVIOUSLY means someone has already FIXED them to work .. so i dont really see what the problem is at all.. with then having THEIR <a_vca_velsense type="2" value="0.000000">
modified in the FXP file ..?

Oh yeah that url references ONE pack ..
https://www.mysteryislands-music.com/brand/vember-audio/surge/

with a total of 40 Presets.. not overly difficult to convert at all..
and btw i dont think its VEMBER anything anymore ..

@sense-amr
Copy link
Contributor Author

why is a FOSS project supporting Pay for presets anyway ?

@esaruoho
Copy link
Collaborator

You seem to be purposefully ignoring what I am saying, so I will, once again, explain.

This change will break songs and presets. Songs that are on people's harddrives, presets that are on people's harddrives. I realise that you seem to be ignoring the magnitude of how much this matters.

If there are changes made into how presets, and, by extension, songs, are loaded/played, this will mean that songs, that worked with Surge 1.52, will break on Surge 1.6.

This means that the plugin is untrustworthy. It therefore will not work like it used to, and I realise that the common theme seems to be "screw them all, who cares about their music, let's break stuff", but I really don't think that's the way to go.

That's why I suggested, that this could be a menu switch for those that actually need this. Those that don't need it, will use the regular Surge, and their songs will not break.

This is about trustworthiness, nothing else.

@esaruoho
Copy link
Collaborator

Yes, people are selling, and giving away presets that were created with Surge 1.52. Yes, they should play like they should - i.e., if you have made a song with presets or self-made sounds, which played 1 way with Surge 1.52, they should play that same way with 1.6.

You have no worldwide control over the internet's .zip content of Surge presets. You never have, and you never will. So don't propose that you can just go, and tell people "yeah so like these presets you're selling, they don't work with Surge 1.6 so here's a fixed bunch of presets where they will work with 1.6".

Most people that use Surge daily, are still using Surge 1.52. They will move, when they can be sure that Surge 1.6 does not crash or break their songs. It would be correct to expect that a preset made with Surge 1.6 would play, currently, identically with 1.52. Same the other way.

If you make a preset with Surge 1.52, it should play the same way with Surge 1.6.

@esaruoho
Copy link
Collaborator

I gave you an example of a surge preset pack made for 1.52. There are multiple such packs. You seem to be hell-bent on having a problem with it being a paid patch pack.

There are numerous places all over the web that give away free Surge 1.52 presets, and they work with Surge 1.52.

They should also play the same way with Surge 1.6. For you to purposefully, repeatedly, ignore this, is beyond me.

@sense-amr
Copy link
Contributor Author

ahh yeh ok .. lets just leave it like this then
velmanual

and advise everyone that comes into #general asking "hey why doesnt velocity work?" ..
Oh thats because intuitively you're meant to turn your "Vel" knob .. down to ZERO .. which means it has 100% velocity sensitivity ..

yeah..

@sense-amr
Copy link
Contributor Author

its actually You that is missing .. and conflating THIS issue with your idea of me wanting to break surge .. totally absurge!

@sense-amr
Copy link
Contributor Author

Disclaimer:

This ISSUE is specifically stated to be about the Vel slider @ AMP envelope and how it currently functions inside Surge.. any link about "breaking patches" is not intended nor considered at the time of making this issue..

@esaruoho
Copy link
Collaborator

i don't grok why we can't just have a setting in the settings menu for surge 1.52 compatibility Mode ON, where it is OFF by default?
ya know?

@baconpaul
Copy link
Collaborator

This is a long thread which I haven’t fully read but I see I got tagged!

Anyway I don’t plan to work on it any time soon - bitmap arity, userdefaults and saved zoom, vst3 zoom, and mpe polyphony would all come ahead. So I think we have enough time to hear from @kurasu who designed it.

@baconpaul
Copy link
Collaborator

are you guys confusing the value and the display of value? Like if the slider was flipped and tooltip was different but values in internal engine were completely the same would this whole problem just be solved? Is it just “the value at the top of the slider should be the one at the bottom and vice versa?”

I agree with @esaruoho that patch compatabikit with 152 is a key goal

@sense-amr
Copy link
Contributor Author

sense-amr commented Jan 26, 2019

i hope you do plan on it before "release" .. because velocity 100% = 0 is a pretty significant issue for a new user of a Synth..

unless it just stays like this

velmanual

@baconpaul
Copy link
Collaborator

Well either someone will work on it, someone will make a case that it is correct, or this issue will be open when we do a release, or there will never be a release. I know one of those four is true.

Don’t know if it will be me. I appreciate your hope for my plans tho...

I haven’t played with the slider to see what it does. Before I started making a case coding or proposing anything I would, as would, I hope, some other person who was making a case coding or proposing would too!

@sense-amr
Copy link
Contributor Author

yeah i made a case.. and provided evidence..

@sagantech
Copy link
Contributor

So I was conversing with sense about this and verified that this is an issue in 1.5.2 as well as 1.6. My idea is to simply change the display so it is inverted. No change to patches or DSP code needed.

@sense-amr
Copy link
Contributor Author

lets also talk to @kurasu about this .. and see what he says .. but i think thats a great fix if it is to be changed @sagantech

@sense-amr
Copy link
Contributor Author

note: i did read "Vel" to be a function of Velocity sensitivity control and i would imagine most new users of Surge would also think it i s..

@baconpaul
Copy link
Collaborator

@sagantech - thanks. If it really is just a display thing the fix is super easy. Won’t break anyone’s track or anything.

@sense-amr
Copy link
Contributor Author

@baconpaul why don't you do a test yourself ? i provided the bitwig file..

@sense-amr
Copy link
Contributor Author

Hmm having some discussions with @kzantow about this .. we make the point that "Velocity" is already a mod parameter in the synth .. that can be routed at will by the user to everything and anything they want..
In many ways this makes the "vel" reasonably redundant..

We make a tentative proposal to use that slider for something else.. perhaps a Pan?..

thoughts? .. harsh rebuttals?
welcome..

@mkruselj mkruselj added the Feature Request New feature request label Nov 9, 2020
@mkruselj
Copy link
Collaborator

mkruselj commented Mar 18, 2021

Surge XT 1.0 is absolutely the perfect time to do this one!

But also - @sense-amr just FYI in the past 2 years I don't recall any user coming at us with "WTF is wrong with this slider", so your premise that it's confusing users doesn't seem to hold water. People just seem to use the Velocity modbutton and that's it - which is fine, too.

Also I want to add that having Vel slider in dB makes all the sense because it IS tied to a gain control of volume. In a way, expressing this as a percentage would be hiding what the control is actually about, which is dynamic range. Which is what we should rename the control into - Dynamics, rather than Vel. Then flip it around and make it go from 0 dB to 48 dB (not -48 dB). Internally it'd behave the same of course.

But that would be the end of this issue. Which, turns out, isn't that big of a deal in the grand scheme of things.

@baconpaul
Copy link
Collaborator

yeah i think the reason it is confusing is the slider is 'velocity insensitivity' from 0-1 not 'velocity sensitivity' from 0-1.
Easy to flip when we do XT agree!

@sense-amr
Copy link
Contributor Author

sense-amr commented Mar 18, 2021 via email

@baconpaul
Copy link
Collaborator

Yup
It's still 'backwards'
easy to fix and relabel once we get 19 shipped and rejigger the params though

@mkruselj
Copy link
Collaborator

Just to be clear this initial post I made referred directly to the velocity slider next to gain slider responding in an inverted way to that which normal operation of a slider to control velocity would be expected to be used

It was perfectly clear all along. 🙂 It just turned out not to be a big deal for apparently everyone, since we didn't have anyone else coming at us with "hey, wtf?!" 🙂

@sense-amr
Copy link
Contributor Author

sense-amr commented Mar 18, 2021 via email

@mkruselj
Copy link
Collaborator

So are many other things in the world yet we live 🙂

@sense-amr
Copy link
Contributor Author

sense-amr commented Mar 18, 2021 via email

@mkruselj
Copy link
Collaborator

It's a matter of issue prioritization and it's just not that important in the grand scheme of things (you're really the only one asking for it, we literally had nobody else reporting it or asking about it). It will eventually be done, but constantly repeating it's wrong it's wrong won't make it happen any sooner. If all goes well with Surge XT plans, might happen sometime this summer, but not before.

@sense-amr
Copy link
Contributor Author

sense-amr commented Mar 18, 2021 via email

@baconpaul
Copy link
Collaborator

Calm down guys. All on the same team etc.... but you made me laugh @sense-amr

The thing is when you first raised it I knew it was wrong but didn't know how to fix it. Now I know how to fix it but have to stage that fix. That's all. We will and can. Easy enough. Just not in 1.9

@sense-amr
Copy link
Contributor Author

sense-amr commented Mar 18, 2021 via email

@baconpaul baconpaul removed the Code Hints Requested Someone would like to tackle this but wants a few pointers on how to start label Jan 15, 2022
@erikjms
Copy link

erikjms commented May 6, 2022

[much time passes..]

Since this is still open, here is another single voice in the wilderness:

Yes, the Velocity slider is backwards; please turn it on its head so it works intuitively.

I started reading the manual for Surge last night and when I got to the explanation on how this UI element is set up, I saw the light, such as it was, and understood that the velocity slider was not broken in the version of XT I am using.

It's just backwards.

I have no idea if anyone else wants this changed, but for what it is worth, I only open issues on projects when I have the time and energy to help debug, which is almost never. It is not always obvious how open a project is to drive-by comments on UI design, especially by a non-programmer musician who just wants the knobs to work the way they look like they do. I'm on the issues page looking for information completely unrelated to this one UI element. I was fine with letting it, um, slide--then saw the title here and laughed to see that someone else had noticed this.

@baconpaul
Copy link
Collaborator

yeah our current plan is: ship 1.1 in the same vein as all the other 1.xs and then embark on a much bigger overhaul where, indeed, this will change to a more rational direction

it is indeed maddening but i keep chickening out of fixing it. but maybe, since 1.1 will hav ea long life since our overhaul will take a long time, i should just bite the bullet and do it. @mkruselj @VincyZed thoughts? It's really easy for me to add an 'invert' option to a slider and apply to just this slider globally.

@sense-amr
Copy link
Contributor Author

sense-amr commented May 6, 2022 via email

@mkruselj
Copy link
Collaborator

mkruselj commented May 6, 2022

Yes we know, the history is right here in this thread. 😛

@baconpaul I would save this one for XT2. That's the one in which we break everything and rebuild. This issue is a perfect fit for that situation. I wouldn't want to cram it in 1.1. Adding that invert option doesn't seem like the right way to go to me.

@erikjms
Copy link

erikjms commented May 7, 2022

I read the whole soap opera! Was very entertaining. 🙃

Myself,I can live with this for now since I know what’s up, or down, with the velocity slider. The info is buried in the manual, though, and I dunno how many others read these things. I only do when I get to the point where I like the synth well enough to want to know what the most inscrutable knobs and buttons do.

If I had an audience anywhere, I’d post a big banner on my site/blog(substack that read “Hey! The gain velocity slider in SurgeXT? It works! It’s upside down though, and will be fixed in some foreseeable future or another”. And link to the manual page describing its behavior.

I also imagine that other people care about microtuning. They should, but. 🤷🏻

@baconpaul
Copy link
Collaborator

Well we have micro tuning right at least! Chuckle

@sense-amr
Copy link
Contributor Author

sense-amr commented May 7, 2022 via email

@erikjms
Copy link

erikjms commented May 7, 2022

@baconpaul Yes! Yes you do! I took a look at the Odin2 repo to see if it was tunable and saw that you had given some very thorough advice on why .kbd support is necessary for microtuning to work. Thank you thank you thank you for your service.

Now I have another synth to learn. And will stop writing here before cluttering this issue with more OT noise—albeit sympathetically resonant noise.

@mkruselj mkruselj added this to To do in Modulation May 16, 2022
@mkruselj mkruselj added the Breaking Change In order to close this issue we need to make a breaking change (no backwards compatibility) label Aug 21, 2022
@sense-amr
Copy link
Contributor Author

sense-amr commented Oct 11, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Breaking Change In order to close this issue we need to make a breaking change (no backwards compatibility) Feature Request New feature request UI Issues related to UI look&feel UX Issues related to user experience (UX) - mouse, touch, keyboard, MIDI inputs, etc.
Projects
Development

No branches or pull requests

9 participants