External - No such object issue

Noise Wrangler

Hello everyone,

I'm working on my first external, and I'm facing a strange issue. My external compiles fine and behaves as I want. I save a patcher with the external in it, still no issue.

But if I close and start Max again, and directly load the patcher with the external, then I get a "No such object" error.

One way to clear the issue is to open a new empty patcher, create an object with the external (which is now visible and doesn't cause an error), close the empty patcher (without saving it), and only then edit the external object in the original patcher.

What am I missing?

I'm on Windows 10, Max 8.6.1, SDK 8.2 and the external is in C.

Thanks!

Iain Duncan

If your external works, but you get "no such object", this means Max isn't finding it. It needs to be in one of the directories that Max searches, such as your Library folder, or something you add to the filesearch path. Those paths are rather fragile, for example if you add a path, and then Max crashes, when you restart, the path is gone! When doing dev I always add my paths and then close Max successfully, and then proceed.

Noise Wrangler

Thanks for chiming in. It is a bit more complicated that just not finding it. Max will find the external only if I first open a new patcher, create an object with the external, and then close the new patcher. Then and only then the external is visible when I load the existing patcher where the external is used.

If I start Max, and directly load the patcher where the external is used, then Max issues the "No such object" message. And the only way to see the patcher again is to do the same routine with the new patcher. Then I can go back to the original patcher and recreate the object without error.

It seems like something isn't happening with the path when loading an existing patcher. (Or more likely something I'm not doing right).

Iain Duncan

ok, but when you say "create an on object with the external", what precisely are you doing? If you are dragging your external into a patcher (ie from your system) that is different from creating a new object and typing the name of the external in a new obect box. I think (it's been a while since it happened to me) that the former will make Max find it. I could be misrembering... but I know I did experience weirdness similar to what you are describing at some point and it all came to paths and Max search folders.

Have you tried putting your compiled external into your Max 8/Externals folder?

Wil

Documents->Max 8 ->Packages -> *create your folder*

Iain Duncan

I think if you have not actually made a package, the correct directory is the Externals folder, not the packages folder. Packages require some extra files to make them visible to the package manager.

Not sure if it actually matters though... :-)

Noise Wrangler

Thanks for your help guys. In answer to some of your questions:

The external is in the same folder as the demo externals from the max-sdk (like simplemaxand dummy )
I've created a patcher ext-test with the two externals above, and two externals I created myself lorenz (the problematic one) and lorenz96 (which seems to work)
When I load the patcher just after starting Max, only lorenz issues a "No such object" error... the other externals load properly... but
If I close the patcher, create a new empty patcher, create a lorenz object by typing it, I don't get an error and the external works, and
When I reopen the ext-test , now lorenz is found and works fine too.

The part that really confuses me is the fact that the lorenz external isn't found only if it's already present in a patcher that's loaded just after starting Max. If it was always missing, I would know it was a problem with the code for sure. But in this case, I'm totally baffled.

JBG

Just as Iain said in his first reply, your search path is likely not correctly configured. When an object isn't in the search path, Max will try to infer it from a wider scope of folders (basically everything inside the Max/ folder) and add it to the search path, which works in 95% of all cases, but will lead to nastiness like the things you describe in the other 5%. I don't know exactly what happens at startup in your case, but I could imagine something like this:

Before opening ext-test, Max loads all externals/abstractions in the valid search path (which contains neither lorenz nor simplemax)
Max opens ext-test which contains a number of extensions not in path and tries to locate each of them.
It finds something called lorenz somewhere in your Max folder, which appears to be an external/abstraction but isn't , tries to instantiate it, and fails
It finds simplemax (which is in the same folder as lorenz) and adds this to your search path

Now, your search path is configured so that it contains the folder of simplemax, so if you now try to instantiate lorenz, everything will all of a sudden work (and cause a great amount of confusion).

The simple answer to avoid all of this is to explicitly ensure that the path is set up correctly at launch. You're saying that they are in the same folder as the demo external from the max-sdk, but you're not telling us where this is. Is it either:

~/Documents/Max\ 8/Packages/max-sdk (so that the externals are in <...>/Packages/<some_pkg>/externals)?
Manually added to your search path through the File Preferences dialogue?

If the answer is "no" to both of these, it's not in your search path, and you should change this first and foremost

Noise Wrangler

Thanks JBG, the max-sdk is in the Packages folder as recommended in the Readme file. And I don't get any issues with the other packages and externals installed there.

I have thought about the possibility of something else called lorenz , but:

The lorenzautocomplete disappears as soon as I delete the external, so that's unlikely.
I can instantiate a lorenz object on a new patcher that I create through File > New Patcher just after starting Max - And simply doing this makes the lorenz external visible on all other patchers I open afterwards. (That's my workaround for now)

That second part is what really puzzles me here. It seems that if the lorenz object is instantiated too quickly (like when loading an existing patcher), Max doesn't find it and then it gets 'confused'.

For completion, I've run ; max db.reset a few times, with different path configurations (with and without explicitly pointing to the Packages folder), and it hasn't changed anything.

Iain Duncan

Another option is to make a build script that cleans out previous versions and moves it to a known-good location after compiling. I wound up doing this for testing anyway. (Doesn't solve the why question but might solve your immediate issue!)

Noise Wrangler

Thanks a lot Iain, it hadn't occurred to me!

Putting the external in the same location as the patcher that calls it seems to solve the problem for now.