Accessing Rack Plugin sub-parameters

Tracktion Engine
1

How might we go about modifying the parameters of internal plugins contained within racks?
I fully understand how this is to be done when a series of plugins are loaded onto a track.

auto delayPlugin = sendTrack->pluginList.getPluginsOfType<te::DelayPlugin> ()[0];

I’m unsure of if/how the node parameters are exposed via the rack system.

Let’s say I have a rack unit with a single internal effect, called “wrapper”.

Aux Return #2
Wrapper Tracktion11
Volume & Pan Plugin
Level Meter

How would I go about modifying the plugins inside the wrapper programmatically?

2

It’s the same as you would do for any other plugin, you just have to get the plugin from the RackType and dynamic cast it to the class you know it is via RackType::getPlugins or RackType::getPluginForID

4

I ended up using this to obtain the RackType from the Rack Instance. I just assumed there would be a getter for it.

            auto rackType = rackInstance->type;
5

You don’t really need a getter if the member is exposed.

6

It’s more of an intellisense & autocompletion related benefit.
I start typing “get” and I know what can be obtained from it.

What is the reasoning behind using the term “RackType”? I found it confusing, especially when considering how the term “type” is used in a different context in the example “PluginType”.

7

Yeah, it’s a different style, but you can’t really rely on typing “.get”, think about property based programming.

RackType maybe isn’t the best name but naming is hard and we’re stuck with 25 years of legacy. Still, it’s a “type” of “Rack” in an Edit which can have multiple “instances” on tracks.

8

You could rename the type and forward a typedef / using to the deprecated one. I think especially in C++ it is quite the benefit of doing that to keep everything tight.

9

True, but I don’t have a better name to replace it with.
That also doesn’t update variable names etc. Just a bit of effort for something that’s not really a problem.

2 Likes