BrainModular

A large part of the functionality that I apply in Usine is as an FX processing rack for my external instruments, the majority of the FX I use being VST, and of course some fun stuff that can be done to manipulate audio within Usine. I do find that access to VST parameters is a bit cumbersome, at least in the patching format. Maybe there are already better ways via IML and Script, but these methods elude me unless someone else creates them.

When I am feeling inspired and load up some VST's to process my audio, I find the amount of patching I need to do to integrate two way VST parameter manipulation into the inspiring moment is a bit uninspiring. I have been patching some methods which I am quite proud of for learning controls direct from VST and receiving parameter names for the control, and they work well enough once everything is wired , but they are both resource hungry methods, as well as complicated to wire with multiple VST's. A template format format works for workflow improvement, but is not as open ended for spontanious creativity as would be if parameters interfacing were more easily accessible.

Each of the several methods already available in Usine are handy for different scenarios, but are not always immediate as would be ideal.

If Usine could offer direct (2 way) mapping or parameter linking of controls to VST parameters (similar to midi mapping) without any additional patching, this would be fantastic and really help open Usine up as a more immediately accessible VST host. Ideally the mapping could also inherit the parameter name to the control as well as even the VST name would be ideal.

I wouldn't bother bringing this up if it seemed far fetched as I am getting along ok as is with the existing functionality, but it seems like an entirely feasible possibility and would really help streamline the workflow for us heavy VST plugin users.

How about something even as simple as a "VST Params" Module available in single or multi params mode with a drop down list of all currently loaded VST's in a workspace, and a second drop down list of all parameters for that VST, a name outlet for the VST and for the parameter, and an input and output pin for data i/o? STill some light patching patching required for two way parameter flow (ie: pass if change and a couple of wires for each control, but would still greatly simplify and centralize the process for clear overview of mapped parameters throughout a workspace.

hope I'm not OT :
you can use the ctrl+shift key and then get access to all parameters via faders.
then use midi learn to control the desired parameters.
I know the ctrl+shift trick is not totally working with HH2 but should be fixed in HH3

cheers

oli_lab wrote:hope I'm not OT :
you can use the ctrl+shift key and then get access to all parameters via faders.
then use midi learn to control the desired parameters.
I know the ctrl+shift trick is not totally working with HH2 but should be fixed in HH3

cheers

I'm not sure what this ctrl+shift mapping is? Do you mean show all vst parameters? If so I had no idea that they could be midi learned via the module settings, if that is what you mean?.

Even so, I would still propose my suggestion, it would allow for a very flexible and easy to manage control over mapping and parameters interaction, especially if parameter maps, names etc. could be easily reorganized in realtime and managed from a central location.

Lets say for example, you wanted to have one faderbe able to control and switch between controlling any VST parameter from several VST's in a workspace. With midi learn, you would have to midi learn a unique CC# to every parameter you may want to be able to switch between controlling with the one knob, and then manipulate a create midi module to switch CC# outputs to match each learned VST parameter. With this method, the fader would not receive a feedback value from the VST parameter, nor would the name of the controlled parameter be updated on the fader.

With a hypothetical "VstPArams" module, there would be real time two way communication between the VST and the fader, and no mapping each vst parameter one by one needed, merely selecting the parameter from drop down menu, or better from touching the control on the VST to learn but ideally still having access to access selected parameter via interface for realtime switching .When the destination VST parameter for the fader were changed, the current value from the VST could be loaded as well as the parameter name. I have already patched for this functionality, but it could be much more streamlined and easier accessible with a dedicated function or module built in Usine.

Hi Guru,

Have you use the DAD VST Tool Addon yet that I made?
It has 8 knobs, and all parameters are exposed in list boxes and drag and drop to assignable knobs for CC Learn.

I was just curious if this was what you were looking for?

-s

Sephult, yes I have used the DAD patch, and yes it does allow an immediacy for VST parameter access that offers an immediacy of control probably suitable for most users, and it does definitely address the simpler form of immediacy that I brought up in my original post,
however I quickly realized that didn't adequately describe the type of functionality I was thinking of which brought me to suggest the module approach to directly accessing parameters from any number of VST's which would allow a much deeper level of parameters mapping and manipulations.

With DAD as is, yes great for immediate basic control surface access to one or two or even several VST's, no complaint there.
When I get into a 16 or even 32 song workspace with different VST configurations for each song, limited screen real estate for visible controls, the desire to dynamically change destinations/modulation variables and receive visual feedback for my mappings per song/preset from my tiny midi controller, and the logistics of keeping the resource use of my workspace to manageable levels, this is where I quickly run into the limitations of currently available solutions.

I have already spent an absurd amount of time patching some fairly functional (and somewhat resource hungry) workarounds (originally inspired by DAD) Where things get really challenging for my methods to work in a workflow friendly way are integration of multiple VST's. Each VST added must have it's parameters concat array into one large array to pick index/learn parameter from, then array extracted to send value to the proper parameter VST, if there is any unusualness to the VST params (ie: empty no name. this breaks, if I swap out a vst for another with a different number of params, this breaks. My only solid solution is using a vst chainer with fixed number of params output but even that is full of shortcomings.

All of this messing around has made the light bulb go off in my head. Why can't Usine simply have a system level selection of multiple source VST's parameters available for example from a module? Many VST hosts and chainers have this basic function (yes, I have pretty much demoed them all), so why can't it be so easily and done even more powerfully in in Usine?

I am assumptive that it can't be that hard to have a module in Usine with an inlet (or multiple) to select any VST from within workspace, an inlet to select from the list of parameters for a specific VST (with ability to learn direct from VST, an inlet and outlet for the parameter value, and an outlet for the VST name and the parameter name. Such a thing would open up so much patching flexibility, and make advanced use of VST's workflow so much smoother.

Anyways, I'll leave it at that and get back to my tangled web.. Maybe for HH v4..

(edit: would just like to add that the concept of module based parameter access could also be applicable to dynamic mapping of interface items parameters within a sub patch )

So after countless hours of patching patching patching and bug hunting and more patching I am coming up with a solution for vst parameters mapping etc and accessibility that is working pretty fantastically and I am pretty darned proud of so maybe don't create suggested VST params etc access module because then I'll have to redo all of my patching to save a few percent of cpu and broaden the general functionality and ease of use a bit.. haha

(yes, I will be sharing the fruits of my labors when the time is right )