I'm guessing it's not possible by the nature of the two contexts.

But is there the likelyhood of ‘special’ syntax to be introduced - for either Hscript/Python,

at some point in time that say for example,

would allow a LOP transform node parameter make a channel reference to some other parameter that sits in SOPs?

I'm not sure what you mean, any parameter can reference any other parameter regardless of context.

Ok…yep it works…when I do by drag and drop, it works because it adds the necessary extra ‘heirarchy layer’ references.

When I was originally doing the the channel referencing I typed it manually so those ‘layers’ were missed - because you don't see them in the network.

It's not like SOPs where you can just follow the names of the nodes as they are seen/related to each other in the network view.

With the drag and drop it gives:


If this was a ‘SOP’ context and just going by what you see with the nodes names I would be using:


Without the two ‘modify’ levels.

I don't know where these ‘modify’ levels are coming from or why it is that way but,

Looking at the Scene Graph Layers Panel for the sop modify node we get:


But it shows only one extra ‘modify’, not two.

So I guess I will just have to be patient and keep reading to become more familiar with USD.

I don't know about you, but I see two levels of ‘modify’ in the node path to the inside of a sopmodify node.

e.g. /stage/sopmodify1/modify/modify/mysop1

During the beta there was just one level, but a second one was added to fix a bug with sopnetworks.

Sop context also requires the correct path to a parameter for reference. For example if you want to reference a parameter on a transform sop inside a solver sop, you have to go down several more levels:

e.g. ch(“../solver1/d/s/transform1/tx”)

Being a LOP has nothing to do with it. The SOP modify just has the dive target set down two levels from its root. Many other nodes with editable dive targets are similar such as the groom objects and various sops with solvers inside.

I don't know about you, but I see two levels of ‘modify’ in the node path to the inside of a sopmodify node.

e.g. /stage/sopmodify1/modify/modify/mysop1

That's what I am saying, there's these two ‘extra’ levels. My point is that it does not operate akin to directory/file system heirarchy(visually speaking, i.e. the node, and the parameter associated with the node);

Which I have assumed naively up to this point in time, but because of this and your solver example, no longer do explicitely.

Sop context also requires the correct path to a parameter for reference. For example if you want to reference a parameter on a transform sop inside a solver sop, you have to go down several more levels:

Yes, but if you have a box inside a subnet, then it does work akin to directory/file system. See attached hip.( no ‘extra’ layers),

just:

ch(“../subnet1/box1/sizex”)

No ‘extra’ layers required.

BabaJ
That's what I am saying, there's these two ‘extra’ levels. My point is that it does not operate akin to directory/file system heirarchy(visually speaking, i.e. the node, and the parameter associated with the node);

They aren't extra, they're right there in the hierarchy. Node paths behave exactly like a file system hierarchy. The ‘dive’ action just takes you directly to the editable area for convenience. If you look at the node path in the network editor you will see the path contains all the levels that exist, including the non-editable ones.

Facepalm.