VST object not communicating well with GRM tools plug-in
Hello
Using the VST object, I am trying to use GRM Delays plug-in in a patch. I've 'printed' and can see the parameters, but messages using these names do not effect the change they should.
The parameter 'Preset' is the first on the list (it should relate to 16 Presets in GRM). I have sent a message (e.g. Preset 6, or 1 6) and in the inline view I see that nothing is affected on teh visible sliders (although I hear a change every time I send the Message).
In the view with the plug-in's own window I see that my Message "Preview 6" is resetting everything at every click, but none of the results are any of GRM's Presets. They seem random.
Other parameters do not seem to receive the right messages either.
Can anyone help here? Thank you!
making the presets a VST parameter is not good practice and might cause that it does not work in every host. but how could the other, regular parameters not work? not sure.
i would recommend - as a "workaround" to what you originally wanted to do - to use numbers only. you can still assign the names to the numbers using some umenu or coll to present that to yourself.
many plug-ins do not have understable and/or unique parameter names anyway.
oh, and dont get screwed by graphics. certain max versions did not reflect parameter changes in plug-ins until the window was in foreground, and while vst~ can do it now, it might still be an issue caused by some plug-ins. so make sure that it actually did not work.
all this is assuming that you did not load the AU version by accident. :)
Thanks very much for this reply Roman. That's a pity - the Max help file gives the sense that all this is possible. But your workaround may get me there - at least to control parameters in a fixed set-up.
I'm not an advanced user, but I'm not sure your workaround is likely to be feasible for live audio processing? I really want to be able to use a midi device to shift parameters, such as between presets, in a live situation.
Actually there's another problem, which will affect the workaround too.
Using the 4th outlet of the VST to see the parameter and the value of the parameter, I can see that Preset is parameter 1, and that if I adjust the Preset inside the window of the GRM plug-in (not the Max graphic), the numbers coming through Max don't reflect the Presets numbers of GRM. Preset 16 comes out as 1, and preset 1 is 0. Preset 10 is 0.6 etc.
If I try using these numbers as parameter messages into the VST, most work correctly i.e. sending in 0.6 sets the VST to parameter 10. But not all of them!
I don't have the GRM Delays plugin, but I use other plugins regularly (mostly FabFilter) and have done a lot with dynamically sending values from Max to the plugin parameters.
With FabFilter, all internal parameters require float values of 0..1. So even if the plugin UI displays other numbers, I have to translate (scale) to 0..1. So, for example, the EQ gain shows -30 .. 30 in the plugin UI. So I will use -30. .. 30. as the range in the Max number object and send it to:
scale -30. 30. 0. 1. then out to the VST~ inlet.
For your presets parameter, you could try: scale 0 16 0. 1.
calling the parameter names and writing them in a [coll] which translates names to numbers after loading a VST plug-in takes 0.1 milliseconds - and then you can select stuff by parameter names to send the associated parameter numbers.
for presets i dont see why you would need to use the parameter, you can change presets by using int just as you can change parameter values by float float. *)
i mean you can also automate the plug-in window position or loading presets by a MIDI controller if you want. it is max!
"But not all of them!"
all parameters are 0.-1. and when there are 16 presets they go in steps of 1/15 of that range.
for me this is only yet another reason not to use this strange GRM parameter but change the preset using the "normal" preset command, where 1 is 1 and 7 is 7.
*)
wait, how was that? last time i used GRM plug-ins was in 1998 i think. don´t they have some kind of preset morphing? well, if you really do not get it to work otherwise, you can recreate that kind of stuff in max, too.
and if you do that, you will have that feature enabled for all plug-ins and not only for GRM...
in the 1998 version of GRM everything works as it should.
i can automate either parameter "19" or parameter "intslide" and the plug-in follows my orders.
so either mrs. ina or mrs. rachel - or a combination of both - must have made some trash.
Thank you both!
@Rachel if you have a patcher where something isn't working, please send it over. I have in the meantime confirmed that the GRM Delays plugin (VST3) is functioning as I would expect on macOS; changes to parameters from Max are reflected in the GRM interface, and parameter changes are reported to Max (in the normalized 0.-1. range, as expected).
@jeremy that's very kind, thank you.
I don't know what was going on. A couple of days later I copied out the part of the patch that was misbehaving and now it works. As it was originally only the Max vst help file with my GRM Delays pulled in it's puzzling, but anyhow it's now doing what it should do so I'm sorted (for now!)