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..??
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
Last edited by 23fx23 (2017-10-07 04:13:21)
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
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
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?
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.
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
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?
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.
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
Last edited by gurulogic (2017-10-11 01:02:28)
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
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.
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?
Last edited by woodslanding (2018-01-13 00:40:19)
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.
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.
Last edited by woodslanding (Today 07:59:56)