remoting vvvv / exposing pins / kontrolleur
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) 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 Value 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) 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.
- 1
anonymous user login
Shoutbox
~13h ago
~7d ago
~7d ago
~8d ago
~21d ago
~1mth ago
~1mth ago
~1mth ago
~1mth ago
~1mth ago
great thank you!!! Let s get this Control UI builder rolling.
control-(androidosc)-ui-builder
here you can grab both mine and woei's (much better then mine) code for Control
sick :)
Kontrolleur crashes on launch at Android 4
hei bo, iirc someone mentioned disabling 3g to make it work.. i don't have an android 4 device here to test.
Hi joreg. Seems this asus tablet has no 3g module(
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)
since there is no magic built into vvvv to do this thats exactly the way to do it. you can send the list of exposed pins to any device that can display sliders and send values back.
the Feedback Target IP is the IP of the device that you want to send (exposed) values to when they are changed in the patch.
hm, is there (yet) any feature, that allows you to change namings like 'Y Input Value' to something that's in the descriptive name?
+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 :)
kontrolleur should take over descriptive names of ioboxes for display.. or what do you mean?!
Not using kontrolleur, just using a control tablet running vvvv. Right now in order to label the sliders on it I've sent over udp all the exposed pin osc addresses the same as kleinkariert, and then another list of the descriptive names via getpatch.
@joreg: +1
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 Name in Server (vvvv).
(is that what kontrolleur does inside?)
right Kontrolleur (Network) duplicates some functionality of Server (VVVV). and it sends the pins name alongside their nodepaths to kontrolleur..
so ja, an extra output that returns all descriptive names sounds plausible..
great feature joreg!!! everything is getting much cleaner and elegant ;)
+1 for Descriptive Name in Server(vvvv)
...as far as i'm thinking, it's the only way to have a flexible but robust newtwork with dynamic parameters assignment.
(you always know that this specific exposed IObox will always be "the size of this quad", even if it's OSC assigned tag changes).
the IObox descriptive name could be assigned into the inspector, in a "custom tag" section.
ciao
:)
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.
Right. Which is also where it seems like todomap is going, but it feels to me like Server(vvvv) and todo are atm separate tracks and both missing some parts for a fully adaptive system.
discussion continued over here: remoting-vvvv-exposing-pins-feature-suggestions
Today I was looking at Exposing again and I have a few questions, because I am not sure if I missed something.
1) how can I find out or even use the Tag of an exposed iobox? using it as osc address does not seem to do much good.
2) is it possible to extend the possibilities so it can handle Transforms, Streams and Colors? Can we do it or is it in the closed core parts?
3) why is the feedback only mirroring manual inputs but not ones that get set remotely?
4) i don't understand what the Cached Pins is supposed to do. Please be so kind and elaborate on that.
1) 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)? 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
2) 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
3) not sure what you mean here. the idea of the feedback is to mirror values you change in the patch on your device.
4) cached pins are those which have been written to at least once. so you can set Accept to Any, write to some pins and then set Accept to OnlyCached and then only those will be able to receive further values.
1) there is a config pin on every IOBox called Tag. maybe i was presuming too much, what is this really for?
2) 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.
3) 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?
4) aha, that makes sense. it got me confused that Server (VVVV) caches only when set to Any.
1) 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.
2) well for color and enum you just set them strings representing their data (ie. as saved in the .v4p)
3) 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).
1) For me, Tag gets very powerful when you use PinInfo-(vvvv) in order to group data.
3) I think velcrome is right to expect feedback in any case. Since for sending and receiving we define different ports, it is the user's responsibility to avoid feedback loops.
joreg,
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:
3. As said, sending out OSC Feedback when incoming connections change the Y Input Value. Any chances to hack that?
(Otherwise, i'd have to place OSCEncoder-(Network) at many locations in the project or gather all of them to centralize OSC Feedback from MIDI devices…)
5. I would really love to be able to specify "nice address" for Server-(VVVV) using the Description (or Tag) instead of the ID.
6. Parameter Value Queries
Currently, i can't read the Y Input Value 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.