dhjdhjdhj

I keep the following in specially named patchers around my system.

The idea is that if I load one of those named patchers into some other patcher, banging it will return the location where that specially named patcher lives. I'm able to use this to refer to specific folders in my system.

Works fine under Max 5 and Max 6. Under Max 7 it seems to return the location of the patcher inside if which it's located rather than the location of the abstraction.

See attached graphic for example. The Max 5 version correctly returns the location of the folder where PatchesRoot lives. Max 7 just returns a '/', presumably the current path of an unsaved patcher.

Below is [PatchesRoot] which does live where Max5 says it does!

I keep the following in specially named patchers around my system.
The idea is that if I load one of those named patchers into some other patcher, banging it will return the location where that specially named patcher lives. I'm able to use this to refer to specific folders in my system.
Works fine under Max 5 and Max 6. Under Max 7 it seems to return the location of the patcher inside if which it's located rather than the location of the abstraction.

Below is [PatchesRoot] which does live where Max5 says it does!


the-path-message-to-thispatcher-is-broken-in-max7

This is expected behavior since November 2013, also in Max 6, as far as I know. Sorry, the old behavior didn't work consistently for all types of subpatchers, and we aren't planning to change it back.

You can place a js object with the following code in your patchers, though:

function bang() {
    var p = this.patcher;
    var filepath = p.filepath;
    outlet(0, filepath);
}

Which will do what you want, more or less, you may need to post-process the file path.

function bang() {
	var p = this.patcher;
	var filepath = p.filepath;
	outlet(0, filepath);
}

Thanks for the quick response, I appreciate that. This does work although I'll have to remove the file extension, not a big deal.

However, for what it's worth, as of 6.1.9, the other approach has been working perfectly fine for me whenever it was in any abstraction (or even nested abstraction) loaded into a patcher. So I'm not sure how it was breaking nor is it clear to me what is the value of the changed behavior.

However, for what it's worth, as of 6.1.9, the other approach has been working perfectly fine for me whenever it was in any abstraction (or even nested abstraction) loaded into a patcher. So I'm not sure how it was breaking nor is  it clear to me what is the value of the changed behavior.


Now I'm a little confused. The documentation for the 'path' message in Max 7 says

"The path message will send the full pathname of the patcher that contains the thispatcher object out the right outlet of the thispatcher object."

http://cycling74.s3.amazonaws.com/support/version_7_0_0.html),

thispatcher: ‘path’ message works in subpatchers

So what are the circumstances under which 'path' doesn't work and also, what is the point of 'path' if you can't put [thispatcher] into an abstraction to get the location of that abstraction?

I'm happy enough with the JS solution (a bit of regex tweaking makes it work exactly the way I needed) but I'd like to understand exactly the change and its purpose.

Now I'm a little confused. The documentation for the 'path' message in Max 7 says
"The path message will send the full pathname of the patcher that contains the thispatcher object out the right outlet of the thispatcher object."

In the release notes for Max 7 (http://cycling74.s3.amazonaws.com/support/version_7_0_0.html), there's an entry that says:

So what are the circumstances under which 'path' doesn't work and also, what is the point of 'path' if you can't put [thispatcher]  into an abstraction to get the location of that abstraction?

I'm happy enough with the JS solution (a bit of regex tweaking makes it work exactly the way I needed) but I'd like to understand exactly the change and its purpose.


So its not broken then> Thanks for the heads up on 7.01 :)

I wrote a little piece on solving this problem, actually I dont think it is the best solution, but I wanted to avoid including javascript in standalones, if possible, so if others have a better idea I am glad to hear it...

http://www.yofiel.com/software/cycling-74-patches/paths-to-externals

So far it just addresses the M4L project.

I wrote a little piece on solving this problem, actually I dont think it is the best solution, but I wanted to avoid including javascript in standalones, if possible, so if others have a better idea I am glad to hear it... 

So far it just addresses the M4L project.


The path message to [thispatcher] is broken in Max7