No worries, figured as the grabbed parameter’s gui tweaking is also picked up by the horizontal slider in the bottom of the tools gui, it wouldn’t be that hard to record at the same time?
It`s partly a case of parameter selection and who/what is controlling it. The tool currently chooses the parameter/gets the renoise chosen parameter. It can then watch / adjust that single parameter.
In the case of allowing the VST to choose the selected parameter it gets a bit more tricky as you have to watch for a parameter movement. When the song is playing and the vst is automated a lot of different parameters can start to move. You can tell if the user starts adjusting an already unautomated parameter fairly easily but if they then change to a parameter that is already automated; you would be needing to be watching all the automations for changes and change the selected parameter in time to start recording properly.
Thinking further on it, even if we had mouse-click flags in the API, unless a VST passes a message about which parameter was left-clicked (and not moved) then we would have the same situation as above, still watching for movements.
The solution I was thinking of with the current API would be to grab a parameter like the [G] button does (song needs to be stopped) and then allow the user to record that parameter. The parmeter could easily be released again on changing it in the tool or renoise, but then you would have to stop the song again to grab a new parameter.
If you didn`t have the parameter grabbing and just linked the selected parameter all the time then you could inadvertantly be creating automations with the VST gui when not wanted.