in a discussion with digitalwannabe we agreed that it would be nice to have a node/plugin to route spreaded data, very much akin to a video matrix switcher: take spreads of data at X inputs, use an index spread to redistribute these data to Y outputs. think of it as a pimped stallone
see attached file for a patch.
when i look at this patch i feel that by programming this into a node or plugin there would be considerable, easily realisable potential for improvement (variable number of inputs/outputs, speed/efficiency). sadly, we lack skills in c# to do it.
so i propose:
Inputs: data input pins, Number of Inputs, Number of Outputs, Index Spread
Outputs: data output pins
anybody wanna help?
matrix_vorum_v2.v4p (38.5 kB)
i can understand your desire for something like that, but i’m afraid that it is not necessary at all. i think that you will agree if you know the reason: vvvv has a very different approach to the problems that create the need for something like a matrix switcher in the first place. i urge you to carefully read and follow these tutorials on spreads, which (i believe) will solve all of your problems of that kind:
Tutorial Spreads, Tutorial Spreads 2 and Another Page about Spreads
it is by no means a ‘new’ concept, but the implementation comes close to genius. fanboy out ;)
dear fanboy diki, ;-)
either i didn’t elaborate enough, or you didn’t look at the patch, or you know something special about spreads i have missed during my projects up until now, but i do not see how the basic tutorials you linked to somehow can be used to provide the functionality digitalwannabe seeks, or how this would approached in a smarter way.
he wants to have a couple of “data generators” as inputs, e.g. an lfo, a random number generator, linearspreads, circularspreads, etc., to use them as a set of “general universal inputs” for his patch for an installation.
these all have different spreadcounts and should be easily routable to the outputs, e.g. to easily change a group of boxes from a circular to a bezier spread to a random distribution, or whatnot.
i do not see why this is not necessary at all, and i’d really much like to see your approach/better solution. i’m ready to be enlightened :-) how would you do it?
(a heap of Switch nodes maybe would also do something similar, but is also not very elegant - aka spiderweb. so maybe it should be called Switch (Value Matrix)…)
thanks bilderbuchi for posting this here and also for explaining my point…
@diki: if you look at the patch you can see that an e.g. 48x12 switcher matrix (what i need now) is quite circumstantial to achieve, although it’s a rather simple task.
in our opinion a node like this could be very useful in lots of situations, not only the one i’m in, as it’s a very general thing to do. i’d also happily see a patch which accomplishes my task in an easier way; unfortunately i can’t find any answers to it in the spreads tutorials you’ve linked to, or i’m overseeing them…
hm. maybe it would make sense to put it into a new node. though i didn’t need that up to now.
for now i would suggest to use 12 switch (input) nodes. one for each output. and this one stallone node you have already. this results in fewer nodes and would probably be faster than your current approach.
(if you now want to get this more general i could imagine that it is somehow possible to modify the patch via setpatch, depending on Number of Inputs and Number of Outputs, but i agree that could turn out to be a little complicated.)
so at the end this is another serious guy, like stallone. but who really wants to code a node named schwarzenegger? …
i also thought about get/setpatch but i am out of my depth there and it felt a bit like cannons to sparrows using setpatch to get functionality which is (i think) rather easily realised in code in a node…
maybe, since it’s a Matrix switcher, “Neo” would be a better name for a serious node? ;-) although i think for clarity’s sake it would maybe be better to stick with telling names, a la Switch (Input Matrix) or similar. Neo sounds tough, though…
or use “Ahnold” instead of Schwarzenegger :D
another suggestion, if i may: wouldn’t it be wonderful to make Stallone’s Spread Count pin spreadable? this way you could e.g. create a spread of (random, gaussian, whatever) numbers with one node, and distribute as you wish around in your patch, one for the number of objects, 3 for translations, 3 for rotations, one for texture selection, etc…
hahaha, neo is a good one there :D
@gregsn: thanks for the tip; i did go for 12 switchers in the beginning, but as this meant connecting all of my 48 inputs 12 times each i’ve started looking for something less laborious…however, if it makes my patch faster i’ll happily start connecting ;)
and no, i didn’t come across another situation where a node like this would have been needed, although i’m not super-experienced in vvvv and didn’t do that much yet; but thinking of it my task is, as mentioned before, something quite general to achieve, i think…a spreadable stallone’s spread count however would be a nice solution to this too…
thanks to you guys
by the way and on the jump:
*using S (Value) and R (Value)
*one module as input
*as many modules as outlets as you want
Switch (Value Matrix12 Input) help.zip (4.9 kB)
(very nice indeed. but kalle, there is no need to hide your beautyful subpatches on the far right side of your gigantic screen. the international patching standards committee frowns on that ;)
bilderbuchi & digitalwannabe, i see what you are getting at now. i agree that this would probably be solved best in a plugin/node, so you can add/remove in/outputs without SetPatch. if Stallone had a spreadable spreads pin though, it would definitely be the way to go; thanks for reminding us of this one :)
but kalle, there is no need to hide your beautyful subpatches on the far right side of your gigantic screen. the international patching standards committee frowns on that ;)
well, i’m not into big screens in normal case.
sorry for this.
in other cases i was complaining about this…
simple plugin done.
tried to make the in/out pincount not as a valueconfig which is only visible/changable by inspector/setpatch. the disadvantage is, that the pincount does not get saved that way, so i switched back to the ‘old’ inspector way
RouterValue.dll (20.5 kB)
wow guys, what a community here. thanks to kalle for this great patch, made me understand bin sizes :D i also like the possibility to “stack” inputs on top of each other for certain outputs, although i’m not in the need for that now…
aaand of course, woei 4ever :D thanks a lot mate, works great and saves lots of patching time!
thank you! :-) i hope i can try it soon…
actually, by clever handling of the “route” value spreads, woei’s plugin can be used as an alternative to a stallone with spreadable spreads pin, can’t it?