Forum

Framedelay plug to behave like native one

vvvv beta question
#1

hi ,

i was trying to add some framedelaying into some plugs and i was trying this , see patch to see better .

Native and plug seem to behave the same apart from that the native can be connected to itself and plug one can not . what am i missing ?

also how can i make it delay more than one frame ?

public void Evaluate(int SpreadMax)
		{
			
	    FOutput.SliceCount = SpreadMax;
			
            Array.Resize(ref FMyLastState, SpreadMax);
			
			for (int i = 0; i < SpreadMax; i++)
			  {  	
			  	FOutput[i](i) = FMyLastState[i](i);
			  	FMyLastState[i](i) = FInput[i](i); 
			  	
//Thread.Sleep(1); I tried with Threading also 
//but i presume this only make a 1 millisecond pause in the app not too sure .
			  	
			  } 
			
		}

FrameDelay.zip (9.7 kB)

#2

you cannot do a framedelay as s plugin right now. if you need a custom functionality you have to use a combination of your code and the native node.

for delaying things more than one frame you would need a Queue-like buffer data structure, where you put in a value at the end and put out the first value and delete it.

#3

ok good to know thank you

#4

Is it still impossible to write a custom FrameDelay node? Stuck at usual feedback task in DX11, programmed custom FrameDelay with vux help, but it doesn’t allow me to push data upstream. Can it be solved somehow?

#5

+1! let us code framedelay to our custom datatypes!

#6

should be possible already with two nodes, no?
like vuxens s and r

#7

Yes, i think it can be solution. But i think it should be supported in plugin interfaces.

#8

There is a “framedelayish” node inside @velcrome))'s ((contribution:message contribution. Uses some kind of trickery I don’t remember exactly.

#9

yeah, its exactly like woei said- it can be done with two nodes: the Framer and the Delayer. The Delayer is connected upstream from the Framer, the Framer gets the data and pushes it into an unconnected input pin of the Delayer.

{img src = "sites/default/files/imagecache/large/screenshot1366580830.png" title = “f+d”}

that way we can even use this combination for patched feedback loops, because it _safely_circumvents the sdk’s restrictions.

I coded my plugins generically (much like the Cons or the Buffer nodes in the sdk), so you can implement them for your own datatype with 3 lines of code.

#10

Yeah, i’m currently using it, but in some cases texture is buggy or not all tFX is working. Maybe this hack broke something in flow pipeline.

Update:
Solved this by S and R nodes. Framedelay by message node is a little bit buggy for dx11 textures, because of the Update cycle and device context.

#11

hey alg,

i considered a lot of cases to make sure it would not break vvvv node graph. however, if the dx11 graph has some underlying magic to it, i would be interested in your patch to see what’s breaking it.

would you be so kind and send me the patch? marko ät intolight dot de

#12

Thanks for the peek. I see what you tried to do. I really like the possibilities.

Unfortunately this will not work with my basic generic nodes, nor with embedding DX11-Textures to Messages. There is simply too much difference in the handling of standard vvvv types and graphic resources.

But I’m sure you could adapt your S and R code to your own Frame and Delayer to make a FrameDelay module and hence the data flow safer.

#13

Yep, i agree. But i planned to clone texture in another node and just send the link via Message - all is worked fine, except some bugs with tFX. Currently i still expecting some bugs with tFX, even with direct texture processing, so maybe this was a generic bug.

#14

at the moment tfx behaves strangely after recompiling re-initializing re-whatevering during normal scenario.
btw i’m not that good in coding DX11 resources yet but i desperately need some framedelaying story can you send me that S+R workaround too ( _@mcro.de )? or upload it here?

#15

Yep, this is my working folder — https://www.dropbox.com/sh/osw6dn83y1f8rfg/PFmtuRzGHH. I will add it to current DX11 repo on GitHub later.

#16

all hail alg! :D

© vvvv group