My custom is to always define a project whenever I create a new .hip and to use the $JOB parameter for defining all paths.
And additionally to keep all .hips in a nested hip directory.

Have been wondering if I'm simply creating unnecessary work though and should stick with $HIP instead and keep all my paths relative to $HIP.

For one thing its necessary to redefine your $JOB(ie re set your project) whenever you open your .hip on a different computer.

Are there any advantages I am not aware of in using $JOB over $HIP or is it simply a matter of preference?

Stick with $HIP, or use $JOB?

I vote stick with $HIP. As soon as you save a new file $HIP is created for you. All I am interested in is the ability to make file references relative to $HIP. I regularly use different computers, with my files in different absolute locations since everything is in Dropbox.

I think the only thing a project gives you is the default bunch of directories, and the ability to create your own directories. If you always create the same folder structure every time you create a scene then that would be useful. I don't, so $HIP gives me all I need.

Does anybody know if you can somehow batch-change $JOB for a lot of hipfiles?

That would alleviate the pain of having to change $JOB, forgetting it when opening another hip, etc.

For as far as I know you can’t go ‘up’ with paths relative to $HIP right? Like a channel reference could:
ch(“../../../../../../../node36/tx“)

I don't use JOB or HIP, as we have our own environment, but….

To change all refs of $JOB to $HIP, open a textport (alt shift t), and:

- tells you where all the JOB vars are, optional

- does the actual change. If you had the time, you could write a batch script to open all of your hip files on the command-line and do this.

And yes, you can go “up” with paths relative to HIP, EX:
Sean

Thanks for telling me that!

So I assume indeed you can write a loop for each hipfile in a folder and change that with opfind, probably also to a path string instead of /$HIP.

but before I dive deeply into the hscript commandline, let me ask this:
Is that particular thing also possible to do in Python?
Because that is what is meant to ‘replace’ HScript in the long term if I’m not mistaken? but the ‘transition’ is not completed yet and maybe some things are better done in HScript commands? Correct or incorrect? :-)

If I could have some vague idea that that sortof thing is also possible in Python I might maybe choose to go that direction instead..

Thanks again

I don't think hscript is slated for removal any time soon. It's much faster when you don't need the advanced capabilities of Python, and it's a lot easier to do one-liners. There are millions of scripts out there in the wild still using hscript, so it would be painful and unnecessary to remove it.

Also some hscript commands are not ported to python yet. In this case, you can always:


If you want to use all python when possible, just use the textport:

help opfind

… and it will show you the equivalent Python def(s).

Sean