Dynamic remote spreads concatenation

vvvv beta feature
1

Hello people, hello devvvvs,

Having to do with dynamic modular systems I found something missing in vvvv features that conceptually is really simple and i think it would be usefull in many patching scenarios.

the problem comes if you want to concatenate multiple spreads into one(like the Cons (Spreads)node does) having the possibility to choose dynamically the input spreads (having them also dislocated in different modules).

i’m using network to avoid this vvvv limit:
you just send data via UDP from different modules.
you send them to local host, same port.
UDP receiver must be set to spread.
in this way you concatenate the incoming data from the local network in a unique spread.

the issue of this approach:

  • you introduce delays by using network
  • you are not sure that data are combined in the same frame (right?).
  • you can’t really decide the order in wich the input spreads are concatened.

MY SUGGESTION:
a couple of new nodes! :)

Actually they could be similar to S (Spreads) and R (Spreads) nodes:

there would be a ConsS node with these inputs:

  • input (where you put data to be concatenated)
  • priority (integer that gives the priority for concatenation order, like it works on Group (EX9 Priority)node)
  • send string (the target where to send)(like in S (Spreads) node)

then there could be a ConsR node with the input:

  • receive string
    and the output:
  • Output
  • bin size (eventually)

using these two nodes combined you could concatenate different input spreads choosing also the order of the concatenation using the priority pins.
Priority works exactly like in groups, lower to higher…

What do you think about this? :)
I found it’s really a nice example of a more general concept regarding vvvv itself:
the conncetions between nodes are just one way to see the actual structure of the data flow. It offers the nice possibility to SEE the graphical rappresentation of the node chains, but it also brings to a static structure.
Would be nice to be able to create this kind of “meta structures” (meta operators) wich can’t not be entirely represented in the vvvv patch GUI, but for this reason they can expand possibilities avoiding GUI limits.
In a way you could represent these objects in different vvvv interfaces, like the Finder;
take the S-R nodes: as far as i understand they create “metaconnections”, not visualized in the patch but that can be displayed in a different graphical interpretation of the system like the Finder window.

i really think it’s an interesting topic to explore.
…and staying also on the practical side, these nodes can really make the difference in a scenario where you load dinamically different modules.

let me know what you think and if there’s something missing in my perspective.
thanks

2

there could be other input-output pins on these nodes:

ConsS ulterior input pin:

  • tag string (or maybe ID integer number?)

ConsR new output:

  • bin tag
3

+1 i missed something like this in md.vis. I’ve worked around the problem with multiple S advanced nodes and clever timing but it’s hacky and it works only if the sources send their data in different times

4

i totally agree, bigger projects tend to get messy, especially if modules are interconnected a lot. either you spin a huge web of links or you clutter the S+R-Hyperspace with tons and tons of entries.

so i thought about a way to “pack” stuff that belongs together, so it neither needs too many connections nor S-nodes, but it still relies on these mechanisms.

it boiled down to three plugins for creation and maintainence of a project-wide API of different “packs” (for example a bunch of named, transformed, colored and visible projectors, all going through the very same link). So there is not only the join and the split-part of the pack, but also a way to change these nodes remotely.

there are more things in the code, for example if a remote change affects a node’s connectivity, it stalls with an exception till you fix the node in question by hand.

this code has shown some issues with bigger projects unfortunately. but maybe it can illustrate a way to go about these problems to create the event system you are looking for, without having to introduce new hidden ways to exchange data.

DynamicPinsSpreadsMConfig.zip (56.2 kB)

5

looks clever

6

Hi, I havent had a chance to look at velcromes approach, but I totally agree with dottores proposal, except for one point: the priority pin on the sender.

Having the priority on the sender would mean that the sender knows of all the other senders to tell if it is more or less important. So prioritorization has to happen on the receiver, either with some sorting function on the node or some re-sorting/sifting in a separate node.

I think ID based S+R nodes with implicit cons are more than neccessary. Right now I am using OSC for this, and I think Elliott provided his OSC S+R Nodes based on channels and addresses with exactly this problem in mind.

But a more integrated solution would be great. Also in dealing with changing spreadcounts You always need the pairing of ID + Value. I made the dictionary plugin to deal with storage of ID based slices - but it would be great to have spreads based on IDs somehow throughout v4.