I've created a VEX CHOP and I'd like to be able to promote the local variable $C (channel index) so that it can be used in expressions on my CHOP. I've noticed that $C can be used in the Noise CHOP, for example, but not all CHOPs. How do I promote the $C variable from my custom VEX CHOP?

Thanks,

Andrew

AndrewJBeard
I've created a VEX CHOP and I'd like to be able to promote the local variable $C (channel index) so that it can be used in expressions on my CHOP. I've noticed that $C can be used in the Noise CHOP, for example, but not all CHOPs. How do I promote the $C variable from my custom VEX CHOP?

Not an option with Vex. The parameter list gets evaluated once and once only, and then off it goes through all the samples.

The equivalent of $C is available in the VEX context for CHOPs, I forget what it is right now but as Antoine says, VEX operators are “different” since they don't support local variables in the UI. However, they do fully support them in the VEX (VOP) code so you need to “code in” local variables support.

The advantage is that VEX executes bazillions (approximately) times faster than an operator using local variables. Usually So it's usually worth it.

Cheers
,
Peter B

Okay, thanks. I appreciate that VEX is SIMD and there have to be some compromises for speed.

I'm guessing then that the Noise CHOP (for example) was written in C++ which is how it can expose the $C local variable?

Actually, whilst we're on the subject of VEX, what is the best way of storing VEX scripts in an asset, when the asset is not entirely defined by the VEX code - i.e. an asset consisting of several nodes, only one of which is a VEX node. I've tried embedding a compiled VEX script in the ‘extra files’ section of my asset, but the VEX node can't read it using the ‘opdef:./’ syntax. At the moment I'm tempted to simply build the VEX code in VOPs, but this feels like a fairly inelegant solution…

Hi Andrew,

You're right, the Noise CHOP and almost all other operators in Houdini are written in C++. You can always tell, if you MMB on a node and it has a “defined by” string pointing to an OTL file, then it's not C++. I might be a subnet or it might be VEX.

For what you're creating, I would recommend you build the VEX node as a “standalone” then use it in your subnet asset. You can save the definitions of multiple nodes to a single OTL file, which would be appropriate in this case I think. Basically, when you save the VEX node point it to $SOMEDIR/someName.otl then when you later use it and save your subnet asset, save it also to $SOMEDIR/someName.otl and bingo they're “together” in a single OTL file. They're actually two different nodes in Houdini.

If you want to “hide” the VEX node because it's useless outside your asset, you can use OPcustomize (copy from $HFS to somewhere in $HOUDINI_PATH) to hide it. There may be a way to hide nodes via Optype Properties, but I'm not 100 % sure about that.

VOPs is also a solution, I personally use VOPs for 95% of my coding in VEX these days, which has pros and cons.

Cheers,

Peter B

AndrewJBeard
Actually, whilst we're on the subject of VEX, what is the best way of storing VEX scripts in an asset, when the asset is not entirely defined by the VEX code - i.e. an asset consisting of several nodes, only one of which is a VEX node. I've tried embedding a compiled VEX script in the ‘extra files’ section of my asset, but the VEX node can't read it using the ‘opdef:./’ syntax. At the moment I'm tempted to simply build the VEX code in VOPs, but this feels like a fairly inelegant solution…

I usually use ‘vcc -l foo.otl foo.vfl’ i.e. make a dedicated OTL for it.

Thanks again, chaps. Most helpful.

I ended up recreating my VEX code in VOPs (which doesn't look half as bad as I thought it would be) and wound it up with some other CHOP nodes into a digital asset.

It works. Kinda.

You see, my HDA CHOP insists on asking the user to select the ‘Subnet CHOP’ from which to export, and defaults to ‘Audio CHOP’ (which doesn't exist in my network) and therefore raises an error when created. This appears to be the default behaviour for HDAs built from SubNetwork CHOPs. Is there any way to force the HDA to export from a different CHOP?

Actually would appear that this last question was answered here:
http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=6470&start=0&postdays=0&postorder=asc&highlight= [sidefx.com]