JJJJ, Run VVVV on JavaScript

vvvv beta feature
1

Project JJJJ

What started of as an experiment, where I wanted to mimic some of VVVV object structure in JavaScript, has grown a bit out of hand. The main thing I wanted for my site was the execution structure (Node after Node in VVVV, Object after Object in JS), so I could do more with dynamic animations in my site, as well as others I’m working on.

However after building a few Objects, I realized I needed a more stable base, which I called “Patch”. This Patch Object would contain an empty function Execute(), and some base variables. This way I could “prototype” this Object in my actual Object so i can call Execute() on every Patch Object. After some testing with this base, and a simple chain structure to trigger the respective Objects, I added an output handles that would send some data to the following Object in the chain.

This is where I realized I had come closer to what VVVV does that I had at first anticipated. This made me somewhat enthusiastic and I throw my original plan (building my own site :P) overboard, and went on with experimenting on the structure I now had.

…
…
weeks coding (aside form the shows/parties of course)
…
…

I now had a solid base, with some basic Objects with functions similar to VVVV Nodes. Now I wanted to add a file reader that could read V4P files, reconstruct there functionality as an Object chain. At this point I had already seen the potential this project has, and renamed it from “My Site” to “JJJJ”. Now all there was left was creating a GUI where the Objects would be represented as Nodes, and the base for JJJJ was done.

I’m currently writing the modules (like: Value, String, GDI, EX9, …) and am far from done -_- , but there is progress.

But I should stop writing, it’s better to show it ;)

http://teshvisuals.nl/jjjj/?patch=true

2

Uhm, I don’t mean to spoil the fun you’re having, but you most certainly have seen this, have you?
http://www.vvvvjs.com/

3

Lol, no I hadn’t.

But like the story says, it was only a tryout anyway :P, and still is for my part (Diggin deeper and deeper in the possibilities of js)

4

so, you’re lucky that vvvvjs is opensource and it’s possible to contribute and make it better together.

5

unbelievable - yea we can absolutely need your contributions on the vvvvjs project. but its realy funny that you obviously worked in some kind of parallel world for so long :D

I am proud to be mod in the vvvvjs forum - although it can need some more discussions

http://vvvvjs.com/forum/list.php?3

6

I’ve been looking further into it, and already saw some major differences, like the replacement of the GDI renderer with the VVVVjs renderer, which has different nodes as well. This would mean that if I’d load a patch which uses a GDI renderer, it would break, or be converted (thus change).

Looking at it it seems to work based on the same structure, like I do, but I see a lot of differences.

If you would take my test patch for instance, it would already break at the whole GDI rendered part. Other things that bother me are the missing pins on nodes like the EX9 renderer, like depthbuffer.
The renderer also seems to resize itself when you change the BackBuffer Width or Height, which is behavior that technically isn’t even related to what BackBuffer means (difference between the rendered resolution and displayed resolution). Look at the text in the GDI renderer in the patch, and the gdi renderer rendering the front page. They have the same backbuffer, so that the pixel-sized text gets rendered at the correct size in both renderers. I changed the BackBuffer Width of the GDI renderer in the subpatch to 500 instead of 1920. As you can see there, the size of the renderer didn’t change, but the text is stretched to fit the 500 pixels wide result in the smaller or bigger renderbox.

It also seems to miss the tricky nodes like audio, collida (althou i already did a parser for one of the in VVVV supported 3D files, collida or dx, so that’s just a little modification away), and things they don’t even call out like midi-in-out

My biggest con: Missing GDI Renderer + Nodes.

7

I think the biggest difference in the 2 is that vvvvjs seems to focus on use as embedded element in websites, and my project is more focused on extending the toolkit of the Artists using VVVV for there shows. Eventho it started of as a tryout for my site, I’m thinking more in the direction of being able to work on your shows and such while away from your comp, using a tablet and means like that.

8

okey but did you have a look on the source?

maybe you can merge your stuff in a way. or do you think it is completely unable to adapt? I cant tell I couldt see your code base. For example if you say you made progress in geometry file nodes and midi - that would be realy something usefull.

And yea it just loosly leans on the design principle… it is not downward copatible most of the time. But it depends on the specific node programmer, there are different ones involved, what pins they actually implement or not.

but it also does not need to everything 100% the same - it is for the web or mobile or open source arm devices.

and seriously… as much as i am impressed by your solo progress with that idea… who in the world uses gdi renderer nowadays and especially for shows?

if you are on native vvvv than dx11 is whats fluffing in 2014 and the vvvvjs topic is something that has a future for the reason that it fills some crossplatform gaps of vvvv - for example i am working on crossplatform copilers that can bring your vvvvjs app directely in the android or ios store.
or it can be used on such devices to support an installationa vvvv dev might do for a client with mobile touch devices. rapid mobile prototyping is something a vvvv based company will face more and more so this is a way for example.

Anyway I would be realy interested in your code :)

9

also since vvvvjs has its own node editor it doesn’t have to be compatible with the original vvvv anymore

10

When I started implementing the v4p loader, I did have both-way compatibility in mind. I also pasted a topic on it on your forum. I’m working on it, so the user-readable code is corrupted at the moment. If that part is fixed I’ll rar it and send you a download link. My version also offers decent console access.

Some console inputs:

access node-object by id: (76 = id of first patch within root, just like vvvv)

root.nodes[76](76).patch.nodes[id](id).patch ↵

and the nodes in the subpatch: (137 = id of the subpatch)

root.nodes[76](76).patch.nodes[137](137).patch.nodes[id](id).patch ↵

for more details on a certain node: (Replace “Renderer (GDI)” with the nodes name; note “Add”, “Subtract”, a.o. instead of “+”, “-”)

var temp = new jjjj.NonPatchNodes["Renderer (GDI)"]() ↵
temp ↵

some items, like input and output are found under proto, since each object inherits the Patch() object (thats also why you need to add .patch at after selecting a node from an array)