Miguel

This is a simple abstraction that I have been using for a while to deal with relative paths in max, specially useful when you use hundreds of samples that you don't want to have on the same folder where your main patch lies.

I am assuming that you have your whole project inside a folder that is not in Max's search path. Ideally, in the main folder I would have the main patch, any additional abstractions that I need and a set of folders where all media files are stored. These in turn may be further organised in sub-folders, say a different sub-folder for each instrument that I sampled or for duration ranges, etc.

This media files might then be called from all sorts of objects like sfplay~, buffer~, etc.

You construct your message in the format: for example "open /firstsubfolder/secondsubfolder/myfile.wav"

you connect this message box to the sfolder abstraction and the output of it to whatever object you are sending sound to, i.e. sfplay~ in this case. That's it!

sfolder will generate the preceding part of the file path (including names with spaces) and format it into an absolute path that sfplay~ will be happy with.

1.- A copy of sfolder must be placed in the top level of your project, along your main patch. That is, you cant drop it into the externals folder and just call it from within the patch as this would generate the path to the externals folder.

2.- The folder and file names of your project can NOT contain spaces. The message you are sending to sfolder is composed of two strings: The command (i.e. open, replace, load, etc.) and the relative path including the filename. If you have spaces in the name of your media files, the patch won't work.

3.- All the media files to be used must be in folders WITHIN your main project folder. This small abstraction won't find things god-knows-where in your harddrive.

The main disadvantage I see of sfolder is that you need to place it somewhere that you will remember and manually drop it into your top level folder using finder when you first start your project.

Any suggestions for improvements are welcome but I won't have time to do any changes for at least a month. Also, I haven't tried it in windows but if there is additional formatting needed for it to work I'm sure one of the forum gurus could solve it in a second, it is not a complicated patch at all.

Attached is a zip file that includes a top level folder with the sfolder and a test patch and a sufbolder with two sound files. Unzip this folder anywhere on your hard drive and move it all over the place, both files should play every time.

 This is a simple abstraction that I have been using for a while to deal with relative paths in max, specially useful when you use hundreds of samples that you don't want to have on the same folder where your main patch lies.

 This media files might then be called from all sorts of objects like sfplay~, buffer~, etc.

You construct your message in the format:  for example "open /firstsubfolder/secondsubfolder/myfile.wav"

you connect this message box to the sfolder abstraction and the output of it to whatever object you are sending sound to, i.e. sfplay~ in this case. That's it! 

There some things to keep in mind tho:
1.- A copy of sfolder must be placed in the top level of your project, along your main patch. That is, you cant drop it into the externals folder and just call it from within the patch as this would generate the path to the externals folder.

sharing-makes-people-like-me-relative-paths

thanks for sharing this tool but where is the link?

Sorry I have not been in the forums for a while.

The file was uploaded but might have been lost with the forum updates. please find it attached

 Sorry I have not been in the forums for a while.
The file was uploaded but might have been lost with the forum updates. please find it attached

I've been fighting with this issue for a while now. The solution using the sFile object above works perfectly fine when running the patch from within Max.

However, when I create a standalone or external, the solution breaks down, as max all of a sudden reports the computer root folder instead of the one the executable/standalone is located.

It's surprising that I haven't managed to find a solution that can consistently access files in sub-folders irrespectively of whether the program is running as standalone or not!

I'd greatly appreciate any suggestions for a simple consistent solution!!

Search the forum or the max documentation for "sendapppath" and you should be able to piece together an equivalent to sending "path" to [thispatcher] that will work in standalones. You might need to do a bit more [sprintf] work to format the location though.

I read about that, but it seemed more convoluted than necessary. I'm spoilt with just using a relative path from the start-up folder of the Java software I write and hoped that there was a solution that was as simple and as cross platform.

I will look into implementing a solution as per your suggestion and post back a patch once I have it working!

you can also deal with the spaces-in-filenames issue by using the "symout" argument with [sprintf]. there's an example subpatch in the [sprintf] help file.

The "path" message to [thispatcher] only works if the patcher is a file, for a standalone you need "sendapppath".

there is a working solution for patches, and another for applications... but AFAIK there are NO working solutions for collectives... which is quite frustrating!

https://cycling74.com/forums/path-message-to-thispatcher-object-in-collectivesstandalones

[Sharing makes people like me] Relative Paths