Page 1 of 1

Dealing with Acceleration in Automation

PostPosted: Thu Oct 20, 2016 5:08 pm
by chrisr
Good afternoon all-
I have an automation controller that travels a surface I am tracking. My issues are with the Ramp up/down times. How can I better adjust for this. Right now its pretty straight forward.

The input is 16bit DMX, I have a range of 10,000 to 50,000. This is translated via a Range node, that converts into X pos in PB. start of .5 to 5

My question is how have you all who have dealt with this, accounting for and the ability to adjust for the ramp up and ramp down. The ramp up/down is seen in the DMX value. But if the device in PB is quicker or slower in a linear fashion than the set piece, how have you all accounted for that.

With the Filter Prediction node combined with a delta node, I see promise. But the issue I have seen, I can get it ahead to help speed up. At the end of travel, the ramp down happens, and the device layer gets ahead of the screen.

If there is something that documents automation with Widget Designer, I would love to read. I've looked around the Forum but have not been able to find what I am looking for.

My apologies for not quiet understanding this, its a new one for me.

Thank you all for any help.

Re: Dealing with Acceleration in Automation

PostPosted: Fri Oct 21, 2016 11:12 am
by schoissi
not sure if this will help,
have you tried to set the Parameter Value Smoothing in PB to Zero, or at a lower value?

Re: Dealing with Acceleration in Automation

PostPosted: Fri Nov 11, 2016 6:44 pm
by chrisr
All, thanks for the help. I want to add this to the thread. Malkuth23 shot me some hints via email. I asked if he'd mind my posting them here. Also Roman and Dennis shot me some hints. Here they are:

Thanks malkuth23, schoissi and Dennis@Coolux!

1. You are thinking in the right direction - ramp times, smoothing and prediction was something that I used to do using 12 or 15 nodes. It now it is all in 1 node "Prediction'. Connect the Delta Node (Math structure below) from the original source if it is available otherwise create a delta node and tie it back into the prediction node. experiment to find the correct multiplier. Start with 0.1 I find they tend to need to be reduced.

2. Up the smoothing because tracking it a messy game and it is hard to make it look graceful.

3. PB and WD smoothing work a bit different. PB smoothing is a bit prettier, but WD smoothing (jitter reduce node is what I used) can be adjusted so much easier... Your call, but I would start with WD smoothing and see if it works for you.

4. There are a few places to watch for smoothing, I ended up using a mix of smoothing between WD and PB, I reduced the smoothing in PB from 500 down to 100, and used the Jitter Reduce after the prediction node. I ended up with a pretty good result.

Delta Node Math structure: PredictedValue = CurrentValue + (Factor * DeltaValue)

I found that being able to see what the delta was doing helped me (Visually) as well, so I made a FLOW Rate node structure, that looked at the Delta of the Automation Feed which was incoming via an ArtNet node. Then took the Delta output and applied it to an angular Display. I could visually see the Delta node respond to the Ramp happening, and how choppy the automation feed is. smooth angular display means your input is smooth.

Re: Dealing with Acceleration in Automation

PostPosted: Mon Nov 14, 2016 11:58 am
by Dennis Kuypers
Hi,

can't wait for the new Widget V6 to introduce Composite Nodes!

Dennis

Re: Dealing with Acceleration in Automation

PostPosted: Tue Nov 15, 2016 6:52 pm
by chrisr
Dennis,
Composite Nodes? Is this the Node Nesting I've heard about, you can build a set of nodes, then place them inside another node and define its inputs, and outputs?

Cheers!

Re: Dealing with Acceleration in Automation

PostPosted: Wed Nov 16, 2016 10:48 am
by Dennis Kuypers
Hey Chris,

Yes indeed. The fun part is that they are reusable and changes you make to them will apply to all the places you used them.

Regards
Dennis