Forum

Remoting vvvv / exposing pins feature suggestions

vvvv beta feature
#1

Hello everybody,

Let’s make this post to collect all the ideas-suggestions-considerations that can be useful to improve the new AMAZING remoting feature, wich allows to write to IOboxes directly from the network via OSC.

Server (vvvv) node gives the OSC tag of the exposed IOboxes.
this tag is auto-generated by the software and it’s related to the pin itself, the position of the IObox into the patches, etc…

suggestions:

1)

Possibility to set a custom OSC address instead of the auto-generated one
usage example:

I have a module with many parameters, each parameter is exposed over network thanks to ctrl+k and Server node.
if i want to control these ioboxes from external interfaces (that could be placed on a different pc/devices) i’ll need static OSC addresses in order to always address correctly data to every IObox.
There’s a parameters called “quad scale”; would be handy to be able to set a custom OSC address like “/quadScale” for it;
In this way any external interface doesn’t care wich is the automatically generated osc address of that IObox; the external interface just sends a value to “/quadScale” address, and you’ll be sure that even if your patch changes your OSC mapping will be stable.

2)

I suggest also the Server (vvvv) node should outputs other info about the exposed IObox, for example the Descriptive Name and the Tag config pins, but also other informations like min-max and Value Type.

this could be usefull in an open scenario where IOboxes are not just stupid containers that receive wethever it comes but they can also provide informations about the data they contain, data used by interfaces to prepare and send values in correct formats.

Let me know what all of you think guys.
ciao

#2

We were talking a little bit about this here: remoting-vvvv-exposing-pins-kontrolleur

Been finally taking a closer look at todo map over the last couple of days (thanks vux). I think now that it also works with exposed pins that it’s actually pretty close to providing all of this + more already. That said having a bit of trouble getting it to stick, did not want to go OT in this thread so made another here: https://discourse.vvvv.org/

#3

I also played a bit (not soo much unfortunally)with todo map and i agree that is super cool.
It’s perfect in a plug and play scenario with one pc and some external ctrl interfaces.
Problems come when you start to consider more complex pc networks.

  1. you can’t write to todoMap variables using a fix OSC address; the only way to write to todomap variables is the mapper learn the source.
    this is a problem in a dynamic modular scenario where sources of data can changes case to case.
    Any module-interface should be able to directly write, whenever it want, to every variable of todomap, without “asking permission” and be routed (being manually learned) to that variable.

  2. another problem: exposed pins feature doesn’t work on network.
    imagine i’ve a render machine with some modules. each module has many exposed parameters.
    my todomap is placed on another pc, the “manager” pc, where is connected also the ctrl interface.
    how can the todomap know, integrate and manage the exposed parameters on the render machine?

Maybe i’m missing something, as i told i’m not super experienced on this topic.
let me know

#4

I’m really just starting with prototyping right now, would like to have something more solid soon but it seems the way to go to figure out what works and what’s needed.

Definitely looking to get to a solution that is enabling completely adaptive interfaces, or as sebl said

Some thoughts on your points:

  1. this is true, but you can patch it to automate the mappings. I’ve attached a quick hacked up demo.

  2. I guess the best way would really depend on how your network is supposed to work. In your example I’m actually thinking that the todo or Pinserver should in fact be on the render machine. You can still send it’s results over the network to interfaces but I think it really needs to sit where the outputs are or?

#5

forgot to attach patch

AutoMap.zip (3.2 kB)

#6

hey everyoneishappy,

  1. yes, the result of your workaround patch is what i mean. but it’s clearly a workaround: by this way you can’t assign specific control data to more then one variable in the same frame. if you have 200 variables you will spend 200 frames to initialize them all.
    I suggest there should be a node that allow you to simply write the Control Data field of the todomap; something like a TodoSetControlData node.
    let’s see what mr vux think about it.

  2. you’re right, it depends on how your network is supposed to work.
    if we have a monodirectional structure (straight flow from interface to output) we just need to map the source to the parameter, and todomap it’s perfect for that.
    another scenario:
    we have a cloud computing approach, in wich every pc in the network does something specific, creates data that can be used throw network (better: each pc contains n modules, each one makes something and provides results in local and network).
    there’s a render machine where we have all the final parameters to be controlled.
    we need a manager that orchestrates the data flow, that tells each module in the network where to send data.
    (a simpler approach is to collect all the data from network in the manager, choose what you need and send it to the render machine. this approach leads to network data redundancy, in fact data can bounce many times before reaching the final target)
    In this scenario we need a dynamic dislocated routing of data.
    the render parameters just listen always to the same osc address, it’s just the system that sends there data from different sources.
    with this approach the cleaner solution for parameters in the renderer it’s just to expose them, assigning them a unique fix OSC address.

…sorry if i couldn’t explane better the thing, quite in hurry…

yo

#7

+1 for static /address!!
I understand the need of them when you’re tryng to distrubute calculations in a network and manage the dataflow.

PS: In general it’s better to name /things in a custom setup…

Cheers

#8

Dottore, are you talking about mesh network and star network? as defined here: http://en.wikipedia.org/wiki/Network_topology

So ‘simpler’ as you say would be exposed pin array on each computer receiving signal and providing feedback to a ‘virtual router’. What would be a scenario where you would want to use a mesh topology instead?

Another use case I’m very interested in is multiple vvvv users collaboratively patching over the web. I’ve been looking in to solutions like node.js or hole-punching to achieve this and seems very doable. But more relevant then the technology to this discussion is:
A) is this something that others are also interested in
B) how this might work in terms of design.

Only a subset of exposed pins? Only exposed pins? Mulitserver boygrouping?

#9

well as you know with modern osc controllers it’s prolly would be /1/Fader00
i mean it’s exactly why we use todo for that, might you want it on midi also
but it’s possible to add something like that for exposed pins, quite nice idea, did’t try server node tho

#10

hey everyoneishappy, nice link! :)

the physical topology of the network is the star one (each pc connected to a unique switch-hub).
the logical topology of the system i suppose would be mesh (partially connected mesh or fully connected mesh).
i included the fully connected mesh topology because EVERY node of the network can talk to all the other nodes; the network i previously exposed, the one with the render machine as output, it’s just one case; you could have a module on the render machine that provides data to other pc in the network, so even this render machine is not just a “leaf”.

the simple approach i described (the one with “manager”/“virtual router” that orchestrates all the nodes)is the easier to build but not the more optimized:
it would be a star logic topology; in this scenario modules can’t see each other, so if one of them requires some data from another, it needs to pass by the manager (sending request and data double times).

what i’d like to do is a more efficient way of manage module intercomunication:

  • every module has a map that describes the network structure, where all the modules are dislocated.
  • if it needs some kind of data from a specific module (eg. a module that provides animations) it just send a request to the module (wherever it is in the network) providing him all the information about the type of data needed and eventually where to send the resulting animation over the network.
  • each module in this network just do what is asked for and provide data where they are required.
  • basically there’s no more difference between local and network module interconnection: the module just send to the target, that can be placed on the same machine or into one other (it knows where the target is thanks to the network structure map).

About what you’re interested in, multiple vvvv users collaboratively patching over the web:
once you’ve got a flexible module network that works in LAN, it’s not too far the possibility to dislocate network nodes over the web, using VPN (Virtual Private Network) (http://techmonks.net/lan-over-internet/).
Once the virtual lan is created you could have people working remotely on some modules over their machines; they could get requests and provide data using the common protocol.
eg. you could dislocate a control interface on the machine of a friend placed in another country, and he could join a design session playing with it and maybe looking at the output throw a skype video call…or having a duplicate instance of the render output on his machine.
theorically you could have a gig from home, sat on your sofa with your ipad interface hehehee

apart from all these network discussions, i think a custom OSC address for the exposed IOboxes is quite a required feature, for any scenario…

ciao :)

#11

ad 2)

latest alpha builds include a new node: PinInfo (VVVV) which takes a pin-path as input (as it is returned by Server (VVVV)) and from that returns:

#12

ad 1)

basically that could be simulated with a little ReceiveOSC (Value/String/Color) module, right? the module would have an Address input and would exist with outputs for different datatypes. internally it would have a R (String) that receives the the global OSC-string (that is received at one central place via UDP (Server) and distributed to all those modules). then it would have an OSCDecoder (Network) to check for the given address and convert the data to the specific value-type for the output.

by using such a system it will not only work with ioboxes but any pin. so instead of creating an iobox and exposing it you’d create a ReceiveOSC module and give it an address. would that be it or am i missing something?

#13

what we lack is small adress string thing on inspektor on exposed, so you can add an osc address directly on iobox so then todo and server knows what this address io assigned to, then the question is how to handle the spreaded io like this?
think we do now ctrl-0 ctrl-1 … if you expose spreaded io so, why don’t we add “-” and number straight to address like that
questioning me would be ctrl/0 ctrl/1 more reliable?

#14

hi joreg,

2)

PinInfo node is exactly what is need to distribute information about IObox receivers over the network.
we could put OSC address in the name and that’s it… actually would be possible to output also IObox’s tag from PinInfo? would be cleaner to keep separate Node label from OSC address, at least in patching.

1)

The most simple scenario i see is that you just set the OSC address in the IObox and, if exposed and found in Server node, it receives on that OSC address.
As far as i understood (maybe i’m wrong) the Server node it’s the place where OSC data are routed to IOboxes using their OSC address. It could be that if you set an OSC address in the IObox’s tag, Server takes that one instead the default one.
would something like this possible?
yo

#15

(if you put the same OSC address in two IOboxes they should receive the same data; Server should distribute)

#16

Hey vvvoolks,
I do not know if this thread is the right one for my post, but looks connected somehowish ;)

I am playing around with Server node, OSC and touchOSC…
I am trying to create a plugin & module for auto generating a layout for touchOSC, based on the exposed nodes and osc communication based on Server node.

In short: I did small plugin, that scans all exposed nodes, extracts the type/name/subtype/etc… data and generates layout file that can be opened in touchOSCEditor. The auto-generated layout file can be edited and/or sync-ed with your touchOSC app via the TouchOSC editor. This I got somehow working in the last 2 days ( I will release it sometime now)

The problem:

What I do not understand is why only exposed inlet IOBox-es( and etc…) are sending/receiving data via OSC. Why not when exposed IOBOX is connected as outlet also to be possible to send its data via OSC when it changes? What do you think?

Am I missing something here?

Note: I am not using Kontrolleur because I want to connect v4 with iPad and with touchOSC. Is there other funky osc/UI software for iPad? Better where I can create on-the-fly the interface directly via udp/tcp…

regards

#17

@dottore:

  1. tag shall be out on PinInfo shortly. (even though not exactly the best place…)
  2. i do get what you want, but you did not answer my question. whats the difference between what you want and the “workaround” (udp/receiveosc,…) i outlined above? to me not much but a bit of usability and mine is more flexible. what do you think?

@zeos
sounds good. exposed outlets…will think about it. concering other tools…the most promising to me was “Control” but there haven’t been many news about it lately: http://charlie-roberts.com/Control/

#18

@joreg: control - ha, sounds nice: http://charlie-roberts.com/Control/?page_id=297, i will check it again and write back. Can I modify the server node code in devel and use it in beta, does it use some special alpha/ devel features?

@dottore: +1

#19

@zeos: yes, server-node should work with beta as well

not sure what you mean with that?!

#20

well finnally my varible naming system for osc controller:
PATCHNAME/GROUP/NAME/0
PATCHNAME/GROUP/NAME/1
PATCHNAME/GROUP/NAME/2
PATCHNAME/GROUP2/NAME/0
PATCHNAME/GROUP3/NAME/0
etc…

quite fun with exposed, you actually see buttons presed in 2-d machine interface, but if it would work sameway straight from server node like:
you do exposed iobox
you add adress to it,vvvv automaticly adds /0…999 in the end meaning witch slice is it, address could be taken from name of iobox…
then you broadcast it to remote host and have an instanced version of you io meaning same io pressed on any computer will be feedbacked to others
and with todo you can even apply midi controller coool
i want that ;]

© vvvv group