Bi-Directional Parameters Manipulation for Plugins

[gurulogic]

I have been building a patch solution that in summary allows to map a fixed number of controllers dynamically between any plugin loaded within the workspace, as well as reflect in the controller interface the source patch, plugin name and plugin param name. Also, any mapped parameters are updated in the controller interface when either changing HH presets, plugin presets or when directly manipulating the control from the plugin UI.

In order for this to work as desired, the plugin i/o arrays must be received and sent by bus which introduces latency to the parameters array loop and causes some issues, most of which I have solutions for. The exception is that when I send modulation data to a plugin the plugin parameters become "locked" and will no longer correctly update when changing presets or manipulating the plugin UI.

I am hoping someone has a brilliant idea how to allow modulation data to be sent to the plugin without freezing the UI so as to allow for bi -directional parameters feedback when using modulators. I believe that if there were a pass if change per array element value this problem could be easily solved, but it is seeming as though that may not be an easy feature to implement..

Here are some examples of my methods based on a very simple one plugin, one mapped parameter and one modulator.

First example (example2waymap) is my established method so far. The problems in this method are that when the LFO is on, the plugin UI becomes unreliable with HH PM or internal preset changes and direct control from the UI is no longer possible.
Also, somewhat inconsistently, sometimes the parameter for the mapped control (index 1) cannot be updated from the plugin UI unless the set array value is triggered by the has changed module, but in the case of using has changed to trigger set value while using buses method, the controller values become inconsistent when received by the plugin so this method is not reliable.
http://www.sensomusic.com/forums/upload ... waymap.pat


Second example (example2waymap(wired) works pretty much perfect for two way parameters exchange while the LFO is running , except that I must hard wire to the plugin which does not work for me, I need to use buses. In the wired method, I must use has changed to trigger set value or else the mapped parameter is locked at the plugin UI. For LFO, this doesn't matter as there is no real need to have the LFO parameter value updated from the plugin.
http://www.sensomusic.com/forums/upload ... red%29.pat


Third example (example2waymap(alt)) is another approach where I circumnavigate the buses latency issue by having the plugin parameters kept in a local loop and sending the remote parameters data to manipulate the local loop directly. This would work fantastically except that I cannot even begin to comprehend how I would dynamically map the necessary index references and parameters from apprx 64 controller sources to their respective plugin destinations. This seems this would be extremely complicated so I doubt this is a solution.
http://www.sensomusic.com/forums/upload ... alt%29.pat


The only other option I can think of is to give up on the idea of using buses for the task and having a hard wired controller interface per patch with special attention to not create any bloc of latency but my ideal and much lighter on resources method and to have items from various racks mapped to a single controller page is to have one central interface for all parameters control within the workspace..Hmm..??

[23fx23]

from what i experienced by the past, thats indeed a bit trycky. think if you hardwire an array in, it overides it all, you have to stop completly the flow when setting the plugin manually (ie stop flow, driven by on mouse down), same with presets (that on change would trigg a counter and stop the flow for a tiny while). and you have to play with wait ones so that when the plugin send out datas, input is blocked for a bloc more.

a non wired method i end up with but more complex was relying on script and iml, scan only wich one value changed in array, scan wich param name from the list and update it wirelessly. this works and doesn't overrides but more complex and higer cpu.(had done this in an old usine automs addon/thead, think sephut got a more modern version of the idea in case)
also while that worked at the time, iml is not recommanded for fast changes load of updates, so prob forget this one for a modulator thing..

not sure completly understood 3 but i would try to use dynamic bus name changes, only one bus get FROM a mod bus , and a listbox is filled with all possible mod source buss names, when seting an id, the listbox delivers the name to the buss where it should look at, or vice versa your modulations send to target buses.
ie there is a bus per VST patch, getting and ID of a parameter it should modulate, -1 otherwise, if it has an id to modulate, then check the requested mod source id, and rename the bus, let the value be set. dk if make sense

[23fx23]

re reading i think i got you map idea, what i would do pers to make things simpler, is all your incoming CC are numbered incrementally, lets say 0 to 63.
then for ech vst you make an array Map. ie cc 0 -> vst param 3, cc1-> param 7 cc2->5 ect, so the array looks like 3,1,5 ect
then simply use a get array element value, passing ccnb as position in the array, when moving CC2, it will look in the array at position 2 and give you 5.
you could then either use one array per vst or a preset of a simgle array that correspnd to the currently remoted vst

[gurulogic]

That is interesting, I think I see what you are saying. I will try in the morning and see if I can decipher your idea.

The method I have been using so far on this idea of mapping plugin parameters from a single set of knobs is that I concat all the parameter arrays from each vst group and send by bus to the control patch and mix with incoming concat array parameters from the next group etc for one giant array. I also concat the params names in a similar fashion with a unique id character added to each parameter name per plugin ie:*FilterFreq, or @Filter Freq Then via the array Difference module, whenever a control is moved on a VST, the index outlet selects the parameter name from Commatext Get String which is stored with "learn" and acts as a marker to index the "learned" parameter via CommaTxt Get String Index . On return of parameters to the VST groups, each plugins array is extracted by size to the respective plugin inlet. (plus a bunch of other tweaks to make things not break when changing plugins / array size)
What I like about this setup is that there is no limit to the number of accessible parameters per plugin or limit to number of plugins assuming I have made the plugin slots for dropping in my template and I can freely add, remove or even move plugins without losing previous mappings, and there is no huge list of parameters to scroll through to map a control. Also it makes it easy to store several mappings within the same control interface so I can always use the same page from my hardware controller.
So far it works quite slick except for the part where I loose feedback from the plugin when sending a continuous modulation. I could probably make do with the solution you suggested of pausing the modulation when changing presets or editing from the UI but it bugs me if I have to compromise functionality lol, so I figure I might as well try to find a better way. Hopefully while being able to keep the existing functionality

[23fx23]

ah yes sound nice, good little tricks sounds handy by doesn't that make a huge array to demultiplex in each patch? thats ok cpu wise?

[gurulogic]

I extract the arrays into group destinations before they are dispatched from the control patch, then extract, or "demultiplex" again for each plugin within each group. All the patching I have done to make this work is maybe a bit on the heavy side but nothing too out of control.i have barely put any time on this since early summer so I am catching up a bit but will definitely upload a working example soon.

[gurulogic]

I put together a solution that should work how I want it to.. This makes sense and works great for one plugin but for some reason the second plugin in this case which should be sending and receiving parameters equal in every way to the first plugin but for some reason the plugin UI freezes. I do not understand why at all. The only possible variable I can see is the the extract array and concat array are somehow introducing latency that causes the second (bottom) plugin to have lag in the parameters array loop??

Example patch file
http://www.sensomusic.com/forums/upload ... Mod.02.pat

[23fx23]

mmm tried to decipher but could not find culprit, tes there must be some kind of delay somewhere, the feedback in doesn't work as expected.

a workaround that seems to work is if you add a pass if change hold like 10ms for me here on the wire feeding the array to vst2, but you loose a bit of speed definition, ideal you be the hold to be 0, exept a small value when mouse is down on vst ui but i could not find back mouse down outputs on vsti out, mm did they disapear or i tripped?

[gurulogic]

Hmm, interesting. Thanks for looking and confirming. For me a pass if change with 3ms hold, so 1 bloc on the params input for plugin 2 seems to solve the issue but there really should be no bloc of latency so I will keep digging as to why. Also even 3ms resolution might cause a grainy sound for fast LFO?
And no you are not tripping, there is no mouse down for VST as long as I can remember, nor does the mouse module show mouse data when over a VST, so this is no use to try.

[gurulogic]

Alright.. with use of the time elapsed module I found there was a 1 bloc latencyafter the concat array and if I deleted the array out to the set value the delay went away so a processing loop required a buffer I guess.
I tried replacing the concat out > set value wire with a quicklink to break the loop and had the same problem, but breaking the link from the plugin params array to the concat seems to work fine. Now it should not be too much trouble to adapt this approach to handle racks of multiple plugins.

It would sure be a lot less patching if pass if change array element value were possible.. wink wink nudge nudge

[23fx23]

ah yes nice, interesting gg! yes i wonder if maybe internally this could be solved if the vst module would have inbuild 'pass if change array' mean on array chge it would change only values that changed in the array, actually i think on every array change it loop and and apply all parameters, wich make tricky if a lfo constantly update it. but yes a more general thing would be cool i reckon, still cool that you found a clever solution!, didn't thought that could be possible

[gurulogic]

Yes, the asynchronous? method of arrays when in a loop can be tricky if the processing does not occur in the same bloc, definitely not ideal for when bidirectional control is required. As seems there usually is in Usine, at least there is some method that can work. I will update my feature request for pass if change array element and suggest your idea for vst module pass if change, although I can see how a true pass if change for general array could be useful too.

[woodslanding]

Just wondering where you are with this now? I'm need some similar functionality, so I'm looking into building it. I ran into a lot of these problems the last time I tried! Are there some good starting points in the addons library?

[gurulogic]

I have been mostly just a forum lurker as of the last while, super busy with everything else in life so no major breakthroughsyet but I do have the framework for solid fully functional, if not a bit patch heavy method that was working well last I checked. I had big plans to upload it to addons but at the rate I'm going all of the bits I wanted to include might not be fully complete until HH4 and of course I'll have to rebuild it from the ground up then, haha. I'll try in the next few days to extract the key patch and templates parts for you to use as a starting point at least.

[woodslanding]

well, any sort of starting point might be cool-- but don't go out of your way. I know what you are saying about making stuff that is actually reusable--I have not posted much to addons because even after something is working in context, it can be a ton of extra work to make it function on its own! I may just start building something and ask here when it doesn't behave the way I expect....

I did ultimately have to use a script to get bi-directional control from my inspector to individual channels without either 1) passing info between channels by mistake, or 2) getting jitter between a channel and the inspector when values change. I tried to make it work with patching and gave up.

I'm guessing I'll need something similar in this case.

Cheers,
-eric

[gurulogic]

Well.. Apparently I must have been doing some patching in my dreams because my solution was nowhere near as integrated in my workspace as I had thought, in fact I am totally lost as to what clever solution I was aiming for. Too many months away lol.

Here is the base solution I had come up with before for full two parameters way control, the key is that there is an array set value module for both manual parameters control and for modulation parameters control, maybe it can give some ideas.

I'm going to keep picking away at this, will keep posted if I figure out where I was going with this..

http://www.sensomusic.com/forums/upload ... odtest.pat

[gurulogic]

OK, I think I figured out where I was headed with this. Here's a quick and dirty example, should be pretty self explanatory from the notes inside, basically there is 4 knobs and 2 modulators that can be assigned to any? number of plugins parameters within a workspace that is connected to the buses "network" . Hopefully it still works, made several changes quick to streamline. Still lots of stuff from a previous method to integrate this approach into if no fatal flaws are discovered.

http://www.sensomusic.org/forums/upload ... n%2018.zip

[woodslanding]

Just downloaded it, I'll take a look!

[oli_lab]

I've been thinking of this matter and wonder if my idea is feasible :

I think there's a way in sdk to update an input with a current value
for exemple : if I move a knob on a vst, it should be possible to get the value at the input of the plugin input .
then, would it be possible to have the fader connected to that input being capable to read the vstmodule input and refresh to this new value accordingly ? we need a "refresh value from ourput" input on the fader for that.
should be possible as when a fader is created it is capable to read the value of the input its output is being connectd and set it accordingly

[woodslanding]

Okay, I have a (partial) solution to what might be what you were asking for

Hasn't been exhaustively tested, but seems to work.

http://www.sensomusic.com/forums/upload ... erBank.pat

To use:
Press learn. Move slider. Move VST control. Rinse and repeat (actually rinsing is done for you)

Learn button should turn off, and slider is mapped. So far I can move params in either vst or slider bank without issue, but try it out and let me know how it is working.

Mappings are stored in faders in subpatch so they can be stored/recalled with a preset. If you change poly value in slider bank, make sure to change CONTROL_COUNT in the script to match.

cheers,
-eric

[woodslanding]

Rereading this, I have completely not dealt with the lfo param control issue!

I do SO miss Max's parameter control method here. Just send a 2 item array where item 1 is the param# (or name) and item 2 is the value.

Similarly, when a param is changed in the vst, you get a 2 item array out.

Doesn't work very well with Usine's circuit model tho (as opposed to Max's message model...)

But Usine uses the message model with MIDI.... and Reaktor uses both messages and circuits with converters from one to the other.... and vst singleparamArrayOUT could send [-1] in between arrays....

Have you tried addressing params through midi? I suppose that requires lots of internal mapping in plugs, and not all plugs support it.

[oli_lab]

that seems to do the trick

[sm_jamieson]

Rereading this, I have completely not dealt with the lfo param control issue!

I do SO miss Max's parameter control method here. Just send a 2 item array where item 1 is the param# (or name) and item 2 is the value.
Similarly, when a param is changed in the vst, you get a 2 item array out.

That could easily be added to the VST plugin-in module.
In fact it would be useful if all modules had this function. Then you could receive details of parameter changes over one "array" wire instead of lots of wires, but use the separate wires when needing signal processing rather than messsages. Actually, since several parameters could change in the same bloc, this might need to be extended to an array containing parameter number and value pairs, with the array as large are need be. A similar array input on all modules could be used to set parameters.
Of course at the moment that array only has data parameters, so this could not be used to set a text parameter for example.

Doesn't work very well with Usine's circuit model tho (as opposed to Max's message model...)

But Usine uses the message model with MIDI.... and Reaktor uses both messages and circuits with converters from one to the other.... and vst singleparamArrayOUT could send [-1] in between arrays....

Have you tried addressing params through midi? I suppose that requires lots of internal mapping in plugs, and not all plugs support it.

I think a "message" is simply an array that gets sent once and does not stay on the wire. And a converter to a message is just a create array module. The things missing to make this act like a message are

1. If cannot be received as a array then when then array items are extracted you can get a callback for one of them changed, but the other ones have not yet been updated. With a message you need to know that when you are told a message has arrived that all of its parts are there.

2. A message needs to be only sent once. Usine MIDI flow is like a message, but you have to manually delete it from the wire on the next bloc else it will be received twice.
It would be useful to have a parameter flag when the signal stays on the wire for 1 bloc and is then then wire is "disconnected" (like setting size to -1).

I think a "message" facility in Usine would be extremely useful and could be done in a way that does not add much overhead to the CPU. I might put some of this as a suggestion/improvement.

Simon.

[oli_lab]

This array out + comma text out is already there !
Or did I miss the point?

[sm_jamieson]

I'm not sure about woodslanding's particular issues, but I was interested the message / circuit concepts and a general way to reduce wires between modules when you do not need all the separate wires for signal processing configurations. It sounds like woodslanding is trying to do a similar thing.

[23fx23]

as far i understood big part the problem in is the wired array in. if one/any of the data in the array in changes, the vst module will scan/get ALL the values of the array in and update all internal values. so if a lfo is constantly setting one value in that array, the constant refresh kinda lock the other parameters as they also are constantly scanned/reapplied to the vst.

if the module had internal 'pass only if changed', it would be able to detect only the lfo param/params in the array that changed over last bloc, and update only it/them, the other values would not pass internally, and the user could still tweak other params on the ui with no 'fight' occuring. that seems the easiest mod to usine current implementation to me.

[gurulogic]

if the module had internal 'pass only if changed', it would be able to detect only the lfo param/params in the array that changed over last bloc, and update only it/them, the other values would not pass internally, and the user could still tweak other params on the ui with no 'fight' occuring. that seems the easiest mod to usine current implementation to me.

^this!

[woodslanding]

I don't know if this is what you need. If it doesn't work for you let me know. I thought a regular pass if changed module would do this as well, so maybe I'm confused.....

For some reason, 'force' is not working.... I can't figure out why.

Code: Select all

//Pass If Changed Array
//By Eric Moon Jan 2018

//GLOBAL VARIABLES AND TPARAMETER  DECLARATIONS
var arrIN  :TParameter;
var arrOUT :TParameter;
var forceIN : TParameter  

var arrMemory : array of single;//values of parameters
var arrChanged : boolean;

/////////////////////////////////////    
//INIT
/////////////////////////////////////    

PROCEDURE INIT();
BEGIN   
    arrIN:=CreateParam('array',ptArray);    setIsOutput(arrIN,false);
    forceIN:=CreateParam('force',ptButton); setIsOutput(forceIN,false);     
    arrOUT:=CreateParam('array',ptArray);   setIsInput(arrOUT,false); 

    arrChanged := FALSE; 
    setLength(arrOUT, -1);
END;    

/////////////////////////////////////     
PROCEDURE Callback(n : integer);
var i,count : integer;
BEGIN      
    if (n = arrIN) OR ((n = forceIN) and (getValue(n) > 0)) then 
    begin
        count := getLength(arrIN);
        setLength(arrOUT, count);
        for i := 0 to count - 1 do 
        begin
            setDataArrayValue(arrOUT, i, getDataArrayValue(arrIN,i));
        end; 
        arrChanged := TRUE;
    end;          
END;
                 
/////////////////////////////////////                      
PROCEDURE ProcessIdle();
BEGIN
    if arrChanged then
    begin
        setLength(arrOUT, -1);
        arrChanged := FALSE;
    end;
END;

[woodslanding]

yeah, maybe this doesn't help, as the lfo will keep the array out from ever being clear.

Oh well....

[oli_lab]

there is a subpatch "array has change" in the library

[oli_lab]

I'm still not sure I have understood your problem well, but I found an idea that may help : think relative instead of absolute !
modulate your parameters from the increment and decrement input of your fader.
so when you change preset should be good !?
At least, it's working well for my one hand sound tweaking simulator !

[23fx23]

here the two white overlays represent VST module diagram that we don't have access to.
adding an array pass if change on our side still generate an array that changes as seen by the vst arry in



we have an UI element of param0. if it changes, it updates the internal data. so far so good.
on input, say we prefer using array for conveniance. we set up an lfo constantly modulating value3. we feed that array to the vst module.

A) top diagram, current usine implemantation.
the array is analysed, detected changing, all individual array datas are passed to the internal stucture, overriding ALL current values by those of arry in, including value0

B) modified with 'INTERNAL' pass if change.
the array is analysed data by data, only the one that changed (here lfo val3) update corresponding value in internal datas. value0 is not affected.

In reality, that kinda normal, usine does what we ask it to do. but on a 'workflow' thing, its a bit of a pain.
so actually we are trying to counter with feedback schemas, that in several case can have a block latency in the loop making things quicly complex

my sugg to senso if reading for making things simpler, while *i suppose* not being overly complex changes to usine would be a modification of VST module:

_either use an internal pass if change shema like B;
OR
_add a new "param_need_import" array input of param size. it would be a boolean type where user specify for each id values from array in if it will be updated.
if user didn't fed an array, assume all need to be "imported" and use the 'legacy' curent schema.
if user fed an array, ie here the array would be filled with 0, exept on id3 iwould be 1, when the array in changes, it would scan that array id as well, and pass internally only value@ id3.
OR
_ add 1 new arrays in or variable size, that would list only params id to change, say 5-8-12. or here only 3. so on arrayIn changes, it pick only those IDs values from array in to the internal structure

[oli_lab]

thanx for taking the time to give more insights on the matter.

you'll always need a loopback if you want the array on the left to be refreshed when you tweak the knobs on the VST GUI, don't you ?

I'm not sure a delay of one bloc is a problem at data level (could be at audio level).

as for the screening of the parameters you want to modulate, that can be done with a mapper value module.

http://www.sensomusic.com/forums/upload ... lation.wkp

cheers

[23fx23]

yes sure in most case we still need a loopback, i didn't patch it here to simplify the 'first view' of the problem.

but not always. say i want to just add 5 lfos to 5 ids, (that will dynamically change so array is more conveniant than wiring individual pins).. the wiring would be much simpler without dealing with feedback. array out would recflect both Ui set values and values set by the lfo,
don't really need array in to be updated in that case for ex. as the arrayin would only update the lfo values internally, not the others that remain as were set by the ui. dk if make sense

there are cases when using busses that go outside of the patch somewhere else say 'gloabl managing' for a ui param then get back in where 1 bloc latency occur on the feedback data, so that can make crazy 'fight' loops .think some patch posted earlier by guru shown that problem or ill try to make an exemple. ie vst 'send' value 1 but next bloc it receive 0, so resend 0, get back 1 ect

i have to update usine to check the wksp, ill have a look thanks

[sm_jamieson]

_add a new "param_need_import" array input of param size. it would be a boolean type where user specify for each id values from array in if it will be updated.
if user didn't fed an array, assume all need to be "imported" and use the 'legacy' curent schema.
if user fed an array, ie here the array would be filled with 0, exept on id3 iwould be 1, when the array in changes, it would scan that array id as well, and pass internally only value@ id3.
OR
_ add 1 new arrays in or variable size, that would list only params id to change, say 5-8-12. or here only 3. so on arrayIn changes, it pick only those IDs values from array in to the internal structure

Yes either of these are better than internal pass-if-changed, which has its own problems if you want to enforce the same value as last time. With internal pass-if-changed, if you sent a value on the input, then the value was changed from the VST GUI or something, and you wanted to send the same value again on the input it would not be registered.

By the way, I have solved this problem before by sending a value that will be ignored by the end module, but will "reset" the pass-if-changed module.

[23fx23]

yes thats true, tho rather than what ive made on the shematic, it could compare with the 'true' internal datas array that would have been changed by ui,
like if arrayin[id] != datas[id] then import value. but agree feel more risky in some cases we might not have imagined. the other solutions seem more safe and modular,
preserving current way of working, just adding a new check if user new array size is >0, wich also has prob slightly less cpu/mem overhead for big arrays if not used.
good trick for out of range value

[sm_jamieson]

Anyone know if the plugin wrapper module included in the SDK is the one that is actually used in Usine ?
Anyway, the SDK PluginWrapper includes the following code which shows all parameters updated when any change:

else if ( Message->wParam >= offsetParamsArrayInOut && Message->wParam < offsetParamsNamesOut )
{
// sanity check in case array size != numOfParams InsOuts
int numOfArrayParams = std::min (numOfParamsInOut, (int) sdkGetEvtSize (m_arrParamsInOut));

// update all params
for (int i = 0; i < numOfArrayParams; ++i)
{
float oldValue = sdkGetEvtData (m_fdrParamsInsOuts);
float newValue = sdkGetEvtArrayData (m_arrParamsInOut, i);
if (newValue != oldValue)
{
pluginInstance->setParameter(i, newValue);
setModuleParamValue (i, newValue);
}
}
}

If the plugin wrapper is the one used in Usine, we could produce a User module to test some different types of logic.

[oli_lab]

if (newValue != oldValue)

that test for each parameters if it as change or not, and only change the ones that changed

[sm_jamieson]

Yes, I think that was a case of typing too fast and seeing what I expected to see !
Interesting.

[woodslanding]

I'm not sure a delay of one bloc is a problem at data level (could be at audio level).

In my experience, block delays are a big problem in data loopback, as you get 'jitter' where two different values chase each other around the loop, and the parameter never stops changing. This happens any time you use sends in a loop, and has to be accounted for. You can't ever have a completed loop with a delay in it, the loop must always be broken at some point.

[woodslanding]

Third example (example2waymap(alt)) is another approach where I circumnavigate the buses latency issue by having the plugin parameters kept in a local loop and sending the remote parameters data to manipulate the local loop directly. This would work fantastically except that I cannot even begin to comprehend how I would dynamically map the necessary index references and parameters from apprx 64 controller sources to their respective plugin destinations. This seems this would be extremely complicated so I doubt this is a solution.
http://www.sensomusic.com/forums/upload … alt%29.pat

Okay, I have run with this, and I think you will be happy with the results.

This is preliminary, but it is working well in my tests. Still left to do: mechanism for setting destination param via learn (but I have already figured this out elsewhere) and support for multiple vsts. This may be tricky... but I think it will be possible, if every vst has this script attached to it. You'll probably need to use renamable busses....

http://www.sensomusic.com/forums/upload ... thLFOs.pat

Try it out, see what you think.

cheers,
-eric

[woodslanding]

alright, I should have gone to bed, but I thought it wouldn't be too hard to get the multi-vst version working, and for once I was right!!

Cut out the poly object in the lower right and paste it wherever you want. You only need one of these, set the poly to 64, and you'll have all you need.

What remains is the wiring each vst needs to have. And each needs to have a different index.

Not tested much, but it's looking functional!

http://www.sensomusic.com/forums/upload ... thLFOs.pat

cheers,
-e

[woodslanding]

Okay, here's a wkp all wired up and working (although you will have to sub your vsts in....)

http://www.sensomusic.com/forums/upload ... erTest.wkp

Seems to work effectively for both vsts. I can't believe this actually works!

Thank you Gurulogic for the great starting point for this.

cheers,
-eric

[23fx23]

good job!, ideally if we get mousedown out of vst (and param_id its on^^eventially to simplify things), man could stop refresh in override of that one to allow ui take over
but all things are there. still think a vst module update would higly simplify, but already with just mouse down we could go head.