This site relies heavily on Javascript. You should enable it if you want the full experience. Learn more.

GenericNodeTest

I am from Add anything with a single node, and Cast to anything with a single node ;)

microdee, Friday, Feb 19th 2016 Digg | Tweet | Delicious 10 comments

graphicuserinterface 20/02/2016 - 01:23

the pin outs change at pin in connection?? wtf, seems really cool!!

microdee 20/02/2016 - 02:57

yup ;) there's one major bug yet which is links are not created when loading patch, and also that's a conceptual problem if connected is nil then obviously it can't detect the types of an object.

tonfilm 20/02/2016 - 03:18

similar problem with this plugin: https://github.com/woeishi/VVVV.Struct
if you find a solution, let us know...

velcrome 20/02/2016 - 07:16

this is wicked!

what usually helps with first frame issues:
Lock down the full Name of the last valid type in a config pin, do so every change. It will get saved to v4p and after load the contents of the pin help you to recreate your pins in OnImportsSatisfied

then you should see connected pins.

microdee 20/02/2016 - 15:12

thanks for the tip I'll do that probably. it will help with the nil problem too.

woei 22/02/2016 - 15:59

@tonfilm: fixed that, check the develop branch.

@microdee @velcrome
reading the config pin OnImportsSatisfied might return null or default. as far as i found out onimportssatisfied just means vvvv has created the plugin. it doesn't mean that pins are filled with the values of v4.

to be sure to load config pins i had to listen to IDiffSpread.IsChanged and us the returning value except for nullordefault. change can trigger twice on init of the plugin (imho when duplicating the node)

microdee 22/02/2016 - 18:19

is the changed event occurs before building up the links in the patch?

woei 22/02/2016 - 18:32

works fine for me at least.

through trial and error it looks something like this:

construct nodes along v4p xml -> onimportssatisfied on the plugin
onpreparegraph: walk the nodetree
io on config pins
io in/outs

not sure, at what point exactly the links are built. vvvv creates tries to create them along the v4p file. so as long as the pins you create match the ones saved ones you don't loose the links.

that's why you might want to check for nullorempty configs. because if you create them wrong, even if within the same frame, you will lose the links no matter if you create the right ones right after.

velcrome 23/02/2016 - 01:42

if one needs all other nodes to successfully evaluate at least once before you go, does this help?

FDiffSpread.Changed += (e) => FHDEHost.MainLoop.OnRender += MyHandlerForDiffSpread;

is there a mainloop event that's being called just at the start of the next evaluation, which should always be at least the second full evaluation?

microdee 28/02/2016 - 00:31

I've got it working! so first of all now it outputs the lowest common type of the spread as you can connect assignable types anyway. so it won't make a pin for every type just have a single output pin which i replace if input lowest common type is different from the saved type in the config pin. so i followed woei's advice. it didn't kept connection first and i realized that the reason was that IDiffSpread.Changed occurs twice when the patch loaded. First it's the default value what you define in the input attributes and the second occurrence is the actual value loaded from the saved .v4p . so now that I check for this situation and invoke true initialization when config pin is !=default (in this case simply empty string). Of course this means that in my case there won't be any output pin when you create the node but one will be created as soon as you connect anything to input pin.
i hope this helps!

GenericNodeTest

Shoutbox