So I am trying to nest “Multiparm Block (list)”s and the default values are not what I would expect.

Example attached.

What I would expect:
# gives the number of the parameter in the first list
#_# gives the number of the parameter in the first nested list

So in my example
first point on the first curve would have the default value 1, 1, 0
seccond point on the first curve would have the default value 2, 1, 0
first point on the seccond curve would have the default value 1, 2, 0
etc.

Also, if you do simple math with the #_# it seems to bug out completely. Try putting #_#-#*10 into the default value and try adding and removing curves and points. Watch it break in unexpected ways.

Am I doing it wrong? Is multiparm block list nesting not supported or broken?


P.S. I think there is a lot of use for this technique and I am surprised by how little information there is on the topic of multiparm blocks (not to mention multiparm block nesting).

That's actually the expected behavior. The # substitution is a simple string substitution. The first # with the first list's number, and the second # with the second list's number. Any subsequent # is not touched. So when the default value of the parm is #_#, this is substituted to become “2_1”. This is then converted to the number 21. The substitution doesn't treat #_# as one substitution, and # as another. You can see this by clicking on the parameter to see the string value before it's converted into a number.

If you want to get only the second list's number, I suppose you could do a trick like: # * 0 + #

Thank you awong! This makes things clear!

Two questions remain for me:
1: Would it not make sense to have a variable specifically for the second list number? - Something like “#2”.
And then you could (theoretically) go even further and nest a list in the second list. This third list could then be represented by “#3” and so on.

2: How would you call a nested multi-block parameter from within a loop?
(So in the example above, I would have a loop running as often as the amount of curves I have and in that loop I would have a loop that would run as often as the amount of points in that curve. And each point could then be influenced by the value in the relevant parameter and be part of some complex operation.)

DASD
1: Would it not make sense to have a variable specifically for the second list number? - Something like “#2”.
And then you could (theoretically) go even further and nest a list in the second list. This third list could then be represented by “#3” and so on.

I believe the reason was so that the substitution logic for the default value follows the same rule as the parameter name.

DASD
2: How would you call a nested multi-block parameter from within a loop?
(So in the example above, I would have a loop running as often as the amount of curves I have and in that loop I would have a loop that would run as often as the amount of points in that curve. And each point could then be influenced by the value in the relevant parameter and be part of some complex operation.)

In Python, you could make use of hou.Parm.multiParmInstances() [sidefx.com] to get a list of all multiparm instances. For example, to iterate through:
import itertools
# utility function taken from itertools documentation
def grouper(iterable, n, fillvalue=None):
args = * n
return itertools.izip_longest(fillvalue=fillvalue, *args)

hou.parm('/obj/curve_object1/parameters')
for curve, point in grouper(parameters.multiParmInstances(), 2):
print point.name()
for usept, pt0, pt1, pt2, weight in grouper(point.multiParmInstances(), 5):
print “ ”, usept.name()
print “ ”, pt0.name()
print “ ”, pt1.name()
print “ ”, pt2.name()
print “ ”, weight.name()
print

Thank you for the code! I will dig into that.

I believe the reason was so that the substitution logic for the default value follows the same rule as the parameter name.

I noticed that it is the same. Wouldn't it make sense to expand functionality with additional useful symbols, though? I mean, you could implement it in such a way, that it does not break backwards-compatibility.

As far as I can tell, the trick you suggested (# * 0 + #), works for the default values, but not for the parameter name or the parameter value.

What if there was an arbitrary symbol (like for example: *) that stands for the position of the parameter in a multiparm block (list)?
So, if the name of the first point was Point*, the point at the top of the list would always be named Point1 and the N-th point in the list would always be named PointN. So no matter how and where you add “points”, they would always have consistent logical names based on their position in the list.

—
Which made me think of another thing: It would be great to have the ability to drag multiparm block entries around (upwards or downwards in the list), or at least have buttons to shift entries up and down.
Maybe that's something to implement in the next Houdini version.

Feel free to submit RFEs for these. Any work in parameters (especially multiparm) is quite complicated. But if it's an important or useful feature for many users, we would look into it.

There are actually several old RFEs for reordering multiparm, but we have yet gotten to it. Feel free to submit another RFE for this to try to bump up the priority.

I have an Indie license, so as far as I know, I have no access to the list of RFEs or the RFE votes.
- Actually, could you please give me a link to the list of RFEs? At this point I wonder wether I am simply missing the right link. I know how to submit RFEs, but not where to see the list of existing RFEs.

I'm glad to hear there are already some RFEs to that end.

There are no public list of RFEs. I just looked at our internal database. There isn't really a “voting” mechanism, but if enough users submit the same feature request, we'd take note.

That's quite fascinating.
It means that every RFE must be processed by SideFX people. And if you don't make the votes public you can pick what to work on and in which order. That makes perfect sense from a developer point of view, because you can prioritize based on various factors that the users are not aware of.
But wouldn't it make sense to at least make the list of existing RFEs public, so users can check whether their requests and bug reports and questions are already known?

Sometimes it's hard to tell whether a bug or RFE is a duplicate. And having duplicates give us more use cases, more scenarios, and more information about an issue. So it's always good to submit a bug or RFE, regardless of whether there's already a duplicate.

Just to chime in, I would also like to be able to have re-ordering options for the multiplram list.
And I also want to have an option to specifically query the second list number (especially for parameter labels).
I'll submit an RFE now