load an abstraction from a specific file location (absolute path)
Hi,
reading through the docs and doing some explorations I guess its not possible, but maybe I am missing something.
Following the simple & attached Max for Live device example (but this will be the same for Max, I am quite sure), I am looking for a way to load each of the two Max abstraction foo.maxpat - one resides in the subfolder "alpha" the other in the subfolder "beta" - in a "specifying an absolute path" way.
It seems to be a basic principle of Max that each abstraction or patch file that is loaded from disk, has to have a unique name and that only filenames are considered and there is no way of distiction by folder paths ... as far as I have found out.
If the filename is found more than once in the search path one gets the warning in the Max console "you have multiple files in your search path with the same name Xyz" and Max uses automatically the first one found - hence the order of paths in the search patch matters.
Even if I use a bpatcher and use the "choose" button (Parameter : Patcher File) to point to the specific file on disk via Finder (or Windows Explorer), only the filen
ame is picked up and not the full filepath (absolute path).
Also the Max project system (whereby each Max for Live device is also a Max Project) and its search path are no help.
Or from another point of view : if a Max abstraction is placed inside its own folder (like alpha & beta in the attached example) there is no way to let Max only search in their (local) folders when loading another Max abstractions like foo.maxpat.
Folder Alpha : alpha.maxpat -> load foo.maxpat from the folder Alpha
Folder Beta : beta.maxpat -> load foo.maxpat from folder Beta
I found no way and Max has chosen the one that was found first depending on the search path.
So the only way I see is to encode prefixes into the filename of Max abstractions, like alphaFoo.maxpat and betaFoo.maxpat ... which can get strange when the project gets larger - anyone how had the pleasure to code in objective C can sing along ... ns & framework prefix heaven, or was it hell ;-)
Or did I miss something?
if you load abstraction into patcher from same folder, all ok,
you can have as many such folders anywhere, and max will load
abstractions into their path buddies correctly.
but don't include that folders into search path.
by the way - what is benefit of having different patchers with same name ?
--------
one can enter absolute path into abstraction too, like this:
Works in max, I don't know about Live and what sense it makes in terms of portability.
Thanks @Source Audio for your hints ... and of course I did not see the obvious ;-)
Although I did somehow ... talking about entering the entire absoulte path in the object box, like you did with : ~/Desktop/Alpha/foo.maxpat.
It was too late as I wrote my post yesterday - sorry, for beeing not precise enough.
I tried relative paths first and then read that the working directory (hence the starting point of a relative path) will vary or depends on the last opened patcher - so I droped this "relative path" approach.
As I thought a patcher object-box inside the Beta Max Abstraction (located in a folder called Beta) set to [../Beta/foo.maxpat] will work theoretically, but may fail at runtime, depending on where in a "bigger patch" the Beta Max Abstraction is placed and hence loaded ... this was the point where I should have gone to sleep ;-).
But now - after a bag of sleep & cup of coffee ;-) - I see, that practically in the moment the Patcher is loaded, the folder it resides in becomes the working directory and hence the relative path approach could or should work ... I have to do some experimentations and come back on that later.
Next up was absolute paths, but using their complete string inside a patcher object-box makes this box huge in width - especially as I have quite a long folder path in which I develope the Max for Live / Max patches (development folder structure for different purposes, source code repository ... are the reasons for that).
But I also must have made a typo yesterday night, as I could not even get this full path string in an object box running ... or I just missed to place the folder path in quotes as it contained spaces ... what so ever, I messed it up ;-)
+++
What remains : long absolute paths make the patcher object box huge in width, hence its quite unsable in "patcher practice".
So I was looking for a solution where I can use an attribute and hence the inspector to set the path and filename for the Max abstraction to load.
But with a fresh mind and having found a way out the rabit hole asleep ... recalling my developer experience ... absolute paths are quite always not a good idea - some moment in time they get you in trouble and some of this "it works on my machine" answers on bug reports are rooted in using absolute paths that most often are different on the users machine.
+++
Regarding your question : why having different patchers / Max Abstractions with the same name.
That 2 or more Max Abstraction will have the same name is NOT something that I plan ahead of time - having 2 or more general purpose "pieces of code" that do different things, but have the same name and are inside a global namespace does not make any sense, right.
Its more a strategy to protect myself as I develop a greater network of Max Abstractions and there is a kind of hierarchy inside the Max Abstractions, with the aim to reuse as much code as possible and not to use "copy & paste" with subpatchers ... which would force me to update code in several places because of a change I made in 1 place.
Its a way to translate my experience in conventional software development, especially the object oriented mindset - brain muscles trained on class hierarchies and namespaces ;-), to the world of Max development ... this visual approach of Max patches & thinking object oriented (Max Abstraction as classes and methods as well) makes sense to me ... currently ;-)
In that way I want to protect myself for Max Abstraction reference issue - Max picking up the wrong patch, if I use the same "Max Abstraction method-name" in 2 different "Max Abstraction classes".
Speaking in an example : Alpha and Beta are "Max Abstraction classes" ... which will be created several times in a bigger patcher (instantiated via several patcher objects).
Foo is a "Max Abstraction method" that I might come up first in the Alpha "Max Abstraction class" - in real patching life it could be something like "advanceModulation".
After some time another logic comes up in the Beta "Max Abstraction class" (and its different, as it has another context, a Max Abstraction that has more parameters e.g.) and my "naming invention / creative" section of my brain will most probaly come up with the same name for the "method abstraction" : foo (or advanceModulation).
I have trained my brain for quite a lot of years, creating similar names for "chunks of code" that do similar logic - which makes reading my own code after some time a lot easier ... the naming scheme for "method names" makes it immediately clear what the code does, at least from a birds eye view - hence scanning through my code becomes much more easier and faster.
cheers & thanks again
You must have had a very sound sleep and very strong cup of coffee to gain so much will and time to write this essay on abstractions, ha, ha.
I must confess that in my entire max life, I did not use a single abstraction,
but allways subpatches or bpatchers.
>>but don't include that folders into search path.
that is the part he missed. inside the search path you do not need the path to find stuff, but you may not use the same filename twice. using paths outside the search path is out of question for standalones or plug-ins, so just dont do it this way.
however, if something is loaded via pcontrol or loadbanged, it would theoretically work with relative paths outside the search path: thispatcher has an outlet which returns the path of the motherpatcher, so that you can construct relative paths from that. which then even works upward.
patcher A will know this way that it is located in /mydisk/myfunnyapp/A-stuff/ and then load mydisk/myfunnyapp/A-stuff/audio/test.aif, while patcher B will look for a file with the same name in the /B-stuff folder.
Writing an essay ;-) ... sometimes it helps to clear ones mind - like explaing a problem to another person alone solves the problem respectively the solution comes to mind while taking or writing about it.
Hope you got a great of coffee too and thanks for your time reading and answering on it ... but the story is not finished yet ... what's a novel without a satisfying finish ;-).
+++
Relative paths are practically not useable in Max 4 Live projects, as there is an implicit "max search path" with "include subfolders" feature turned on, that is set to the folder in which the *.amxd file is developed and stored.
While the relative path notation in a patcher like [./foo.maxpat] works technically, it practically fails if there are several subfolders (like alpha & beta in my example) underneath the M4L device development folder that contain a Patcher with the same name (foo.maxpatch).
Max chooses the frist "foo.maxpatch" found traversing its search path and the relative path instructions are dropped.
Also there is a strange difference in behavior when editing the "parent patcher" and entering the relative path (one might get a error that this file does not exist) and saving the parent patcher, close the editor, delete the M4L device from the Live Set, add it again to the Live Set and open the editor again (the file is found and it works in some sense ... but not along my intention as the search path acts like a dictator ;-).
Hero of the novel died ;-).
Epitaph : there is default development folder that is created by Max when one adds a M4L device to the Live Set and opens the editor - which is described here : https://docs.cycling74.com/max8/vignettes/projects_devices. This makes sense for the "others / 3rd party M4L device" especially as they are frozen and hence "unpacked" in that folder.
But for a local development of ones own M4L device its odd - its not clear why this default folder is used although I store the amxd in a local development folder ... and this default folder is deleted by the way, when the Max editor is closed.
Although I can understand that its hard to distinguish theses cases when there is no explicit project file or structure ... Max 4 Live Device development is like working with (in a Live Set) & developing on (in the Max editor) an executable in a tranparent manner and same time (which is quite crazy & awesome) - no build process, no packing ... so that there are quirks and surprises is comprehensible.
The really odd thing though : in the Max Patch Editor, opening the project window and looking at the "project search paths", only the defaut Max "unpack" folder (~/Documents/Max 8/Max for Live Devices on a Mac) and NOT the real local development folder shows up - which is weird as this local development folder is in fact part of the search path (even with subfolders turned on) or my Alpha, Beta and Foo could not have been found and loaded.
Epilog : the hero was mislead on evil paths ;-)
+++
Beings, long forgotten, arise out of the ages of wisdom : prefix'es.
So my current solution are prefixes, like [aFoo.maxpat] (to be used in the Alpha Max Abstraction) and [bFoo.maxpat] (to be used in the Beta Max Abstraction).
I think it makes not much sense to try to workaround the fundamental concepts of a programming language or enviroment just to satisfy or continue a habit gathered in another programming language ... it's like in the reald world : each culture got's in own habits and beauties - lets see, use & enjoy them ;-)
+++
(publisher out of off : hey there more antique techniques you can elaborate and reinvent for an adaptive and creative usage - let's write an entire season or trilogy ;-)
i wonder what the idea was behind using the same filename for A something and B something?
regarding "outside the search path"; that is exactly what /Application Support in macOS is for.
I will repeat it again :
my personal way is : no abstractions or non embeded stuff.
It might seem too much work to allways paste, embed etc , but it pays
when it comes to portability, serving in different max versions, OS etc.
end of discussion for me.
only exception are poly subpatches, where one has no choice.
For that reason and my complete lack of interest in Live
I can't contribute anything else to the topic.
@Roman Thilenius ... reasonable question and this most probably has "gone under" in the lots of text I wrote ;-)
Long story short : it was an idea to adapt my experiences & habits from object oriented software development to Max respectively Max for Live, especially for the reuse of code ... hence Max Abstractions.
Explicitly : thinking Max Abstractions as classes that uses other Max Abstractions as their methods and as 2 classes might have both a method named "advanceModulation", a different implementations in each class, there would have been a need to distinguish them in Max to prevent a namig collision.
But this idea has passed over ;-) ... the more I patch in Max, the more a new "coding style" emerges ... Max seems to be much more about (maybe it is all about) designing a "flow of data" - so its very different from the tradintional approch in software development, where one tends to design an architecture of code first, where data for sure plays an important role, but in a very different way.
Or in other words : the question arose from a "object oriented thinking" and trying to workaround the nature of Max ... which does not make much sense ;-).
yup.
what is also therorectically possible is using the same names for abstractions or media files in different /packages or custom subfolders and then move them out of the search path when you want to work on another project.
and again, we would still recommend against it.
if you want to connect with the max world you will go even one step further, and use nametags for all your filenames, so that i can install your files in my max, too, without running into conflicts.