Hi
Double-click on background and typing name in node-browser isn’t working any more, subpatch isn’t in the list. Tested in 50beta35 and 50beta35.5. Subpatch is definitely in subfolder and I’m in a scenario that is working in 45beta34.2.
Made a testpatch to confirm, same there.
Anything changed? Any option I missed?
where is the testpatch?
Oh, gone with the wind. It was just a subpatch in a subfolder; an input, a plus node and an output.
please attach.
linking test.zip (3.3 KB)
The zip contains a “projectfolder” which i had put into my projects (which are also linked in root patch).
In 45beta34.2 I can open toplevel_patch.v4p, double-click and type name subpa… to find the subpatch, in 50beta35 this doesn’t work.
Hm, it also keeps on loosing connection to more and more subpatches in subfolders. Those are linked throughout my project and have been working fine in the past.
Also I can’t see any system behind, sometimes when I open the project it is as it was before, sometimes subpatches are gone.
It became pretty painful to work in 50beta35.x. Sorry to annoy you with this.
regarding the demo in your .zip: confirmed, there seems to be some changed behavior, thanks for the report. what works as a workaround: name the subdirectory “modules” and start all modules with a capital letter to have them show up in the nodebrowser.
note: this is only a problem of the nodebrowsers filtering, it does not influence the loading of saved patches.
how is this related to the initial bug-report of the nodebrowser not showing certain entries? please provide a reproducible demo. or, if it is not related please start a new topic about it.
Thanks for checking back and the work-around!
Not sure if the second issue is related. Both regards subpatches in subfolder, thus I thought it might.
me neither, and you are the only one to find out and make a more detailed report. from what you wrote so far i’m afraid i have no clue what that could mean…
Weirdly it became reproducable:
broken_link_after_reopen.zip (17.9 KB)
I opened the subpatch (regular open dialog), then copied its node from the root patch, pasted it into toplevel_patch and for the time all was working. Pins accessable and all. After saving toplevel_patch and reopening the link is broken, red node.
The file path shown when hovering over the node is correct.
Any idea? Or did I make a mistake that I’m too blind to see?
ok, from my understanding this seems unrelated to your initial question. i couldn’t reproduce your description but it seems whats happening is this:
have you noticed that when saving a patch you get a notice saying:
You have saved the patch to a different path. If you are using relative paths in your patch (for subpatches, textures,…) they may no longer be valid the next time you open this patch!
so when you save a patch to a different location its relative content (subpatches, textures,…) may get out of sync and you’ll have to manually make sure to fix those paths.
the tooltip of the subpatch shows the path that it was last found at to give you a hint where to look for it. hope that explains.
I know this message from the past, but it hasn’t happened popped up. Also I haven’t been changing directory, it was a simple “Save”, not “Save As”.
The tooltip’s path is still correct, thus shouldn’t the link still be working?
the tooltip shows
…\Users\mf0x\Documents\vvvv\my projects\projectfolder\sequences\subpatch.v4p
which means from whereever your toplevel_patch.v4p is placed go one directory up and then go down "Users\mf0x\Documents\vvvv\my projects\projectfolder\sequences" to find subpatch.v4p
that would mean your directory structure should look like:
C:\foo\toplevel_patch.v4p
C:\Users\mf0x\Documents\vvvv\my projects\projectfolder\sequences\subpatch.v4p
is that the case?
There might be the issue.
toplevel_patch.v4p sits in “C:\Users\mf0x\Documents\vvvv\my projects\projectfolder”.
Correct relative link thus should be: “sequences\subpatch.v4p”
or “…\projectfolder\sequences\subpatch.v4p”
I misread the tooltip as starting with just “” instead of “…” - which would be a correct absolute path.
Ah, got it!
Issue is because of copying the patch over from root-patch. The long relative path is correct as seen from root, incorrect as seen from toplevel_patch.v4p’s location.
Hm, just strange that everything worked initially, only after reopening it is broken.
Would assume the path to be updated during copy&paste.
And now it does exactly that - path updated during copy&paste. I just tried again.
Really can’t say how/when it happens, this copy&paste-fails-update. :/
Maybe related?
Thanks for finding those!
No special chars in the file name in my case. Unless space counts?!
Is this “SHIFT + ALT + P shortcut which makes paths relative” still working??
SHIFT+ALT+P is still active but should hardly ever by needed as this happens now automatically whenever possible. anyway again, since this is not related to the initial topic, please start a new forum thread if you find a case you can reproduce and try to be as explicit as possible in how to reproduce it.