Difff node- vs file- vs systemname

testing the packs difff following came up:

just changed the nodename (seen via getpatch) resulting in a red node since the filename remained the same.

checking the vvvv difff.xml it’s a little obscure how to handle filenames (e.g. for moving/renaming files)
i just see lines like

hei woei this should actually just work. here an actual example:

<NODE old="HTTP (Network Get)" new="HTTP (Network Get Legacy)" />

filenames don’t matter. they used to some years ago, when we had those :MODULES: variables but meanwhile only the nodenames count. so unless you’re dealing with ages old patches things should just work. can you share the specific example?

i tried with the demo testPack in the sdk replacing the Foo (Test) with any other patch of mine (without category)

so happy or not?

not happy.

maybe i should have added that i tried with testPack… and it didn’t work.

use cases for moving and renaming outside of modules etc folders are mainly refactoring reasons:
moving/renaming subpatches, effects, vl plugins,…
think big projects with a lot of files, importing parts from other projects, restructuring, renaming pins without loosing all the connections

turns out you have to move the pack into the packs folder to get converter going.
i’ll do a readme that points out this issue.

i added some help. and demo patches that get renamed. i think you might need to stick to the naming scheme name (category version) to make it work.

jop,

assumed, that the pack has to be in the pack folder anyways. so first featurerequest:
additional commandline option ‘/difff filename.xml’

was afraid, that the mechanism only works with ‘Nodename (Category)’. while this will probably work out fine for fx, not sure how well it will perform when renaming/moving vl/plugin/dynamics where the actual nodename doesn’t change (since joreg stated above, that filename doesn’t matter, i guess the mechanism is only dealing with nodenames). and also not sure, if i should start giving all my subpatches a category in order to have them being handled by diffffing…

so second featurerequest (not so urgent since i imagine, it’s quite more work in the back for you) is to have diffffing being able to handle filenames, e.g. ‘newfilename=“xx”’

first one would be great, thx!

Can you elaborate more on the first feature request?
Is it about adding a path to the list of available packs or just pack converters?
Would it be ok to have the version.info file besides?
Is this something that helps you developing a pack or where do you need it for other purposes?
Is it necessary to be able to add more paths?

my idea was just to have a possibility to quickly force vvvv to run a converter. so my usecase is nothing that should be around permanently like a pack or anything. just for these cases during production, when you need to refactor and have the affected nodes (and or pins) in use in a lot of places already.

right now i have to go through all v4p xmls and change a path. with pins its even more cumbersome, since i have to find the all the links and rename.
renaming pins in runtime is kind of okey, when you have just one instance of the node. otherwise you have to go an redraw a lot of connections.

so something like a quickdiff, without version or anything. just a possibility to trigger that mechanism. using at my own risk.

so:

just about a not permanent converter.
would be great without version, when triggered always consider current state an old version
not for packs, the mechanism as is works fine for packs. really for production, refactoring and cleanup
just one path should be enough, i only want to do that once and save

in upcoming alphas look into the testpack folder. There is a manualdiff.xml with further instructions.

just needed the /manualdiff option, works as expected in b36.
thx!

oldfilename to newfilename request still persists though.

just in midst the usecase:
developing a set of nodes in a plugin. the final step is cleaning up namings. pinnames and nodenames can be handled nicely. renaming the .dll breaks proper loading. (in this case the (debug)patch pics up the csproj next to it and creates dynamic plugins instead of taking the renamed .dll from bin/AnyCPU/Debug)

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.