Parameter objects review

[Alex Harker]

Please take a look at the list of parameter objects (currently just fl.setparam~) and provide answers/thoughts on the following questions:

1. Are there any objects missing here?

2. Are there any object features missing here?

3. Any issues with info documentation, either general, or specific to a given object?

4. Any changes to parameter names/style desired here?

5. Any issues with object names?

[Alex Harker]

From earlier email correspondence:

• i do not understand why we need to type an integer to express how many param argument inlets we want? it serves no useful purpose other than to make us type more
• for example, i should be able to type [fl.setparams~ freq mode] and the object just knows i mean two params in the inlet order they are declared in.

Thoughts?

[Alex Harker]

Interestingly the same correspondence mistakenly named the object as 'fl.params~', which is what I misremembered it as recently too - is that a better/more appropriate name?

[Francesco Cameli]

I don't have any problem with typing an integer to set the number of inlets. It reminds me, in a way, of how jit.gl.multiple works. However, typing just [fl.setparams~ freq mode] looks more convenient, and so I would agree with changing it. "fl.params~" looks better too.

[Owen Green]

+1 to all that.

The only addition that springs to mind (no conctrete use case yet), is a getParam(s) counterpart.

[Alex Harker]

Ah... Now that is potentially much much more complex - I can see why you'd want to do it though.

[Alex Harker]

see next alpha