here is to announce a little feature nobody has asked for:
basically you can now write a value/spread to any pin of a running vvvv-patch from the outside. sick? yes.
the plugininterface now allows you to write to any pin which is in turn used by a new node called Server (VVVV)node which listens for your udp/osc-messages and distributes received values to the targeted pins, like so: /40/30/2/Y Input Value 2.4,2.5,2.6 sending the above osc-message to the vvvv-servers port will set the Y Input Valuepin of the node with ID 2 which sits in patch with ID 30 which sits in patch with ID 40 to a spread of: 2.4 2.5 2.6 see? should allow you to quite mess around..
now of course you don’t want to do this all random and find out about the target-addresses manually. as mentioned in a previous posting refactor-to-subpatch there is one primary shortcut left on vvvvs keyboard cheat-sheet which we saved for this moment: ctrl+k (read “kontroll”) allows you to expose selected IOBoxes for being controlled from the outside. first exposing only turns IOBoxes green, but inside this sets a flag on the node that can be accessed via the plugininterface which e.g. allows a node like the afformentioned Server (VVVV) to return a list of all exposed pins’ osc addresses…
next it would be nice to write values to such exposed IOBoxes from, say a mobile device. this is where Kontrolleur (VVVV)node steps in. essentially just an alternative, more specialized vvvv-server that pushes information about exposed pins to the Kontrolleur android app. check its help-patch for instructions.
and like Kontrolleur (VVVV) it could also make (even more) sense to code a plugin that communicates with Control (which seems to be in quite a rework for some time now so i didn’t dare touch it) or one that exposes pins via even other protocols (http, whatnot..)
all necessary functionality (reading of/writing to pins, listing exposed pins,…) is accessible via the plugininterface. you know what to do..
now available in latest alpha builds.
Comments:
Comments are no longer accepted for this post.
forum
here you can grab both mine and woei’s (much better then mine) code for Control
yes.
for now, i have a patch that extracts all descriptive names from all exposed ioBoxes in my setup and fiddles them together with the osc part before sending that whole list over to my controller (what is a patch on another machine)… that is like the opposite of elegant.
** so, i’d suggest that the most flexible way would be a Descriptive Namepin in Server (vvvv)node.** (is that what kontrolleur does inside?)
right Kontrolleur (Network)node duplicates some functionality of Server (VVVV)node. and it sends the pins name alongside their nodepaths to kontrolleur..
so ja, an extra output that returns all descriptive names sounds plausible..
finger » hand:
would be also noice, if some other properties could be in appropriate outputpins as well. think about type/subtype, min/max etc. with that information on your remoting system, one can easily remote an ‘unknown’ system.
Today I was looking at Exposing again and I have a few questions, because I am not sure if I missed something.
you mean the address (not the tag), right? or otherwise i don’t get the question.. have you seen the helppatch of the Server (VVVV)node? there you should get an idea about the addresses of pins. they consist of node-ids (of all of their parent-nodes/patches) plus their pin-name
colors and enums should be easily possible, see https://github.com/vvvv/vvvv-sdk/blob/develop/vvvv45/src/nodes/plugins/vvvv/Server/VVVVServerNode.cs for others my guess is it would need some internal work
not sure what you mean here. the idea of the feedback is to mirror values you change in the patch on your device.
cached pins are those which have been written to at least once. so you can set Acceptpin to Any, write to some pins and then set Acceptpin to OnlyCached and then only those will be able to receive further values.
there is a config pin on every IOBox called Tagpin. maybe i was presuming too much, what is this really for?
i see that it is possible to find out about other exposed ioboxes besides strings and values (especially the Node iobox is doing quite some funky tricks), but i was wondering whats necessary to remotely set them.
i try to be more descriptive: feedback happens only when i change the value of an exposed input iobox by hand. if a value change happens to an exposed input pin by a local (or even remote) osc message, it is not feedbacked. if it is a exposed output pin it is not feedbacked either. why is this?
aha, that makes sense. it got me confused that Server (VVVV)node caches only when set to Any.
thats just a user-string without functionality attached. but can be used by plugin-writers to read its content and to stuff with it. like e.g. for exposed pins you could specify a subtype and then in your interface react to that.
well for color and enum you just set them strings representing their data (ie. as saved in the .v4p)
that is the idea: reflect manual changes in the patch back to a remoting device. if the value comes from remote i don’t want it to be sent back to it. if syncing multiple remoting devices is what you’re looking for than i am afraid this is not handled, but should only be a matter of reworking Server (VVVV).
joreguser, sorry for gravedigging, but this is coherent with above posts: Over 2.5 years passed and again i’d die for obvious enhancements of the IOBox exposing feature:
As said, sending out OSC Feedback when incoming connections change the Y Input Valuepin. Any chances to hack that? (Otherwise, i’d have to place OSCEncoder-(Network)node at many locations in the project or gather all of them to centralize OSC Feedback from MIDI devices…)
I would really love to be able to specify “nice address” for Server-(VVVV)node using the Descriptionpin (or Tag)pin instead of the IDpin.
Parameter Value Queries Currently, i can’t read the Y Input Valuepin of Exposed Nodes in C#? I browsed the PlugInInterface documentation, but couldn’t find any elegant solution. As a powerful alternative, the OSC protocol standard in (5 Requests for Information > Parameter Value Queries), defines a behaviour that if you send /current-value to an address, the target answers the value. Wouldn’t that be a huge benefit? What kind of effort is gonna be the price?
ad 3) i still don’t get that usecase. the original idea is: you have IOBoxes that have connections only from their outputs. you expose those. you change their value via a kontrolleur. so far normal use. then if you allow feedback it means: if you change the IOBox in the patch that change is also reflected on the kontrolleur. so what is missing exactly?
ad 5) understandable, but would need some thinking and coding
ad 6) you can use IPin2.Spread to get/set a pins value: /pluginspecs/html/P_VVVV_PluginInterfaces_V2_Graph_IPin2_Spread.htm
the osc-specification you refer to is an interesting find. to my understanding though it is not the one everyone is working with today, which is this: http://opensoundcontrol.org/spec-1_0 and this one does not have that idea of “discoverability” built in.
Thanks for this really nice feature and it works like a charm!
Since I am not so interested in android devices I wondered if it is possible to get a server-node on your control-pc to show the list of exposed pins from a second target-pc? Maybe it was my stupidity but I was not able to get this running… So I am now sending the server-list “oldschool” via udp(network client) to know whenever a new IOBox got exposed.
changing the “Feedback Target IP” does not seem to make any difference.
@bo27: forgot to mention: Kontrolleur beta2 fixes those issues. (need to reinstall from android store)
the Feedback Target IPpin is the IP of the device that you want to send (exposed) values to when they are changed in the patch.
+1 Would be really nice if the io box is given a descriptive name, that that is what is used by default for the osc address, and otherwise just the raw ID.
Cool feature in general though :)