Internal Parameters - Holding Data in Components

“Internal Parameters” is a useful place to hold variables and states inside a component.

Instead of creating custom parameters on your component that are exposed to the outside, you create parameters inside the component to hold data more privately.

NOTE: This post is shortened as Internal Parameters are now documented in wiki pages: … Parameters
and … Parameters


Hi greg,

Thank you for laying this out, It is certainly something I would like to understand better, I would love to start using this technique as I am in general a huge fan of custom parameters… Ive been digging around your example and readme and are left with some questions:

1 - Would this technique be recommended in-terms of optimization / speed with highly dynamic parameters? i.e. animations curves etc.

2 - What is the purpose of these Dats? in the “empty” internal parameter setting base:

internal par explain.PNG

3 - In what circumstances is eval() needed? can you explain this further:

4 - Has anyone done any more speed tests with this technique?

Thanks Greg!

(Responses now embedded in the wiki pages)

I trimmed down this thread on Internal Parameters, not because almost nobody’s given any feedback on it (thanks Timesquid), not because it’s been abandoned, but because there’s now a wiki page that covers it nicely: … Parameters
and … Parameters

and there’s a simpler example .toe file.

I am finding that as my components grow from 20 nodes to more, and they take on more logic and states, Internal Parameters becomes useful and helps me avoid writing extensions. They are a more visual way to hold, change and observe data in components that I enjoy working with. So this is also a reminder that this technique does exist, and I’m looking forward to critique and other observation about it.

Holy smokes that’s slick.

Looks like you can also set the value of an internal par with python:

op( 'project1' ).ext.Grid.Curbin = 2

You can also do neat tricks like setting your internal pars to their default vals:

op( 'project1' ).ext.Grid.Curbin = op( 'project1' ).ext.Grid.Curbin.default

I can think of a ton of great uses for this. Thanks for pointing it out Greg!

Yes, Internal Parameters have all the benefits of parameters in general: … Parameters

Hi Greg - I somehow only recently discovered this and it is honestly blowing my mind. I often write extensions to handle custom parameters and am always looking for the most efficient/non-obtrusive way to hold data so this is perfect - thanks! I hope you guys continue to develop down this route of optimizing parameters and storage techniques.

One question, on the wiki you note…
COMING SOON: a parameter type which is a python object, so you can hold a dictionary in a parameter.

I’m wondering if you are still pursuing this and/or will be in 099? This would possibly be there greatest thing ever…

Secondly, it would be great to see a Derivative wiki page on best practices and/or examples for rolling your own classes for parameters as it is very powerful and it seems no one is using.

Great work!


I’m Diving into experimenting with internal Parameters and wondering is it possible
to access or set this outside of the parent component ?


External access via op(‘path’).ipar.Effect.parname was not part of the original design (strictly internal). But we’ve been considering for a while making it externally available in the same way, but have not decided to to so yet. The only way is through something like op(‘path’).par.iop1.eval().par.parname, but that is clunky. Same goes with using the Internal Operators externally op(‘path’).par.iop1.eval().

1 Like

Hi Greg, any plans still to make external access of iops/ipars available?