"Sidechaining" data from one plugin to another

[aviloff]

MacOS 10.15.7
Cockos Reaper

I'm setting up a multitrack project in Reaper, each track has a Camomile plugin loaded. Each of these plugins sends automation parameter data to an external program via OSC commands. Currently I need to create a separate [netsend] in each of the plugins, while in a similar Pd patch it would be just one [netsend] receiving messages from everywhere via a single [receive].

As there are performance issues already with multiple instances of these fairly simple plugins, things would get worse if I were to control parameters externally via OSC commands. I would then need to equip each of the plugins with a separate [netrecieve], and assign a separate port number. This would complicate things a lot and might become inefficient.

Since you are using the $0 variable in variable names in most of your demo plugins, I was wondering if non-$0 variables could be used "globally" within the scope of a DAW running several plugins. For example, plugin A on track 1 would [send x] to the [receive x] found in plugin B on track 2.

Such functionality can expand the scope of Camomile's implementation.

[pierreguillot]

Hello,

I'm not sure to fully understand the problem and/or how the suggested change would fix it. Sorry if I misunderstand, I'll try to answer to your issue:

As there are performance issues already with multiple instances of these fairly simple plugins, things would get worse if I were to control parameters externally via OSC commands. I would then need to equip each of the plugins with a separate [netrecieve], and assign a separate port number. This would complicate things a lot and might become inefficient.

How do you know that it would get worse or that it might become inefficient? (And I don't understand why you need to use [netrecieve] if you want to send data to an external program). Anyway, you should know that the examples given with Camomile don't have a lot of parameters so the patches were not optimized but you can change the way you receive parameters from the DAW to be more optimized (using only one [receive param] for instance).

Since you are using the $0 variable in variable names in most of your demo plugins, I was wondering if non-$0 variables could be used "globally" within the scope of a DAW running several plugins.

No, I don't think that's not a good idea. All the plugins will then send and receive messages, parameters, etc. to/from all the plugins. It will break all the patches. And as plugin instances can already communicate using objects such as [netsend] and [netreceive] so I don't think it would be useful.

If you want to improve the performance of the plugin, please share your patch and we'll try to find a way to do it :)

[aviloff]

Hello Pierre!

Thanks for the quick response!

How do you know that it would get worse or that it might become inefficient?

I thought that a [netsend] and [netreceive] on each plugin is too much, but realising the initial idea is manageable without sending/receiving parameters using PD's [send] and [receive], you are right.

And then from what you are saying I assume that the use of $0 in variable names is generally superfluous.

If you want to improve the performance of the plugin, please share your patch and we'll try to find a way to do it :)

I created a demo patch that covers the basic functionality I am trying to achieve. The plugin not only sends parameter values as OSC messages but also receives messages that control the parameters. There are comments that I added, with additional suggestions for Camomile. It would be great if you could have a look!

[pierreguillot]

Why not simply doing something like that instead of param.get.multi?

Do you simply want to visualize the changes on the sliders when you receive OSC messages or do you want to changes the parameters of the DAW (to create automation for instance)?
Same question for the sliders, do you want to change the parameters when you click on it or is it simply visual feedback of the current value?
What do you mean by "would be great if these send/receives could be handled dynamically"? You should have a look at the help patch, you can change the symbol of the [send] object dynamically. And you can also use dynamic patching. If I remember well someone did a tutorial for that. You can ask on the Pd mailing list, the forum, the Facebook group, etc.

[aviloff]

Thanks for the suggestion, the [change] object does help with optimising the flow of parameter data in this case, when each parameter is only forwarded to the network.

With this modification, the patch now works just as intended, and this includes

• writing automation by dragging over the slider and number box,
• writing automation by receiving messages over the network
• displaying changes made to the automation envelopes or over network

Sometimes it freezes on a value in latch mode after editing the value by mouse-dragging and then pressing play twice. This rewrites automation when it is undesirable.

One other thing I was pointing out is that the Shift + drag on a slider in Camomile's interface does not switch it to high-accuracy fine adjustment mode, as it does in Pure Data (I use version 0-51-1 currently for testing).

[pierreguillot]

Sometimes it freezes on a value in latch mode after editing the value by mouse-dragging and then pressing play twice. This rewrites automation when it is undesirable.

This might be related to this issue that will be fixed for v1.0.8. But if not, feel free to create an issue for it.

One other thing I was pointing out is that the Shift + drag on a slider in Camomile's interface does not switch it to high-accuracy fine adjustment mode, as it does in Pure Data (I use version 0-51-1 currently for testing).

Please create a specific issue for it.

If everything else is okay, please close this issue.

[aviloff]

Thanks!