EarHax

I would like to have the ability to create a new patcher/project, and have it NOT be able to see/load anything in my user library file path (~/Documents/Max\ 7/Library/). When I open the "Options>File Preferences..." menu, if I uncheck the "Subfolders" checkbox for the user library, if I close and reopen that, it shows that it is still checked.

Furthermore, new patches will still list/autocomplete and load patches/code/etc. in my user library folders when creating new objects.

How can I disable this behavior ONLY for specific patches/projects for debug/testing purposes before sharing patches using "Copy Compressed" that have code/patcher dependencies in my user library to ensure that nothing will be missing when someone else tries to open it?

I would like to have the ability to create a new patcher/project, and have it NOT be able to see/load anything in my user library file path 

ignoring-user-library-file-pathisolating-patches-for-testing

Really hoping someone has some helpful info on this soon...

I dislike idea of having any "default" place for either externals, packages,

So I kill all that stuff and place things manually where I want them.

Usually if You make a folder and store main patch into it , subpatches,

externals, pictures or whatever else needs to be loaded, it will work ok.

It is more of a challenge to disable all that auto - stuff.

I dislike idea of having any "default" place for either externals, packages,
patches or whatever else.
So I kill all that stuff and place things manually where I want them.
Usually if You make a folder and store main patch into it , subpatches,
externals, pictures or whatever else needs to be loaded, it will work ok.
It is more of a challenge to disable all that auto - stuff.





True. This is more of a development/QA issue than a personal preference, however.

My main issue is that Max will forcibly load things from places I don't want it to at times when they are referenced by a subpatcher. Sometimes older versions of abstractions will load even when I have saved a newer version into the project folder when editing other subpatchers, and the newer one then gets put into a _DeletedItems folder simply because one patcher referencing the abstraction wasn't saved with the latest version of it, and loads it from somewhere else. And if I have a patcher loading other patchers, it gets really messy because then the order in which things are saved determines how and what they will load.

For example: I open project/patcher A, which opens patcher B, which loads various utilities and abstractions with it. Sometimes I am forced to open patcher B first to update it with the latest abstractions independently of being opened from patch A. But in some cases, I need patcher A open for patcher B to work properly. So if I open and save patcher B on its own, then the next time I open it from patcher A with the project, there are UI bugs or other problems.

Also, it doesn't make sense to have multiple versions of utilities/abstractions/code/media files I use all over my system for every project I am working on that references them, considering that this results in even more of a mess with version control and things being loaded from the wrong place than if I only have one version of the file in the user library.

But even then, with just one version of a file in my library, sometimes some abstraction in a patch within a patch within a patch will still create an old version of the file in the project folder, thus causing problems for other patchers in the project loading that file since the search path looks in the project folder for files first before looking in the user library.

SO, to reiterate, I really need to find some way to isolate projects (or individual patchers) from the user library folders to prevent this from happening so that I can either force the most recent version of a file (or a version of the file customized for the project) in the project folder to be used, or to cause patchers to fail to load the file so that I can replace it properly as needed (just where it is failing to load, instead of needing to fix a problem that propagates to several other patchers because the file they were loading properly from the project folder got deleted and replaced with an older version by something else).

Lastly, I still think it must be a bug that when I uncheck the "Subfolders" checkbox for the user library, if I close and reopen the window, it shows that it is still checked, and newly created objects in the patcher can still list/autocomplete and load patches/code/etc. from my user library folders.

Sorry to repeat myself, but I see it very simple - either computer is controlling You

Even if one had enough time to analyse what exactly max does with all that

stuff, including restoring of crashed patchers, not to talk about apples revisions

etc etc, there would be no guarantee that the system would behave

exactly the way You want, and that on very next update things won't start acting

If You do professional work with max, and maintain many projects,

Sorry to repeat myself, but I see it very simple - either computer is controlling You
or the other way arround.
Even if one had enough time to analyse what exactly max does with all that
stuff, including restoring of crashed patchers, not to talk about apples revisions
etc etc, there would be no guarantee that the system would behave
exactly the way You want, and that on very next update things won't start acting
a bit different.
If You do professional work with max, and maintain many projects,
 You have to have it under control.


Sorry, but your replies are not helpful. Please stop trolling.

If there's anyone else in the Max universe who can actually help by letting me know how to remove the user library (or at least the subfolders within it) from the search paths for specific projects/patchers, please reply and let me know.

Since the subfolders checkbox is failing to remain unchecked, and items in the user library are still being listed, and are able to be loaded when creating new object boxes, I'm pretty sure this is a bug.

Are there no c74 staff members watching the forum for issues labeled with the bugs tag who can respond to address this?

If there's anyone else in the Max universe who can actually help by letting me know how to remove the user library (or at least the subfolders within it) from the search paths for specific projects/patchers, please reply and let me know. 

i understand your idea behind this, but you cant do it this way.

when files are in the search path, they are in the search path. and when you have "older versions of abstractions" in the search path, then this approach is a complete fail for at least two reasons.

your best bet is to use packages for your projects - or any other form of (custom) subfolders in the search path - one per project, and then you can disable the unwanted ones by moving them out manually.

but it is generally a bad idea to call version 0.3 of your [audiothing] "audiothing" and then call version 0.4 "audiothing", too.

imagine your would call both of your daughters "anna" and then shout "anna" out of the front window. what do you think how the other anna, who is currently behind the house, would react?

IF you for some weird reason want to keep different versions of the ehm ... "same" abstraction, then please use a naming convention like audiothing03, audiothing04. that is the only way you can make sure that always the one you want will be loaded.

the filebrowser, btw, has nothing to do with the search path. if it confuses you, then dont use it.

(in my opinion the filebrowser system is a bit strange. noone needs all the pictures he used for GUI building in the "media" browser or the other way round. and noone needs the live devices to show up in 5 different places. i would prefer a fully customizable filebrower system.)

if you have a lot of abstractions you should at one point start to add them to the contextmenu (objectlist) - or remember their names.

i understand your idea behind this, but you cant do it this way.

when files are in the search path, they are in the search path. and when you have "older versions of abstractions" in the search path, then this approach is a complete fail for at least two reasons.

imagine your would call both of your daughters "anna" and then shout "anna" out of the front window. what do you think how the other anna, who is currently behind the house, would react?

IF you for some weird reason want to keep different versions of the ehm ... "same" abstraction, then please use a naming convention like audiothing03, audiothing04. that is the only way you can make sure that always the one you want will be loaded.

the filebrowser, btw, has nothing to do with the search path. if it confuses you, then dont use it.

(in my opinion the filebrowser system is a bit strange. noone needs all the pictures he used for GUI building in the "media" browser or  the other way round. and noone needs the live devices to show up in 5 different places. i would prefer a fully customizable filebrower system.)

if you have a lot of abstractions you should at one point start to add them to  the contextmenu (objectlist) - or remember their names.


btw, you can also put your projects in folders outside the active search path (like /user/myshit/) and then include these locations by adding them to the search path (file preferences) only when needed.

This isn't actually the case I was trying to explain, however. I have one copy of each abstraction that I save in a subfolder in the user library path, and they are used all over the place. But what is happening is, when I update one of these utility abstractions while working on one particular patcher, instead of the other patchers in other projects that reference the same abstraction simply loading the one copy that I maintain, a copy of an older version of the abstraction (as it was when that project was last saved) will be created in that project's folder. 

I'm not sure how or why this is happening, or why I can't uncheck the "subfolders" box for the user library path in the list of search paths for a project and have that preference be saved. But at least it is now clear to me that it seems I will need to maintain multiple revisions/copies(with unique names) of every abstraction I use for each project, and take everything out of the user library path that I don't want to have always be loaded, since it seems there is no other way. 

But that "subfolders" checkbox should really be grayed out if the user isn't actually able to uncheck it to exclude the user library subfolders from a project.

And yes, I do know how to use file browser. I'm sorry if something I said previously may have been incorrectly worded and would indicate otherwise.

This isn't actually the case I was trying to explain, however. I have one copy of each abstraction that I save in a subfolder in the user library path, and they are used all over the place. But what is happening is, when I update one of these utility abstractions while working on one particular patcher, instead of the other patchers in other projects that reference the same abstraction simply loading the one copy that I maintain, a copy of an older version of the abstraction (as it was when that project was last saved) will be created in that project's folder. 

I'm not sure how or why this is happening, or why I can't uncheck the "subfolders" box for the user library path in the list of search paths for a project and have that preference be saved. But at least it is now clear to me that it seems I will need to maintain multiple revisions/copies(with unique names) of every abstraction I use for each project, and take everything out of the user library path that I don't want to have always be loaded, since it seems there is no other way. 

But that "subfolders" checkbox should really be grayed out if the user isn't actually able to uncheck it to exclude the user library subfolders from a project.

And yes, I do know how to use file browser. I'm sorry if something I said previously may have been incorrectly worded and would indicate otherwise.

it seems that i am not using 6/7often enough to be aware of this weird automatic creation of older versions of subpatches after another instance has been updated and saved. it does not really make sense. i can reproduce the expectation you had. :)

Ignoring user library file path/isolating patches for testing