Is it possible to simulate the turning of a widget knob in GPScript?
IOW, from a script the aim is to generate a data stream of the same type as would be generated by a widget knob which is connected to and used to drive a plugin parameter.
The issue I believe is that the actual plugin parameter which is to be driven responds to a changgng data stream itself rather than simply to a final value.
Specifically, I’m working with the ‘Navigate thru presets’ parameter of Arturia VST3 synths. If I hook a knob widget up to it, it does what one would expect - the selected preset changes up and down as the knob is turned up and down.
However, my goal is to randomly select a preset when I press a button. It seems as if I will have to fully simulate the data stream from a turning widget knob to get the VST3 synth to respond appropriately.
P.S This randomization goal I have already solved for the VST(2) versions of the synths (which operate differently in this respect). I’m specifically aiming to solve for VST3 versions at this point. Thanks!
I don’t understand this — if you want to set a plugin parameter value to “x”, you just send the value “x” to it, either directly, or by setting a widget mapped to that parameter to “x”
@dhj I’m working with the ‘Navigate thru presets’ parameter of Arturia VST3 synth plugins (e.g. Pigments, CZ V, Jup-8 V4, etc.)
Here is what I seem to be observing:
The plugin maintains its own internal idea/index of the “currently selected preset” (CSP).
As differing (increasing or decreasing) values of the parameter ‘Navigate thru presets’ are received the CSP moves up or down by one increment for each received change.
Thus, sending one new value results in a one slot change, up or down, regardless of how large or small the change in value is.
I speculate that the reason for this is to allow navigation of lists of arbitrary length, which is indeed possible. if you keep increasing the incoming value you continue to go forward in the list indefinitely, even for thousands of items. And the reverse if you are decreasing the value.
I have not so far found actual documentation about this, but I think I’m observing correctly. If anyone wishes to experiment themselves with ‘Navigate thru presets’, I welcome confirmation, refutation, or refinement of my observations.
BTW, in order to prevent a blizzard of preset changes (e.g. as a knob is turned) the mere Navigation to a new CSP does not actually change the preset. Rather, having arrived at the desired CSP you have to send in a different message, on the parameter ‘Select Preset’. I call this the “take” message (but that’s just me!). That’s what causes the preset change to actually happen.
OK - I just loaded Pigments to see what’s going on and have consequently asked some questions on their forums since the host automation parameters aren’t properly documented. I’m unclear exactly as to how a specific preset is supposed to be loaded.
Frankly it’s probably easier to use GP User Presets
Working via plugin parameters, first interact with the ‘Navigate thru presets’ parameter (which puts a new preset “on-deck”), then interact with the Select Preset’ parameter, which actually actually causes the plugin to load the “on-deck” choice.
Yeah, I had a look at it - and as far as I can tell, it’s a very bizarre design.
That Navigate Through Presets seems to use the following algorithm
if newValue > oldValue
then increment preset
else decrement preset
where > can be a difference of 0.0001, for example
So if you want to browse forward, you need to set a value of 0.0 (say) and then as you move a widget in either direction, increment that value by 0.0001 and send it to the plugin and you can keep going forward.
Similarly if you want to browse backwards, set a starting value of 1.0 and decrement by 0.0001 as you turn a widget
Attached is a trivial gigfile that demonstrates this working
Thanks for the demo showing the technique using a for loop and Setparameter().
I’ve evolved this a bit to add a first take at randomization buttons. Files attached.
I note that ‘Navigate thru presets’ wraps around when it reaches the end of the current Bank/Playlist in either direction. This simplifies things a bit, as one does not have to worry about hitting upper or lower bounds when randomizing.