Forum

A Dark Side of VVVV's question

vvvv beta question
#1

Hi !
we had a tchat yesterday with Tekcor, everyoneishappy and UrbanKind about a CP project.

I have a question for devvvs or heavy patchers:

i would like to create a patch loader VJ oriented wich:

  • auto detect if the patch that is loaded has a renderer DX9
  • if yes, create temporarely a connexion to it in the main patch and connect to it

my goal is to enable simple loading of patches, without having to structure them on same I/O inlets and outlets ( svvvitcher is nice, but too much complex)

in clear and simple words:
a user create separetly from the structure a patch
if he wants to load it in a main structure, it would be possible , and on the fly

( about the question of inputs for manipulating, there would be S + R technique based approach).

So, how to achieve this:

Patch ? or PlugIn ? Wich the best approach ?

yours

#2

you could just take a look to IRIS. - i think it does exactly what you´re looking for - for now you have to create an specialized plugin to handle the i/o´s your patch. but for the next version you will get rid of it because of the amazingly pinserver. Also the library will be based on the Texture-fx naming convention so that you could use any patch/fx following that convention…

#3

sounds good!
ps: what about a todomap integration for midi controllers
since it’s not possible (in current version) to save the Signals mapping per patch?

#4

surely you just want each content patch to output a texture, which then feeds into the geometry correction / whatever end of the main patch?

And why are you going to a vj type system? are people going to ‘perform’ their content?

#5

hi guest/circuitb/mrBoni !

vj or whatelse, idea is to create a free simple canvas to load unload patches.
for me i m thinking texturing of course ;-)

well with IO in S/R not sure to be in need of a pin server.
just a global framework.

one point could be to create a triple/quadruple user interface framework, with feedback:
thinking in levels, for examples:

mouse levels inputs /
midi inputs /
art-net inputs /
OSC- inputs /

but i will have a closer look to iris, thxs for this hudge contrib

#6

hi, ok i m coming back to this topic.

thanks for for iris.

All goal pointed in iris are really same goals i m trying to find, and i was very happy to read the iris wiki. really similar preoccupations.
and i completely approve and appreciate peroccuations behind it.

helas, despite this high similarity in preoccupations and statements i feel iris framework not in my feeling.

this for 2 points:
-GUI ergonomy
-General canevas designing
and especially:
-input output restrictiv frameworks

I learned a lot looking to nodes and this impressiv work, thxs again to iris team.

Now still this question:

how can i create an auto connexion when loading a patch to its Renderer output ? wich is the best way ?

#7

he karis,

thx for the flowers. for future iris versions we will break up the restricted A/B structure to another more flexible approach.
whats your points about the gui and i/o?
if you want to create dynamic connections you have to build your own parser which automatically set & delete connections if you are loading or changing a patch. so for a start you can do everything of course via setPatch. therfore you have to parse ( xpath) for nodeIds and IoBoxes via descriptive names… and you have to make sure that the io-box you want to connect to your renderer is type-safe(e.g.layer output) but on the other hand vvvv will not make any unsafe connections so maybe you can just “ignore” that…
you could also do it the “iris” way using a predefined structure (like texture-fx) in this case you could just change the patch itself, as long as the new one has the same io-boxes the connections will be preserved…

#8

ah yeah milo, you are right, parsing the wml file, how stupid am i ! thousand of flowers to you ;-)

about iris:
commands on the media are disturbing and somehow need concentration to identify command possibilities
the main general window view is not clear: how many group, how many final renderers, why 6 windows. i didn t feel it explicit. the approach is very personnal, and despite the wiki, i feel there is something else to do, more GUI sided than system sided

about io framework in subpatches:
“the new one has the same io-boxes the connections will be preserved”, its all about that:
load and play without risking to break because previous version, new version or wrong canvas of input outputs ( despite your subpatch explanation is a real pleasure to read on wiki). escaping coding framework would be nice.

yours , milo
christoph

© vvvv group