I’ve seen several projects making use of both vvvv and Processing at the same time.
I’ve used Processing before and switched to vvvv because of Processing’s (still) poor capacity of dealing with video clips and some memory issues related to handling textures in memory. And now I’m a happy vvvv user, although sometimes, being used to Java and C#, my brain still fights with the vvvv programming metaphors and logic. But I love its interactivity and interface smoothness which are lacking in Processing.
So, my question is: what is it that Processing does and vvvv cannot do?
There must be something, otherwise all these projects wouldn’t be making use of both at the same time.
I think in this example they just used both - vvvv and processing - to demonstrate the capabilities of their own software: http://nuigroup.com/touchlib/
Theses tow piece of software wasn’t designed into the same context. Not fot the same needs too. Processing was created by teachers to help ppl learning programming with a visual result.
Actually i’m not sure there’s something processing can do vvvv can’t (must be and it’s an interesting subject). Maybe web applet but i’ve seen an html renderer (not sure it can’t export vvvv renderer into a web page though). But u underlined the reasons why i’ve switched from processing to vvvv too. After that i tried to go back with processing but isn’t that easy.
Sound is one of the weakes point of VVVV but it isn’t much better into processing (as far as i’ve tryed). If u really wants to deal with sound i think it’s better to go into PD or Max/msp (or csound, sc and all the like).
considering 3d performance and interaction vvvv is the way to go, but if you have to deal with numerical algorithms or datastructures then processing is better, because it has all possibilities java has to offer…
I think the power of Processing lies mainly in its abstraction from ‘pure’ Java. It’s very easy to whip up small ‘sketches’ and loops with graphical results using only a reduced set of commands that cut out most of the schlepp (drag) you’d have to deal with building the same in core Java.
It reaches its limit pretty fast with bigger projects, as soon as you feel the need to tweak those very routines that it takes of your back at first, and partly due to its interface. Luckily, you can embed the abstraction layer of Processing itself into a Java project, and with powerful development platforms like Eclipse, nothing can stop you from using both the Processing semantics and all the Java-libraries you can find (and their numbers are legend) in an interface suited for larger scales.
That’s not the idea of quick prototyping, though ;)
Now, VVVV also cuts the schlepp, but it’s (personal opinion following) more enticing (/) since it handles DirectX and does so with amazing performance; and creating a render context or an event handler for user input with a double-click definitely fits my idea of quick prototyping. But what’s most striking (from my point of view) about VVVV is the way it deals with data, the way it is designed to monitor, direct and shape its flow (that remains invisible in most other programming environments I know): the treatment of numbers is far less abstract, I’d even say that it gains a sort of Gestalt, which is a lot more intuitive to work with than formulas.
You can’t crack VVVV up as far as Processing, but I figure if someone wants to write their own 3d-engine, they are far off the prototyping-territory anyway. You could still go wild in HLSL ;)
first i think there are some things like coding objectoriented structures that are not possible with vvvv, as far as i know.
at least to me it’s a lot easier to make lots of objects with complex interactions and subclasses etc, than messing with tons of subpatches.
processing can do some things that are essential for printdesign you cannot do with vvvv.
for example if you have a generated mesh that you want to output as good as possible. you can export it with the gridwriter from ampop, or export the meshdata.
with processing you can also export the meshdata and the hires-images. but you can also export it to pdf as clean vectordata.
another big issue is the use of fonts. if you’re into typography then vvvv is a bad choice i think. elektromeier patched some great stuff recently, but processing is still better for handling fonts.
at first sight processing seems to be slow. but if you use opengl and hardware accleration you can run stuff that is pretty impressive.
applications. i can export a processing scetch as a standalone-application for pc and mac, that can generate stuff and export is as hires-image, vectors, movie and even as 3d-model. so i can send my work to some other designers who can then use it for print, motiongraphics and livevisuals.
i recently did a collaboration with a norwegian designstudio doing a festival. i sent them my scetch as an application. they are designers who cannot code. the were able to run it, and get everything the wanted from that application. it rendered images huge enough for printing big posters, it rendered movies that are used for a tv-spot, and the scetch runs in realtime at the festival on a huge screen. i think vvvv can’t do that.
so lots of things are better in p5 and other are better in vvvv, already discussed issues like 3d, video, dataflow etc…
but for printdesign processing is the way to go.
and knowing that i’m using an opensource crossplatform tool is a good thing to me. :)
i use both tools and it’s definitely worth learning p5 and vvvv.
most of the points in this thread are well taken.
but of course everybody who is inclined to do so can create high-resolution print graphic pdfs by adding up large strings. pdf is quite horrible to parse, but quite easy to create…
