The GenericAudioProcessorEditor’s text boxes next to the sliders should be editable. Here’s a PR for this, which removes more lines than it adds as it takes more effort to make them not editable apparently.
That would be cool, but beware, that sending a value without beginGesture/endGesture causes trouble with the automation. I haven’t read all your code, so IDK if it is already taken care of. Especially considering that there is an open(?) issue about beginGesture/setValueNotifyingHost/endGesture not working, if sent right after another:
1 Like
The PR uses the Slider’s already built in text box, so changes from the text box should be handled like the slider is handled, i.e SliderParameterComponent::sliderValueChanged should handle it and if it doesn’t do the gestures right then it probably also doesn’t do them right for slider drags.
So put your vote where your mouth is 
Making the box editable like that causes trouble when hosting plug-ins.
If you’re hosting a VST2 plug-in with discrete parameters then all we can do is use a slider and display the text presented by that parameter for any given value. This could be something like ‘First Order’, ‘Second Order’, ‘Third Order’, …, for a ‘Filter Order’ parameter and there’s no way to tell what text will correspond to what value. This un-editable slider approach is in line with that taken by DAWs in their generic parameter views.
We could use 0.0 to 1.0 float ranges for each parameter, which makes setting values in the box trivial, but we’re then throwing away information about the parameter. The ‘Filter Order’ would be displayed as ‘0.3’, rather than ‘Second Order’.
Wasn’t that what the parameter’s getValueForText and getText were for?
Did you try the PR or are you guessing? If it doesn’t display as “Second Order” please give me a reproduction so I could fix it.
1 Like
Also a thought that occurred this morning to me, how about sending beginGesture() when the label is clicked for editing?
It would be consistent from an UX point of view IMHO and could help to remedy the problem, that beginGesture(), setValueNotifyingHost() and endGesture() should not occur en block…
For plug-ins without a .vstxml file (which is pretty rare, and on top of that Steinberg appears to have scrubbed all mentions of the format from the web) JUCE’s VST2 hosting doesn’t support getText and getValueForText and will fall back to using floats. This was a choice made a long time ago because many plug-ins had extremely flaky support for both of these ops. Maybe the landscape has changed somewhat since then, but I suspect this is the reason that DAWs also prevent you from entering any text to be interpreted by VST2 parameters.
Iiuc you are saying that for some of the hosted VST2s without UIs, when the host opens a generic UI, this change will make its text-boxes currently showing numbers in 0-1 range editable (neutral benefit imho), and for other hosted plugins and for plugins using the generic editor internally as their UI or a component within it (as I do during development) this is a big win. So why not???
I’m saying that if you are hosting a VST2 in JUCE, then your proposed changes will make discrete parameters with string labels display 0.0 -> 1.0 instead of ‘First Order’, ‘Second Order’, … . This would prevent you using a GenericAudioProcessorEditor to provide a GUI-less view of the plug-in as the DAWs do.
Just make it configurable? Or for example display the formatted text from the hosted plugins, but when editing the text, accept and handle a 0.0-1.0 ranged value? (Not great for the end user, but better than no manual entry available.)
I think setting a 0 to 1 value on a slider which displays text for a different range (say -1 to 1) would be extremely confusing for users. I can’t see that working well. You’d also have to know what scheme the plug-in uses to map the range to different discrete values. It may not be equally spaced, or use the start of the midpoint of each division, …
Making it configurable is possible, but it would have to come with a caveat in the comments explaining why you shouldn’t use it in some cases, which isn’t particularly appealing.
There’s a clear motivation for having editable values in some quick GUI you can throw on an AudioProcessor, but I think the GenericAudioProcessorEditor should serve the lowest common denominator.
There are several use cases for the generic editor:
- [A] When hosting plugins, that don’t have their own custom editors, use as their editor
- [B] When developing a plugin without a custom UI
- [C] For internal use while developing plugins, to be used as a component in their temporary UI so that one could control parameters that weren’t programmed into the UI.
To me the important use case is C.
For @t0m it seems that the most important use case is A, specifically for the cases where the problem manifests, which are VST2 plugins that don’t have a UI and also don’t have a .vstxml file.
Is this analysis correct?
You’ve narrowed case [A] a little too much.
If you’re hosting plug-ins you will probably want to display a generic parameter view in addition to the plug-in’s GUI. All DAWs offer something like this and the current GenericAudioProcessorEditor offers the same functionality as the DAWs.
The problem is most obvious in VST2s, but I’d wager that there are plenty of VST3s that would also crash if you handed them some very slightly malformed text to parse. There’s a reason the DAWs don’t let you do this.
You’ll also run into similar problems without hosting pre-built plug-ins: if your AudioProcessor is using the old parameter management methods then they can’t do text parsing. Yes the old methods have been deprecated for a while now, but every time we mention them on the forum there’s a decent number of people unwilling to update, so they will remain deprecated, rather than removed, for a little while yet.
I’m biased towards keeping the status quo as you should be able to slap a generic editor on anything and have it behave in unsurprising ways.
For cases [B] and [C] I’m aware that the current situation is a little annoying. If you are not using the old parameter methods then not being able to type in the boxes feels a little too restrictive.
Perhaps we can switch editable slider values on if the AudioProcessor we’re sitting on top of is both not an AudioPluginInstance and not using the old parameter API. I think this would work, but I’d have to investigate it carefully to make sure there are no corner cases we’d run into.
Reaper allows that for VST3 plugins in its automation envelope point adjustment window, but interestingly, not in their generic plugin parameters window, which works like the Juce GenericAudioProcessor and shows just uneditable labels. (I am sure there are some VST3 plugins that will crash or something when given nonsense text, but at least Melda’s plugins just handle those as the parameter’s minimum value.)
Is the point adjustment window what you get when you right-click on an automation point? There I only have the option of setting a 0.0 -> 1.0 float value…
The plugin needs to be a VST3 plugin that supports the feature. At least Melda’s plugins and (modern) Juce based plugins have the support.
Ah, OK. I gave it a quick go with an iZotope plug-in (non JUCE-based).