Dynamic plugin: Turn on/off an output pin visibility using a input pin in same node

vvvv beta question
1

Yo devvvvs,

Making a twitter plugin which has so far 47 output pins(and more coming…). It looks a bit mental to have so many output pins… So…
Is there any way to control an output pin visibility from an input pin? Rather than having to turn on output pin visibility in Herr Inspektor… I am not looking at dynamic number of output pins (so dynamic value template does no apply here) as I have a set number of output pins which never changes. What I am trying to do is when you toggle on a bool in an input pin it turns on one output pin’s visibility… The idea is I have a spreaded input pin in my plugin which controls what data you want to retrieve from a tweet. For example you might want to turn on Tweet coordinates, which means my plug in will then retrieve tweet coordinates, which then means that the “tweet coordinates” output pin should now be visible. Idea is you turn off “tweet coordinates” in search control input pin and boom it turns off the “tweet coordinates” output pin and vice versa and for all search controls. Woudl be really nice as then my plugin only output pins are the ones you need not all 47 possible output pins (you might only want to use 10 of those 47 output pins). Is this even possible? I can’t seem to be able to turn pin visibility on or off after the pin declaration? Cheers.

Attached a screenshot explaining a bit…

And link to image file in case the above image is appearing too small in this forum post…

EVVVVILTWEET2.jpg

2

this contradicts with vvvv’s design pattern, you should never have data control the pin visibility because this can potentially break links in patches. you can however create configuration pins which control the presence of the pins one wants to have.

another clever way would be to make just the basic outputs and one output with type Tweet or so, and then smaller getter nodes with just a few output pins which will get data out of the Tweet object by topic, e.g. one for date/time related data, one for tags, one for user data… this also has the advantage that you can send the Tweet around in your patch and get the data where you need it without having big nodes laying around.