Variables on custom parameters no dirtying

Issue:

  • Use a variable as an expression on a custom parameter
  • The parameter value is only set to dirty when the container viewer is active in the network view

How to reproduce?

  • Open attached example
  • An lfo updates the variable value through a chopexec.
  • The variable is passed as an expression to the container1
  • Switch off the viewer of container1 => update of lfo values stops propagating
  • Same thing happens when you switch to perform mode

Workaround?
Use the chop value directly (or the dato1 in the local container) for the parameter instead of the variable.
NewProject.toe (4.31 KB)

I don’t think this is related to Custom Pars, I think this is a variable issue.

If you instead reference your LFO val in your custom par then the displayed values do update in perform.

I’m not a huge fan, personally, of using touch vars for things that need to update every frame - you might instead use the path to your CHOP as a variable, and then build a ref:

# something like this to store the path to your CHOP: parent().setVar('chan1', op('lfo1'))

# this as your expression in your custom par: op(var('chan1'))[0]

Both of the above approaches work as expected.

Hi Matthew,

thank you for your answer and the nice little trick with storing the operators location.

In my project the variables are mostly driven by a setup ui. I use variables for two reasons:

  1. I want to be able to save/load the variable state to an external file. (Just discovered that it can also be done with a file in and file out chop).
  2. The setup ui also needs to set some values that are normally received from an OSC in chop. I did not find a way to safely override chop values coming from two sources. The override chop always holds the last updated and not the last cooked value.

Example:
OSC in chop and “setup” chop are connected to an override chop.
osc in value: 1
‘setup’ chop value: 0
override chop value: 0
If now the setup wants to set the value to 0, the override chop will not change it’s value, because the setup value did not change.

Is there solution to solve this with chops only?

Hmmmm…

A CHOP only approach here is a little more complicated than is ideal. You could use an info CHOP to find the absolute cookframe for your ops, then use a logic CHOP to select the greater val, then use that to drive a switch CHOP or the pulse par on a Constant CHOP. All of that, however, seems like more work than using a bit of Python to get there.

Is there a particular reason it needs to be all in CHOPs?

For me CHOPs seem to be the TD primitive for frequently changing values.
So it seems logical to first try to solve it using CHOPs.
But I did not find a way to solve it, so I used variables. Having one place where all the current state lives and can be inspected seems like a sound way to organize a complex project.
Variables worked good until I tried to split up logic into reusable components/containers + custom parameters and I encountered this bug.

Now I’m considering implement a python only way, that sets the values directly on the operators. I would use a routing table that contains channel name, destination operator, and parameter name. If I add a little extension to containers that need to set values through the routing table, the ergonomics should be similar to variables.

I made some testing to see the performance characteristics of this approach. I see a 0.05ms execution time for each channel that changes. I can actually see the difference between this approach and setting chop channel references on the custom parameters in the total cpu processing time. If there are not too many channels that change with each frame, I still think this approach is worth it.