I am working on a delay plugin and would like to allow the user to switch between tempo-synchronized (e.g. quarter note) delays and freesync (e.g. 100 ms) delays. Looking at professionally produced plugins such as Audio Damage's Dubstation, they are able to utilize the same parameter for both of these units. For example, when you flip the midi sync parameter, the parameter that previously stated "50 ms" now states "1/4". This change is seen both in the plugin's GUI and the parameters available within the DAW itself.
Although the most straightforward approach would be to have two separate parameters for ms delay and synchronized delay, I appreciate the simplicity and clarity of having one delay time parameter that covers both use cases. Seeing as many modern delay plugins have implemented this functionality, is there a commonly accepted, elegant method for programmatically altering the parameter's units in this manner?
Apologies if this question has been asked before, but I have done quite a bit of searching and reading this week without much luck. The approaches I have tried and/or considered so far are as follows:
- Creating two PluginParameter pointer member variables in plugincore.h (representing free sync and midi sync delay time parameters), passing one pointer into the parameter vector during initialization, then programmatically swapping the addresses the pointers point to if the midi sync option is enabled or disabled.
-Swapping the PluginParameter pointers themselves in the PluginParameter vector and map (by erasing the old and inserting the new), making sure to preserve the same index.
-"Re-initializing" the PluginParameter object using the setter functions.
All of the options I've come up with feel a bit kludgy, even if they might work. If this problem has been already solved elsewhere, I would appreciate help in figuring this out.
Thanks very much in advance!
Apologies for the delays in my Forum replies as things have become complicated for me work-wise. Starting in January that should be cleared up.
As for your question - the only major issue is that the PluginParameter objects which wind up as DAW parameters are always considered to be part of the automation system. Plugin developers are prohibited from doing anything to these parameters that could screw up the automation, such as adding/removing parameters, changing the default or min/max values during operation. If you are dynamically adding or removing PluginParameter objects from the list, then this is bad because it would screw up the automation.
One way to peer into other plugin parameter lists is to use the "default GUI" interface which varies by DAW but usually is implemented as a giant list of sliders or knobs. AAX (only) as the ability to turn off the Default GUI but as with the others, AAX prohibits changing those parameter details above. Note that you are allowed to change the name of the plugin or its units. Try that with the plugin you are referencing to see if there are really two underlying parameters, or one. If there are two they will necessarily need to show up as two GUI controls in that default GUI.
With the SynthLab synths from my new book, I use a trick for dynamically loading the Option Menus (drop-list control) that contain the waveforms/filters as well as the SynthLabs modules. Since the option menus represent string-list parameters, you are free to change those strings as long as the number of strings does not change (otherwise it would blow up the automation). To facilitate this, I created a custom-view in VSTGUI called CustomOptionMenu which allows you to change the names of the strings in the list via the ASPiK messaging system that is documented in the ASPiK docs. This is now part of ASPiK and is in the customviews.h file. It is also documented to some extent in the SynthLab docs. There is another custom-view called CustomTextLabel that allows you to change the label text, on the fly during plugin operation. Neither of these changes are illegal because the number of strings in the list does not change, and the underlying linked variable does not change. This allows automation to work properly. With this pair of custom views, you can make the parameter *appear* to change as the name and contents of the list change, but the underlying variable does not. For SynthLab, I use a pair of these pairs of controls, one for the SynthLab Module, and another for the SynthLab string list (waveforms for oscillators, filter types for filters, etc...). When the user saves the plugin state during a session, only the indexes of the strings are saved. When recalled, the controls re-set themselves up to appear as the user left them.
There is another way to do this as well, and likewise involves custom-views but in this case, you create both parameters as independent controls, and then you use the custom view messaging to hide or show the controls. When you place them on top of each other in the GUI, you can make it appear that the GUI control is morphing but in reality one cluster is hidden while the other is shown. This is also legal as automation will still work properly but it is less ideal because you need to know when to show/hide the controls.
One reason I still use VSTGUI4 (and abandoned the early RackAFX GUI library that I hand-coded) is the benefit of using Custom Views and Subcontrollers. With these two items, you can do anything with GUI design, though of course it is not trivial and will take extra coding. If you have not tried using custom views or subcontrollers, see the examples in the ASPiK SDK.
I was having a very similar problem a while back and wanted to use the inbuilt UIViewSwitch functionality for that purpose.
Unfortunately it was broken in regards to loading presets at the time. After some effort though I was finally able to have that issue addressed by Steinberg.
I've outlined how to use the View Switch (several times) in the that forum post and the fix to the issue is at the end. You can implement that immediately or wait for it in a future VST update. (was only a minor issue but definitely wasn't professional)
In your case I would actually use two knobs, combined with the ViewSwitch. That allows keeping numeric-entry functionality and for knob-indentation of the bpm synced mode.
On the other hand, feel free to take your own approach and Will's advice about learning the custom-view messaging system is extremely good as well.
Most Users Ever Online: 152
Currently Browsing this Page:
Guest Posters: 1
Moderators: W Pirkle: 656