For those who aren’t familiar with frameserving, its when one program (vvvv in this case) outputs a pointer file, like an empty .avi, that another media program can import and use as if it were an already rendered video. Is this possible to do in vvvv?
dont know about that but you can check the shared memory nodes
would this be a way to use v4 as a plugin in aftereffects?
Yes, i first discovered this as a premiere plugin that allowed me to render the timeline directly into my external mpeg encoder without an intermediate render. I could also play my timeline in an external media player/editor using this method as well, its very adaptable.
Well it looks like there’s no way to do this in vvvv and no one here seems to care about being able to use their patch as a source in other programs such as video mixers or fx passthrough’s. I presented the idea to the dev’s but got no response, so i guess they don’t care either.
I did find one solution called syphon, but its only for jitter and only on mac, so if anyone wants to go beyond the 5 minute “hey look at this weird patch” performance that people only can stand to watch a minute of, then that’s it.
it’s horses for courses poof.
vvvv is among the strongest tools for it’s intended tasks, which all lie in real time rendering interacting with all sorts of other software and hardware.
That vvvv has progressed to a point where people normally using tools like afterfx (like you poof) want to use vvvv is bloody awesome and shows how cool a tool vvvv is.
For people wanting to use an output from vvvv in another tool like afterfx light seems to be at the end of the tunnel: md.vis
so far just between instances of vvvv, but one day…
I will just say that if you put the same amount of work into a patch as you do to a video made in AFX you can usually stand watching the patch mushc longer. I do not share your experience of vvvv patches. Creating video in AFX lasting 5 mins takes a lot of effort if it should not be boring, the same goes of course for vvvv… and you can make the vvvv patch so it never repeats and thus giving you new 5 mins every time you open it. every time yoiu run the video, it will be the same.
I love vvvv and people often ask if it can communicate with this or that software, and usually it can, but quite often vvvv is a strong replacement for the software it needs to communicate with.
just my 0.02€ on the subject
Hi poof, this is valuable idea but it needs hard coding and time…
This shout leads to a video made by a vvvv user.
This video, as stated by author, is done with vvvv and AFX.
This means that’s possible.
This does not mean it’s going to be easy.
This means that some efforts are needed to find workarounds.
After all, AFX it’s non real-time renderer; so, what’s the meaning of realtime rendering stuff passed, in a live show, to a non real-time renderer?
Just accept, please, that a few skills are required to use vvvv and to get the best out of it.
Moreover I don’t see here anyone saying “vvvv is the definitive software, after it, there’s the big nothing”. I see enthusiastic people of what the software can do.
… but poof is pointing a good question… ;-)
frameserving structure IS interresting.
ohhhhh !!! :-°
Actually I think this is possible, you would need to timeliner your animation in v4, have an afx plugin that sent the timecode from afx to v4, v4 would render a frame to disk and the afx plugin could the load that, or infact you could shared memory to access it, it requires a afx plugin being written however.
@poof, sory for late answer. assuming this is interesting to others as well i don’t answer your private mail, but rather answer here.
historically frameserving has not been too interesting to us since vvvv is a realtime environment and sharing frames with non-realtime software didn’t seem to have so many applications. not saying it didn’t make sense at all but you know…we have to focus… also since the introduction of the possibility to load avisynth scripts with FileStream (DShow9) i thought some old-school cpu-based frameserving between applications could already be possible. one way at least (as input to vvvv that is).
also the SharedMem (EX9.Texture) allows for reading textures serverd from other applications. still cpu-based and thus not too interesting for realtime purposes but definitely usefull for scenarios where the image size is not too big.
indeed something like syphon is needed for realtime frameserving as this is sharing textures directly on the GPU without any significant performance penalties. while i am not sure how interesting such a system would be to interact with a non-realtime software it should certainly be possible to write an afterfx plugin to consume from or broadcast to syphon as well.
now syphon is macosx/opengl stuff and vvvvs engine is based on directx, so syphon won’t directly help and i am not aware of any similar framework for directx (anyone into porting syphon?). still it is possible as our proof of concept shows that @microdee)) successfully made use of as user:sunep already pointed out above: ((blog:md.vis
note that this does not only allow sharing of textures between instances of vvvv but potentially any other direct3d supporting application on windows >= vista. also for now it can be used as a workaround of getting texture-data as input to plugins.
still this is not in the main alpha branch as it needs some more tweaking/testing/time.
bottomline: there are options for frameserving to/from vvvv. until someone comes up with a standard like syphon for directx/windows write your own plugins to communicate with the application of your choice.
+1 for syphon :)
I didnt mean to suggest that the focus be on AE or non-realtime programs necessarily, my interest, and i believe the real potential here behind frameserving, lies with using v4 as a source into a realtime video mixing program like resolume. The basis of video mixing is that no one video source is interesting enough to constitute a performance, and the same is true for any visual medium, a shot does not make a scene, a scene does not make an act, and an act does not make a show. V4 is no exception and no matter how talented a programmer may be what you’re left with is one scene for the entirety of a song. Our only current alternative is to rig up some simple switches between patches and attempt a ghetto mixer, or to use the mds.vis that was suggested which is essentially the same thing, but such a cumbersome approach to this craft does not facilitate creativity or risk taking. Until we are able to use our patches in a professional mixing program we will always be limited by the static nature of any one visual source.
I hope you’re aware that v4 is way, way behind jitter. While you are focusing on some other aspect of v4 that apparently is deserving of your attention, you are neglecting the fact that v4 cannot survive within a vaccuum. Creating something like mds.vis to get it to interface with itself is a start but is no answer to opening v4 up to the rest of the ecosystem of video programs. If v4 is to be a contender against jitter, it must match its strongest featuresets and not only open itself up to other programs, but make full use of user’s hardware, and do so without resorting to telling its users to ‘write their own plugins’.
poof, you would better write your own software instead of non gentle and angerfull criticisms. I think this would be the best solution. take a book about C sharp or C++ and go on it.
VVVV is far more open than jitter, and i think you didn t understand the generosity behind it.
Who is jitter? ;)
VVVV is far more than a source of colored pixels.
Wow! Every time I read @poof))'s posts I think I have not understood anything about vvvv (which is probably true, compared to experienced vvvv users), ((forum:is-jitter-more-stable#comment-75818
Anyways, after first impact of these incredible reality slaps @poof generously provides, I step back, and recall all the time I spend and spent searching vvvvorum, reading documentation (and why not, translating it), searching for stuff on msdn… And I get self-confident again, yes!
I’ve found many answers here, found kind community and clever software.
Also I don’t understand what’s wrong with implementing plugins and so on. Yes, personally I wouldn’t be able to manage this, but this would be my problem, not vvvv’s. So what’s the point? Someone’s not able to get a single good thing out of vvvv? Oh, mummy, vvvv won’t let me play! Tell it something!
Once a guy told me: I bought this computer. Yeah! I started it. But there’s a thing I don’t understand. I sit in front of it, and it doesn’t do nothing! No matter how many time I wait! Nothing happens! All this money simply wasted!
-And that was strange, since screensaver should be on by default.
One more: once a girl, macbook equipped, phoned me asking for help to access ftp with safari. So, after googling, I found apple key + K combo (I’m no apple user, so I can’t say this is right or not for real) and told her to do this. Ten seconds silence, and then: here there’s no apple key!
So, I really don’t know if it’s vvvv to be blamed for something or if someone should be blamed. Probably the lack of ready-to-use stuff is disappointing. But I mean… there’s a lot of stuff that can be downloaded here, which can be implemented to own needs. Ah, yes. But then one should also have to understand how things work. Mh. Probably this is the biggest obstacle, for me too.
But I found that the more I do, the more I understand; the more I understand, the more I do (now devvvvs can you please help me writing a plugin for me that lets me spread this circular behavior at its maximum, non-depending on hardware capabilities?). Hopefully one day I’ll have the guts to propose a real vvvv project to someone.
And anyways… has vvvv ever to be considered against jitter?
This is something I completely lost along the road. I think that in general would be healthy having some competitiveness, but never considered the option of being against each other (mostly 'cos I hope this is not a surviving matter).
It’s All A Matter Of Point of View
48K seem to be happy with PPhttps://vvvv.org/sites/default/files/imagecache/large/images/P_P.JPG