Re: [Openfx-developer] kOfxParamTypeList

[Pierre J. <ja...@re...>]

On 7/19/2010 6:36 AM, fab...@fr... wrote:
> Hi,
>
> I would like to propose an important new parameter type : kOfxParamTypeList, which can really improve the openfx possibilities.
> Hosts could use something like a listView (in Qt terms) to display the list of parameters. This listView can be a treeView with a list of list.
> A simple example, kOfxParamTypeList<kOfxParamTypeDouble2D>
>    
I am all for it as I requested similar before - not the same - (calling 
it then predefined array of parameters versus completely dynamic)
I see we forgot a sort of parameter array group type in 2.0 list

The distinction I see is you suggest "Only the number of parameters or 
group of parameters inside will be dynamic."
while back then I tried to separate fully dynamic from a growable block 
of parameters (with some host provided Add+, Delete-)... so where group 
count changes but not number of params per instance as a distinction.
= it would be better to be able to add a variable list of parameters per 
such "Add" block instance, but I am just not sure every hosts can do that.
Rethinking this a bit, perhaps it's just a matter of the host telling 
you so one knows in the "Add" callback a fixed size group is autocreate 
and all you need to do is perhaps change some defaults (e.g names of 
some params, value of color,...), and then so possibly use the 
hide/disable mechanism for these parameters at fixed slot to represent 
the same when variable size array is not possible?  OR the "Add" 
callback is for you to fill with an arbitrary parameter create list then 
probably based on some other menu or something in the plugin.

Also what is the largest number of parameters per block you envision 
would make sense, I am worried about this being robust in 2D UI layouts 
- for example is it reasonable / useful to cap a max like 10-15 
parameters (some numbers) per such group?

- pierre

////////////////////////////////////////////////////////////////////////////
I repaste some highlights from
"V2 Expansions - dynamic parameter creation" may 2005 thread
below


"
Hi All,

dynamic parameter creation has been requested by various people, but 
nobody has put forward a spec or the modifications/extra suites required 
to do it.

I think it is a good idea, however I'm not going to do the work in 
defining it, as I have enough (unpaid) OFX work on my plate right now. 
Unless, of course, someone wants to trade redocumenting the API for 
defining the suite.

So, over to one of you to come up with a spec and a OFX suite to do it. 
My one suggestion is that we break the V1 parameters suite and provide a 
new V2 suite to accomplish this.

b
"

Pierre says primarly interested in blocks of parameters
"There is two types of dynamism, pre-defined and completely dynamic..."

Abstracting Array of Parameters idea here:  A mechanism with Add, Delete 
that comes with a menu (1,2,3,4,5...), or a scrollable list or another 
way to enter the proper one, and a block of parameters (same usual 
parameters supported by host). The xml ressource, defaults,.. could be 
shared for each block. API wise a way to loop all the current arrays 
(getNumMembers, for i to NumMembers, for i to NumParams get...). One 
fair host side UI implementation could be a box showing the current 
selection parameters and not the other instances of the list. (showing 3 
but not 1,2 and 4,5...).  This works very well at least for 2D geometry 
etc...

Bruno Nicoletti <br...@th...>  5/4/2005 12:29 PM:
"
I was just drafting a reply to Pierre's post and yours answered some of 
my questions.

Firstly we already do have show/hide available under OFX.

How about this for a spec...
     - parameters can be declared to be "list" params at plug-in 
description,
     - parameters that are "lists" can have elements added or removed 
from an instance dynamically under plug-in control,
     - using the current "group" param, you can declare a group param to 
be a list, where adding or deleting to it creates a new set of params in 
the group.

So for your case (assuming we add a rotospline param type) you would 
declare a group to contain a spline and the other associated bits you 
want. The plug-in would have push buttons to add/delete sets to the 
group, voila you get new rotos as you need them, with the extra bits on 
the side.

If the listing capabilities only worked on non-grouped parameter types, 
you could still have it work, simply by declaring the N params 
(including the roto) you need to be lists and doing the add/delete to 
each of them when the user hits add/delete.

Some glue needs to be thought about and host developers need to be 
consulted, but is this what you would want?

Does anybody out there currently want to be able to create arbitrary new 
parameters on the fly and which can't fit into this scheme?

Would any host manufacturers have a problem with this list scheme?
"

Gary Oberbrunner <ga...@ge...>
"
Peter Litwinowicz wrote:
> I'm still very unclear about what you propose as a list and what you 
> propose
> as a group.  Can't we call everything one or the other?

If I understand correctly, a list is just a logically related collection 
of params.  A group looks like a group to the user (box around it or 
whatever). Bruno's saying that a group can be made into a list so you 
can have something that looks like a group but behaves like a list, i.e. 
is replicable.

> Again, we don't really need dynamically allocated param settings that 
> vary
> for each spline.  We can simply say " for this plugin, create a 
> checkbox, 2
> popup-menus and 3 float sliders" whenever a new spline is added.  No need
> for us to change that per-spline, or vary it once our plugin is 
> initialized
> (I'm not speaking for anyone else!)

The spline plus your list of params is the list.  That list gets 
duplicated once per spline.

> 4) the host app sees that the user creates a spline for our plugin, then
> adds the necessary parameters for that spline (based on what we declare
> about spline params upon initialization of our plugin)

Or the host could call the plugin and tell it "new spline created" and 
the plugin could add the new copy of the list (or group).  Maybe that 
gives more flexibility?  In any case the new params should cause the 
host to know the plugin needs to be rerendered.

-- Gary
"


Bruno Nicoletti <br...@th...> "
Almost but not quite right. Obviously we are having terminology issues 
here and I wasn't clear enough in my post. I also have a horrid head 
cold, which isn't helping.

By group, I mean a set of logically grouped parameters. In OFX this is 
currently done with an explicit "group" parameter type that has other 
parameters as children. This is typically done so hierarchical param 
layouts (think After Effects or the FLAME animation sheet) are able to 
group params nicely.

By list I mean a parameter that can have zero or more values in it, the 
number of which are dynamically controlled by the plug-in. So you say 
during the plugin description phase "I want 2D position parameter fred 
to be a list". By doing so, fred can have zero or more 2D values inside 
it, each behaving as a separate 2D param. During the lifetime of the 
instance, the plug-in adds or deletes values in that list.

Using the STL as pseudo code to explain the concept,
     FloatParam barney; // basic float param, what we have now
     std::list<FloatParam> fred; // an array of float params, what I'm 
suggesting

I was suggesting that by declaring a group parameter  to be a list, 
creating a new element in that group param's list creates new elements 
in the children of the group as well.

I was also suggesting rotosplines be made explicit parameters that the 
effect declares in the same way as any other parameter, and so can be 
list params or added to groups.

Linking these concepts together, I was suggesting that Pete and Pierre 
could achieve what he was asking for without having to do some non 
orthogonal magic linking sets of parameters to implicit rotosplines.

Does that make more sense? "
"
  ///////////////////////////////////

SO,
All missing from above is the implicit association I think of "Add" and 
"Delete" (Add and Delete needs their own callback ) as explicitely part 
of the list super-param type
and the understanding that different hosts can display such parameter 
groupings completely differently:
- some usual schemes for example include:
* a menu (e.g. light 1,light  2,light  3,light  7,..) - selected one is 
the controls that get displayed in UI,  need alt to menu for cases where 
there are too many items
* a scrollable list that grows as you "Add" (e.g. as in Fusion natively 
now)
* a dedicated UI page for such (for the 2D parameter layout folks) - I 
think toxik 2011 has some internal "meta-widget" like that now that 
would map to this
-- display one only in Controls UI but all in animation channels editor...
Ideally Interact functions need a reset(currentId) to tell host which 
one to display or goto in UI.

Some other suites could be easier to design if that based mechanism was 
supported.

> -------------
> | Position  |
> -------------
> | ( 15, 1)  |
> | (255, 10) |
> | ( 5, 200) |
> | ...       |
> -------------
>
> I imagine a solution allowing to create a list of a group of parameters, so with one column for each parameter of the group. The parameters inside the list will be declared at the description step, like for all parameters. Only the number of parameters or group of parameters inside will be dynamic.
>
> See an example, kOfxParamTypeList<  kOfxParamTypeGroup<kOfxParamTypeString, kOfxParamTypeDouble2D, kOfxParamTypeRGBA, kOfxParamTypeBoolean>  >
>
> ---------------------------------------------------------
> | Name   | Position  | Color                | Enabled   |
> ---------------------------------------------------------
> | "foo"  | ( 15,  1) | (1.0, 0.0, 0.0, 1.0) | True      |
> | "foo2" | (255, 10) | (1.0, 1.0, 1.0, 1.0) | True      |
> | "foo3" | ( 5, 200) | (0.0, 0.0, 0.0, 1.0) | False     |
> |                   ...                                 |
> ---------------------------------------------------------
>
> We can imagine a code like that:
>
> OFX::GroupParamDescriptor* myListTypes = desc.defineGroupParam( "myListTypes" );
> myListTypes->setLabel( "Headers" );
>
> OFX::StringParamDescriptor* name = desc.defineStringParam( "myList_name" );
> name->setLabel( "Name" );
> name->setParent( *myListTypes );
> name->setDefault( "foo" );
> name->setEvaluateOnChange(false);
> name->setHint( "The name option of the list" );
>
> OFX::Double2DParamDescriptor* position = desc.defineDouble2DParam( "myList_position" );
> position->setLabel( "Position" );
> position->setParent( *myListTypes );
> position->setDefault( 1, 1 );
>
> OFX::RGBAParamDescriptor
> ...
> OFX::BooleanParamDescriptor
> ...
>
> OFX::ListParamDescriptor* myList = desc.defineListParam( "myList" );
> myList->setLabel( "My list" );
> myList->setParameterType( *myListTypes );
>
> There are still many things to discuss about the implementation, from example changedParam action...
>
> I read the discussion for openfx 2.0 about dynamic parameters.
> In my opinion, the problem is entierly solved simply with a property "unused" and a list parameter type. I think it simplify the problem and keeps the ofx philosophy of description step (describe/describeInContext).
> I think a new property "unused" is needed, which is different from "isSecret" because secret parameters needs to be stored in project file unlike unused parameters.
> Even if openfx supports dynamic parameters, a list type have a sense.
>
> What do you think about this idea ?
>
> Best regards,
> Fabien Castan
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first --http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Openfx-developer mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openfx-developer
>
>