Sensomusic

#1 2017-10-06 20:53:18

gurulogic
Community

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
http://www.sensomusic.com/forums/uploads.php?file=Example2waymap.JPG

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
http://www.sensomusic.com/forums/uploads.php?file=example2waymap%28wired%29.JPG

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
http://www.sensomusic.com/forums/uploads.php?file=example2waymap%28alt%29.JPG

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..??

Offline

 

#2 2017-10-07 01:25:43

23fx23
Community

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 02:13:21)

Offline

 

#3 2017-10-07 07:06:06

23fx23
Community

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

Offline

 

#4 2017-10-07 08:01:48

gurulogic
Community

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 :)

Offline

 

#5 2017-10-07 16:38:01

23fx23
Community

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?

Offline

 

#6 2017-10-07 16:59:06

gurulogic
Community

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.

Offline

 

#7 2017-10-10 07:52:27

gurulogic
Community

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

Offline

 

#8 2017-10-10 10:50:11

23fx23
Community

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?

Offline

 

#9 2017-10-10 21:23:53

gurulogic
Community

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.

Offline

 

#10 2017-10-10 23:01:27

gurulogic
Community

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 :)

http://www.sensomusic.org/forums/uploads.php?file=paramsfbgood.JPG

Last edited by gurulogic (2017-10-10 23:02:28)

Offline

 

#11 2017-10-11 07:18:16

23fx23
Community

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 ;)

Offline

 

#12 2017-10-11 18:45:10

gurulogic
Community

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.

Offline

 

#13 2018-01-12 23:25:46

woodslanding
Community

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-12 23:40:19)


Custom i7 5775 ITX build, Win10, Babyface, touchscreen
Custom 2 manual midi keyboard
Usine, Kontakt, Reaktor, Synthmaster

Offline

 

#14 2018-01-14 04:53:10

gurulogic
Community

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.

Offline

 

#15 2018-01-16 06:56:58

woodslanding
Community

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

Last edited by woodslanding (2018-01-16 06:59:56)


Custom i7 5775 ITX build, Win10, Babyface, touchscreen
Custom 2 manual midi keyboard
Usine, Kontakt, Reaktor, Synthmaster

Offline

 

#16 2018-01-18 06:40:44

gurulogic
Community

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

Offline

 

#17 2018-01-19 07:47:24

gurulogic
Community

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

Offline

 

#18 2018-01-25 05:15:26

woodslanding
Community

Just downloaded it, I'll take a look!


Custom i7 5775 ITX build, Win10, Babyface, touchscreen
Custom 2 manual midi keyboard
Usine, Kontakt, Reaktor, Synthmaster

Offline

 

#19 2018-01-28 17:10:32

oli_lab
Platinum Member

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


http://oli-lab.org

Win7 I7/32GB RAM  - RME RayDat - Focusrite Octopre MKII Dynamic - OSC capable interfaces

follow OLI_LAB adventures on Facebook
http://www.facebook.com/pages/OLI_LAB/3 … 506?v=wall

Offline

 

#20 2018-02-02 18:09:16

woodslanding
Community

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


Custom i7 5775 ITX build, Win10, Babyface, touchscreen
Custom 2 manual midi keyboard
Usine, Kontakt, Reaktor, Synthmaster

Offline

 

#21 2018-02-04 03:55:05

woodslanding
Community

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.


Custom i7 5775 ITX build, Win10, Babyface, touchscreen
Custom 2 manual midi keyboard
Usine, Kontakt, Reaktor, Synthmaster

Offline

 

#22 2018-02-04 12:55:18

oli_lab
Platinum Member

http://www.sensomusic.com/forums/uploads.php?file=vst%20manip.PNG

that seems to do the trick


http://oli-lab.org

Win7 I7/32GB RAM  - RME RayDat - Focusrite Octopre MKII Dynamic - OSC capable interfaces

follow OLI_LAB adventures on Facebook
http://www.facebook.com/pages/OLI_LAB/3 … 506?v=wall

Offline

 

#23 2018-02-05 10:22:16

sm_jamieson
Platinum Member

woodslanding wrote:

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.

woodslanding wrote:

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.

Offline

 

#24 2018-02-05 12:19:03

oli_lab
Platinum Member

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


http://oli-lab.org

Win7 I7/32GB RAM  - RME RayDat - Focusrite Octopre MKII Dynamic - OSC capable interfaces

follow OLI_LAB adventures on Facebook
http://www.facebook.com/pages/OLI_LAB/3 … 506?v=wall

Offline

 

#25 2018-02-05 12:41:37

sm_jamieson
Platinum Member

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.

Offline