Distributing Control Data

Hi All

I am at the beginning of a new project and will use that to get properly into gamma.

The very first step for me, is to re-implement my old performance tool and for this I need to be able to control parameters all around in my system.

Is there a way I can make a system where I kan have a kind of matrix where I can patch all sources to all destinations?

eg. I would like to control saturation in a Process Node but I will use multiple instances of it so I want to use midi controlers 9 and 10 respectively. Ideally the saturations would appear in this system and it would be simple to patch the desired midi controllers to the correct destinations.

This would also make it easier to create a UI for it

I think in your case it would be good to have a look at this tutorial:

Basically you would create a master class that holds the state and all settings of your application, which you then can get and set anywhere else in your program. Took me a while to grasp the logic, but its really worth it.

1 Like

Just to understand your question

-Are you looking for a good way to transport control data to various destinations inside your gamma patch?
-Are you asking how to make a gamma application that is a UI matrix in a render window for patching control data to attributes?

@tobyk I am looking for the transport of data. UI will be static, in the sense that it will not enable re-routing of data.

maybe there will not be a GUI at all, and all control will be via midi, OSC and config files

I think this can be quite simple.

-Somewhere at the top of your root application patch you have your MIDI (or other controller) input process.
-This process contains the ‘raw’ input nodes and writes the relevant data (Eg Midi CC X through Y) to a custom datatype ‘ControlData’.
-If the entire input data state is available every frame from the midi nodes you can just use the Create operation and create a new ControlData every frame.
-The custom datatype stores this data however you like. If conceptually the data isn’t assigned to anything store it in pads ‘controller 9’ ‘controller 10’ or ‘ControllerSpread’. BUT if the assignment already exists you can already call them ‘saturation’ etc.
-This datatype should probably be a RECORD and each of those attributes are the names of the pads.

-Back on your root patch pass this instance of ControlData to every downstream process you would like to control
-Inside your downstream processes you can use a Split operation on the ControlData instance to access all the pads. In this case all the outputs are exposed and you just patch the pins that are relevant.
-Or you can create custom operations ‘GetSaturation’ ‘GetHue’ that are more meaningful and only expose the output pin you need at that time.

If you have input data from controllers that is not available every frame than you need to have a slightly more sophisticated input process. An example would be OSC messages arriving at different times,

In this case you cannot create a new ControlData every frame.
-Instead you store the ControlData instance in a pad.
-On frames that new data arrives you should execute an update on that ControlData, you can make specific operations that just update the relevant arriving data. Eg ‘SetFader5’ ‘SetVolume’ etc.