Subpatch path resolution

#1

When a subpatch is being inserted in a patch, its relative path is only correctly established and saved in the main patch if the subpatch was in the same branch as the main patch.

If the subpatch is taken from a different branch than the main patch is saved in, the subpatch appears as a zombie when the patch is reloaded.

The upshot of this is that subpatches can't be used like library objects, which to my understanding is part of the point of having them. They will have to be copied to the same branch as the main patch. Thus it's not possible to use subpatches that are maintained in a central location, such as in the axoloti-contrib or axoloti-factory (library) branches.

Being able to use subpatches from the local or git libraries, or any folder of the users choosing, would surely be a good thing. In my view, and that of a fellow user I've discussed this with, this would be essential an intuitive.

Why has the current mechanism been chosen, and would the developers consider inserting the relative path in the patch files in all cases?

#2

Sorry. I took notice of your previous post about it, but haven't found time to look in depth yet. I certainly plan to diagnose/address this soon!
Not being able to use subpatches from libraries: when saved as a subpatch file and present in an object library they're not referenced by relative path (well only relative to the object library root), making it relative to the patch itself would prevent moving the patch to another folder.
What OS are you using? It may also be related to the mechanism resolving a relative path from two files.
Keep in mind my answer here is before looking in-depth...

#3

yeah, the relative to patch needs to be reviewed.
I suspect it may be related to an area that has a workaround on it (but may not be)

the subpatch loading uses a full path name, which is then matched to a library by looking at the libraries path.
this really is a workaround, to avoid having to rewrite the object matching logic,which before was based on a single path.

what really we need to do, is to know which library an subpatch was originally loaded from, and then load it from there. path should be irrelevant.

objects do not suffer from this for 2 reasons, a) they have a UUID (we could add this to subpatches!) b) objects are all loaded/resolved at startup. (this is probably going to have to change in the future as the object library grows, but that needs a rewrite of not only loading but also the browser)

I do wonder if subpatches that are placed in a library (using 'add to library'), should be treated differently to relative subpatches... i.e. get a uuid, and make them more like proper objects. Its certainly true that subpatches in a library we want to behave as if they were objects (as much as possible)

(think obsolete objects, and that we might end up with obsolete subpatches!)

#4

Sorry, forgot to mention the platform: Axoloti 1.0.10 on Windows 7 64 bit.

This issue hit me when I went from object-developer mode to end-user mode, as in actually starting to build my "real" patches. If not exactly a show stopper when in end-user mode, I either have to keep copying updated subpatches to my project folders or re insert, embed and reconnect them, which is a bit of an inconvenience.

As tb mentions, perhaps it's an idea to use an UUID binding for subpatches residing in libraries, and the relative path if the subpatch was not inserted from any of the registered libraries. That would cover most use cases fairly solidly, I'd think.

I appreciate that you'll look into it :slight_smile:

Edit: perhaps it's best to delete the "residual" thread "Subpatch loading issue" in the Helpdesk forum.