patch relative filepath
Hi,
I've googled around and here too, but couldn't find a solution to make a patch loading samples to play in some sfplay~ objects with a PATCH relative filepath...
I used to make it pretty easily in PD, I can't believe it's so complicated in max/msp...
I have to put it into another computer.
Send the word
path
to [thispatcher] and get the relative path from the right outlet. The patch must be saved as a file to get a path.
Note:
The example below works only for regular Max patches, for applications you need a different method.
`
will this work if the patch is opened on another computer with the max runtime ?
thank you anyway !
I saved the patch, put it in another folder, opened with Max runtime, worked. So yes, must be the same on another computer as long as there is Max installed.
I took a slightly different approach to this problem. I create an abstraction with pretty much the same code (path to thispatcher) but I give it an inlet and outlet and then throw it in the root folder of a particular environment. E.g, the code below is stored in a file called CurrentRigRoot in a folder that contains all the patchers and related files used for a particular live rig.
I can then work with a new patcher, before even saving it, and have access to stuff I need, relative to the location where CurrentRigRoot is saved.
E.g
I have a few of these abstractions, suitably named, deployed in important places - for example, there's one called CurrentPatchRoot that is stored in a folder where all my .fxp files are to be saved and then I can easily access that from anywhere as well.
I'm using the solution with thispatcher in an abstraction, but suddenly the bahaviour changes and thispatcher reports the path of the main patch, not the one of the abstraction. How can this be used to work in an abstraction? I have an abstraction which loads a soundfile which is next to the abstraction and I would like to use this abstraction from various places.
in case it really does that it might be a bug.
as a temp solution, you could split your abstraction into two.
a newly created one will be opened via pcontrol after launching the patch, and writes its path into a var. the old one (while keeping its name) will provide that path by reading out the var.
I was told it is intended behaviour that thispatcher will output the path to the root document. Even if thispatcher is in an abstraction. If that's true then the helpfile which is next to the abstraction will get a different path then when the abstraction is in use from another file... sorry, little bit hard to explain.
Anyway, I "solved" this by telling the user to add the path to the search paths.
BTW, in Pd you can simply use relative paths and they are always relative to the patch they are referenced in, not to the parent patch. Also you can use [declare -path] in any patch without having the user to add a path to the preferences manually... It can be so easy.
The abstraction i Posted above worked very well but to be honest, I’ve mostly moved away from Max in the last year or so for a variety of reasons so I’ve no idea if something changed in an update that broke it.
Well thanks anyway!
This is an easy way to open samples in a folder next to the main patcher which allows to move the hole project folder anywhere without troubles. The folder relative path is just written as argument of a sub-patch.
[110.callrelatives]
000.whatever
...for those situations where you want to move the patcher file and its samples while it is open and still want it to work. :)