-
Notifications
You must be signed in to change notification settings - Fork 404
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
Better/more precise automation names for FX params #1559
Comments
So this one is going to be, basically, impossible. I'm going to close it as "not doable or so hard that it is not worth doing" The reason is that the header labels are not part of the parameter they are part of the effect. And when the VST is generating the label, it only has a reference to the parameter. You can see the insanity I go through in surge-rack and surge-fx to get that label name (sorting by graphic position and building totally separate data structure). It is not exactly impossible - I could rewrite every effect to have a reference in the parameter, make sure it doesn't leak, modify the vst3, au, lv2, and vst2 to see if it is not null, fix the API to make the label easier to associate with the parameter number, and so on, but basically that's not worth it. Or I could make it so parameters all have a display name different from their label name. Or a variety of other things. But I just don't think it is worth it. So alas the VST param names will be the name displayed under the slider. That unfortunately means your renaming spree #1558 will need revisiting. We can't assume this issue happens as a pre-requisite of that. Sorry! |
Gonna reopen this even though I am still really worried about doing it. |
I made my peace that this is not happening, so I'm closing it! |
#7284 basically does this |
As can be seen from above screenshot, distortion effect has three parameters called "Gain", and in DAW they all have the same name... Ideally the section label (in this case Pre-EQ, Post-EQ, Output) should be also used to construct a clearer and unique name for each of those currently identical parameter names.
Will be awesome then!
The text was updated successfully, but these errors were encountered: