Add Tags to Parameter

It would be nice to be able to attach some intel onto parameter inside of the “Customize Component”-Dialog like the tag-system for components.
Missing this for some dynamic-interfacecreation purpose.

1 Like

Curious what you’d use this for. In case Toronto decides to add it, it would be nice to know specific needs.

For my DMX-Controlled Mediaserver i currently have a system were I build the UI inside of the components with a table. The main reason for that is to specify the adress-offset of the parameter and if it is 16 or 8 bit.

With this feature I could build the components just with custom-pars and have the complete UI/DMX-Interface be generated from the parameters without additional defining via a table.

Another one would be for my preset-system to define if a parameter snaps or if it should fade. I suppose I could just build different pages for that but then I would loose my otherwise existing structure.

I see. As an interim fix, maybe you could just auto-generate a tableDAT (or multiple) with any info you need.

Hey just wanted to bump this request. I think it would be really useful to have the ability to tag parameters.

Often times I find myself wishing that I could store more data to parameters in general. Adding the ability to set new attributes on the par class with the setattr method would be my ultimate RFE. Or maybe it would make sense to add the store and unstore methods like the op class has.

To give an example of a practical application, I’m working on a GDTF Importer (WIP) that automatically generates parameters for all of the DMX channels a given lighting fixture has.In some cases a particular channel might have preset values that would make sense to expose as pulse parameters. Rather than building a large table of values associated with pulse parameter names it would be much cleaner to store the relevant information in the parameter itself.

As well, keeping track of which parameters to delete when loading in a new fixture would be much easier if you could search through custom parameters by tag. Sure, you could delete all pars in a given page but if there are parameters you’d like to keep on that page then you need to keep track of their names elsewhere.

Another example is defining which method of an extension a pulse parameter should call from a Parameter Exe DAT’s onPulse method. I see a lot of beginners doing something like this:

if par.name == 'Somepulsename':
    ext.MYEXT.DoThis()
elif par.name == 'Anotherpulsename':
   ext.MYEXT.DoThat()

another popular method is to do something like this:

pulse_lookup = {
    'Somepulsename': 'DoThis',
    'Anotherpulsename': 'DoThat'
}
if par.name in pulse_lookup.keys():
    getattr(ext.MYEXT, pulse_lookup[par.name])()

or my current workflow which is to add methods to my extension that match the par names (usually with a bit prepended to the name like pulse_ ) so my onPulse callback would look something like this:

p_name = 'pulse_' + par.name
	
if hasattr(parent().extensions[0], p_name):
	getattr(parent().extensions[0], p_name)()

This way you can keep everything in the extension and never have to edit the Parameter Execute Dat.

If the par class allowed you to set custom attributes where you could, for example, store a reference to an extension method in a custom par attribute called onPulse, you could do something like this:

if hasattr(par, 'onPulse'):
   getattr(par, 'onPulse')()

At the end of the day there are ways to work around not being able to store any information to parameters but it always ends up feeling a bit convoluted. I think it would really clean up the workflow and make programming custom component much faster and easier to understand.

4 Likes

+1

Managing lots of custom pars becomes tedious. The ability to categorize them by tag would be very helpful for more complex projects.

+1 for at least simple string tags and, even better, the ability to attach any python object/s to a par object.

This would be really useful for RayTK. I’m currently using internal DAT tables to assign metadata to parameters, but being able to include it directly on the parameters themselves would simplify things a lot.

1 Like

In the interim, can you use the neglected Help string of a parameter to store ancillary data?

python >>> n.par.Abc.help
‘’
python >>> n.par.Abc.help = ‘[3, 5, 7]’
python >>> eval(n.par.Abc.help)[2]
7

1 Like

plus one for this and the ability to select the tagged paramters in a parCHOP would be peachy

1 Like

+1, dunno if tags or a full-fledged storage unit would be best.