Tebjan Halm wrote:
to be honest, i dont read the whole mail ... *ashamed*
tststs
so if i want to use shaders, i have to compile gem together with the shader code ? there is no object, that can load shaders ?
there are objects that load shaders (from files) you just have to compile Gem from CVS to get these objects.
... and which shader language is supported ind gem ?
currently just ARB-shaders (and in theory NVSL) so no Cg and no GLSL; i am currently thinking about how GLSL would be best integrated (which pd-object set would be nice); once i have figured that out, it should be done pretty quick.
mfg.asd.r IOhannes
greets
On Oct 18, 2005, at 7:27 AM, IOhannes m zmoelnig wrote:
Tebjan Halm wrote:
... and which shader language is supported ind gem ?
currently just ARB-shaders (and in theory NVSL) so no Cg and no GLSL; i am currently thinking about how GLSL would be best integrated (which pd-object set would be nice); once i have figured that out, it should be done pretty quick.
...as ya might've guessed, I'm already into a coupla drafts of a glsl- based [shader_program]...the first try was simply to mimic what I did for the ARB programs, but then I found that glsl is different in that you compile programs to objects, then link those objects into a shader, which then can be used when needed...another twist is that while one does need to specifiy whether the program is vertex or fragment when creating a shader object, you can actually just link together vertex and fragment shader objects for the final shader: discovered this looking at some of the latest nvidia sample code (specifically gpu_videoeffects)...
...so, I think this means we should just have one [shader_program] that can accept one or two names as arguments (vertex shader followed by fragment?), but we would then need some mechanism to determine which one is the vertex or fragment shader...so, I've been just going ahead with making it a message based object, such that you send a [vertex nameOfVertexShader< and/or [fragment nameOfFragShader< to the [shader_program]...then the shader_program will try to link together whatever it has, report what happens, and go on from there...
...how's this sound?
jamie
james tittle wrote:
...so, I think this means we should just have one [shader_program] that can accept one or two names as arguments (vertex shader followed by fragment?), but we would then need some mechanism to determine which one is the vertex or fragment shader...so, I've been just going ahead with making it a message based object, such that you send a [vertex nameOfVertexShader< and/or [fragment nameOfFragShader< to the [shader_program]...then the shader_program will try to link together whatever it has, report what happens, and go on from there...
but does this mean that we can only have 1 fragment-object and 1 vertex-object, while GLSL would support multiples of both (the only restriction ist that there must be one and only one main() routing in both fragment and vertex sets)
so i was thinking of having 3 objects: vertex- and fragment-shader loaders ("compilers") and a linker-object.
does this make the patches unnaturally bloated ?
it would look like
| [GLSL_vertex vertex_main.glsl] | [GLSL_vertex vertex_sub1.glsl] | [GLSL_fragment fragment_main.glsl] | [GLSL] |
(the object-names just came to my mind while typing, so i don't care about them)
and both [GLSL_vertex] and [GLSL_fragment] would have one additional inlet/outlet so you could share shader-objects.
otoh, i am not sure what's the fuzz about all those different compiled shader-objects. one thing is that you can keep your (shading) code cleaner and re-use it (as a programmer i mean); so it wouldn't be _that_ bad, if you had to copy everything to one file before loading it into [shader_program]. the more serious question is, whether you can use more distinct complex shaders, if they share modules(==shader objects). so if 2 shaders share 50% of the code and loading both totally separately would exceed the maximum number of instructions, you might be able to load both with the share objects (only 75% (compared to the other option) has to be loaded) is this assumption correct ? should it bother us ?
mf.adsr. IOhannes
...how's this sound?
jamie
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On Oct 18, 2005, at 12:48 PM, IOhannes m zmoelnig wrote:
james tittle wrote:
...so, I think this means we should just have one [shader_program] that can accept one or two names as arguments (vertex shader followed by fragment?), but we would then need some mechanism to determine which one is the vertex or fragment shader...so, I've been just going ahead with making it a message based object, such that you send a [vertex nameOfVertexShader< and/or [fragment nameOfFragShader< to the [shader_program]...then the shader_program will try to link together whatever it has, report what happens, and go on from there...
but does this mean that we can only have 1 fragment-object and 1 vertex-object, while GLSL would support multiples of both (the only restriction ist that there must be one and only one main() routing in both fragment and vertex sets)
so i was thinking of having 3 objects: vertex- and fragment-shader loaders ("compilers") and a linker-object.
does this make the patches unnaturally bloated ?
it would look like
| [GLSL_vertex vertex_main.glsl] | [GLSL_vertex vertex_sub1.glsl] | [GLSL_fragment fragment_main.glsl] | [GLSL] |
(the object-names just came to my mind while typing, so i don't care about them)
and both [GLSL_vertex] and [GLSL_fragment] would have one additional inlet/outlet so you could share shader-objects.
...this sounds fine, but could also just be done with one object that can be created with multiple names, like you did with fragment_program inheriting from vertex_program: the only difference in vertex/fragment shader object creation is what is passed to glCreateShaderObject(): GL_VERTEX_SHADER or GL_FRAGMENT_SHADER...chris had actually suggest the "shader_program" name, but I kinda like putting in the GLSL/glsl_whatever to make it more obviously different from the ARB program stuff, tho pedanticly glsl is "shaders" and arb is "programs" (of course a glsl shader object becomes a glsl program object when it's linked!)...
...then I agree we should have a GLSL_link/bind/program that would be like the soon-to-be-CVSed pix_multitexture, in that it'll accept shader object ID's...the thing here is that I haven't seen examples where more than one of each shader is bound together in one program (not to say that "I've seen it all")...I have seen header files for shaders that include common lists of uniform variables, so I guess these would have to be included somewhere along the line...
otoh, i am not sure what's the fuzz about all those different compiled shader-objects. one thing is that you can keep your (shading) code cleaner and re- use it (as a programmer i mean); so it wouldn't be _that_ bad, if you had to copy everything to one file before loading it into [shader_program]. the more serious question is, whether you can use more distinct complex shaders, if they share modules(==shader objects). so if 2 shaders share 50% of the code and loading both totally separately would exceed the maximum number of instructions, you might be able to load both with the share objects (only 75% (compared to the other option) has to be loaded) is this assumption correct ? should it bother us ?
...yeh, I think it's good to stop and try to get it correct the first time, which is why I didn't just do a similar set of object like the ARB stuff...
...one thing that I REALLY want to add to this (and possibly the ARB program objects) is a way to edit the programs without using an external editor, and this'll be pretty easy to do with the tcl text widget, I'd imagine...then we have a really cool system for playing with GPU programming!
jamie
ps: do your current gl drivers include support for pixel buffer objects and framebuffer objects? If so, I had a crazy idea for multiple_windows where we could just render things to framebuffer objects and then use those for our different windows...
james tittle wrote:
...this sounds fine, but could also just be done with one object that can be created with multiple names, like you did with fragment_program inheriting from vertex_program: the only difference in vertex/fragment shader object creation is what is passed to glCreateShaderObject(): GL_VERTEX_SHADER or GL_FRAGMENT_SHADER...chris had actually suggest the
yes, i just think that from a pd-patcher's side of view, it is easier if we have 2 distinct objects. (on the C++ die of things they really are the same object with a different "skin")
...then I agree we should have a GLSL_link/bind/program that would be like the soon-to-be-CVSed pix_multitexture, in that it'll accept shader object ID's...the thing here is that I haven't seen examples where more than one of each shader is bound together in one program (not to say that "I've seen it all")...I have seen header files for shaders that include common lists of uniform variables, so I guess these would have to be included somewhere along the line...
i thought the "#include" directive is not supported by GLSL. (but my brains might have gone astray) but since the linking multiple shader-objects is such a prominent feature in the documentation, it really would be a shame if we would just ignore that.
should it bother us ?
...yeh, I think it's good to stop and try to get it correct the first time, which is why I didn't just do a similar set of object like the ARB stuff...
yes, i also started to just add GLSL-support to the ARB-shader-objects and noticed that it is kind of different...
...one thing that I REALLY want to add to this (and possibly the ARB program objects) is a way to edit the programs without using an external editor, and this'll be pretty easy to do with the tcl text widget, I'd imagine...then we have a really cool system for playing with GPU programming!
well, that would be rather simple. we just add a method to give the program-string (ye, we should really try to get a string-type into pd!!), like [program "!!ARBvp1.0..."( instead of the normal [open shader.vp(
and once there is a string type in pd, pd would of course also need a string-editor; so it is not a problem directly related to Gem (but nevertheless a cool feature)
jamie
ps: do your current gl drivers include support for pixel buffer objects and framebuffer objects? If so, I had a crazy idea for multiple_windows where we could just render things to framebuffer objects and then use those for our different windows...
glewinfo gives me:
glBindFramebufferEXT: OK GL_EXT_framebuffer_object: MISSING [OK] GL_ARB_pixel_buffer_object: MISSING GL_EXT_pixel_buffer_object: OK
if have no idea what the "MISSING [OK]" means.
mfg.afd- da IOhannes
james tittle schrieb:
On Oct 18, 2005, at 12:48 PM, IOhannes m zmoelnig wrote:
james tittle wrote:
...so, I think this means we should just have one [shader_program] that can accept one or two names as arguments (vertex shader followed by fragment?), but we would then need some mechanism to determine which one is the vertex or fragment shader...so, I've been just going ahead with making it a message based object, such that you send a [vertex nameOfVertexShader< and/or [fragment nameOfFragShader< to the [shader_program]...then the shader_program will try to link together whatever it has, report what happens, and go on from there...
but does this mean that we can only have 1 fragment-object and 1 vertex-object, while GLSL would support multiples of both (the only restriction ist that there must be one and only one main() routing in both fragment and vertex sets)
so i was thinking of having 3 objects: vertex- and fragment-shader loaders ("compilers") and a linker-object.
does this make the patches unnaturally bloated ?
it would look like
| [GLSL_vertex vertex_main.glsl] | [GLSL_vertex vertex_sub1.glsl] | [GLSL_fragment fragment_main.glsl] | [GLSL] |
(the object-names just came to my mind while typing, so i don't care about them)
and both [GLSL_vertex] and [GLSL_fragment] would have one additional inlet/outlet so you could share shader-objects.
...this sounds fine, but could also just be done with one object that can be created with multiple names, like you did with fragment_program inheriting from vertex_program: the only difference in vertex/fragment shader object creation is what is passed to glCreateShaderObject(): GL_VERTEX_SHADER or GL_FRAGMENT_SHADER...chris had actually suggest the "shader_program" name, but I kinda like putting in the GLSL/glsl_whatever to make it more obviously different from the ARB program stuff, tho pedanticly glsl is "shaders" and arb is "programs" (of course a glsl shader object becomes a glsl program object when it's linked!)...
...then I agree we should have a GLSL_link/bind/program that would be like the soon-to-be-CVSed pix_multitexture, in that it'll accept shader object ID's...the thing here is that I haven't seen examples where more than one of each shader is bound together in one program (not to say that "I've seen it all")...I have seen header files for shaders that include common lists of uniform variables, so I guess these would have to be included somewhere along the line...
otoh, i am not sure what's the fuzz about all those different compiled shader-objects. one thing is that you can keep your (shading) code cleaner and re- use it (as a programmer i mean); so it wouldn't be _that_ bad, if you had to copy everything to one file before loading it into [shader_program]. the more serious question is, whether you can use more distinct complex shaders, if they share modules(==shader objects). so if 2 shaders share 50% of the code and loading both totally separately would exceed the maximum number of instructions, you might be able to load both with the share objects (only 75% (compared to the other option) has to be loaded) is this assumption correct ? should it bother us ?
...yeh, I think it's good to stop and try to get it correct the first time, which is why I didn't just do a similar set of object like the ARB stuff...
...one thing that I REALLY want to add to this (and possibly the ARB program objects) is a way to edit the programs without using an external editor, and this'll be pretty easy to do with the tcl text widget, I'd imagine...then we have a really cool system for playing with GPU programming!
jamie
ps: do your current gl drivers include support for pixel buffer objects and framebuffer objects? If so, I had a crazy idea for multiple_windows where we could just render things to framebuffer objects and then use those for our different windows...
i know shaders only from directX hlsl like they are implemented in vvvv. there you edit the shader by rightclick on a shader node in a way like james want to have it. the shader code itself contains ALL, that means paramters, vertexshaders, pixelshaders and the way how they should compiled together.
the hierarchy is like:
1.) paramters matrices, paramters from input pins, textures, sampler ...
2.) vertexshader codes (as many you want)
3.) pixelshader codes (as many you want)
4.) techniques (a many you want) here you define which vertexshader should be combined with which pixelshader like:
technique InversTextureColor { pass P0 { VertexShader = compile vs_1_1 DestroyGeometry(); PixelShader = compile ps_1_4 InverseTexturePixels(); } }
and there is an input pin to select which technique should be used.
that means everything is in one textfile and you just need one object to load and/or edit the shader code, simple and clear.
i send an example code with this mail ...
nice greets from the meso office ;)
// -------------------------------------------------------------------------------------------------- // PARAMETERS: // --------------------------------------------------------------------------------------------------
//transforms float4x4 tW: WORLD; //the models world matrix float4x4 tV: VIEW; //view matrix as set via Renderer (EX9) float4x4 tP: PROJECTION; //projection matrix as set via Renderer (EX9) float4x4 tWVP: WORLDVIEWPROJECTION;
//texture texture Tex <string uiname="Texture";>; sampler Samp = sampler_state //sampler for doing the texture-lookup { Texture = (Tex); //apply a texture to the sampler MipFilter = LINEAR; //sampler states MinFilter = LINEAR; MagFilter = LINEAR; };
//define some input pins float param1; float param2;
//texture transformation marked with semantic TEXTUREMATRIX to achieve symmetric transformations float4x4 tTex: TEXTUREMATRIX <string uiname="Texture Transform";>;
//the data structure: "vertexshader to pixelshader" //used as output data with the VS function //and as input data with the PS function struct vs2ps { float4 Pos : POSITION; float4 TexCd : TEXCOORD0; };
// -------------------------------------------------------------------------------------------------- // VERTEXSHADERS // --------------------------------------------------------------------------------------------------
vs2ps VS( float4 Pos : POSITION, float4 TexCd : TEXCOORD0) { //inititalize all fields of output struct with 0 vs2ps Out = (vs2ps)0;
//transform position Out.Pos = mul(Pos, tWVP);
//transform texturecoordinates Out.TexCd = mul(TexCd, tTex);
return Out; }
// -------------------------------------------------------------------------------------------------- // PIXELSHADERS: // --------------------------------------------------------------------------------------------------
float4 col : Color;
float4 PS(vs2ps In): COLOR { //In.TexCd = In.TexCd / In.TexCd.w; // for perpective texture projections (e.g. shadow maps) ps_2_0
float4 col = tex2D(Samp, In.TexCd);
return col; }
float4 PS2(vs2ps In): COLOR { //In.TexCd = In.TexCd / In.TexCd.w; // for perpective texture projections (e.g. shadow maps) ps_2_0
float4 col = tex2D(Samp, In.TexCd);
return col; }
// -------------------------------------------------------------------------------------------------- // TECHNIQUES: // --------------------------------------------------------------------------------------------------
technique TMyShader1 { pass P0 { //Wrap0 = U; // useful when mesh is round like a sphere VertexShader = compile vs_1_1 VS(); PixelShader = compile ps_1_0 PS(); } }
technique TMyShader2 { pass P0 { //Wrap0 = U; // useful when mesh is round like a sphere VertexShader = compile vs_1_1 VS(); PixelShader = compile ps_1_4 PS2(); } }
technique TFixedFunctionPipeline { pass P0 { //transforms WorldTransform[0] = (tW); ViewTransform = (tV); ProjectionTransform = (tP);
//texturing Sampler[0] = (Samp); TextureTransform[0] = (tTex); TexCoordIndex[0] = 0; TextureTransformFlags[0] = COUNT4 | PROJECTED; //Wrap0 = U; // useful when mesh is round like a sphere
Lighting = FALSE;
//shaders VertexShader = NULL; PixelShader = NULL; } }
hi tebjan,
On Oct 18, 2005, at 2:55 PM, Tebjan Halm wrote:
i know shaders only from directX hlsl like they are implemented in vvvv. there you edit the shader by rightclick on a shader node in a way like james want to have it.
...yeh, but instead of a rightclick on the node, I was thinking of sending a [edit< message to the object (keeping with "the pd way"), and that would open a text widget window, perhaps even on the canvas like ben's [entry]...speaking of which, I checked that out briefly, and it seems pretty nice, but I couldn't get it to print any output on bang...time to look at the code...
the shader code itself contains ALL, that means paramters, vertexshaders, pixelshaders and the way how they should compiled together.
...snip...
that means everything is in one textfile and you just need one object to load and/or edit the shader code, simple and clear.
...that spec looks very similar to CgFX project files, but I don't know of something similar yet for glsl: perhaps we could quickly put something together with XML and start a standard with GEM/GLSL? No time atm, sadly...otoh, a pd patch with the several shader objects, presets, and such would also be similar, although not human readable in the least bit...
nice greets from the meso office ;)
...meso and vvvv!?! Whatcha doin' slum-ing around here? ;-) Seriously, I've always admired the screenshots and specs of vvvv, but never have had a machine to play around with it :-( ...I'm strictly ppc/osx, tho I guess next year even that'll change.... 'twould be nice if ya'll moved to opengl and went more cross platform :-)
l8r, james
james tittle wrote:
hi tebjan,
On Oct 18, 2005, at 2:55 PM, Tebjan Halm wrote:
i know shaders only from directX hlsl like they are implemented in vvvv. there you edit the shader by rightclick on a shader node in a way like james want to have it.
...yeh, but instead of a rightclick on the node, I was thinking of sending a [edit< message to the object (keeping with "the pd way"), and
just to stress my opinion again: i think think this should be done but it should be done not within the shader-objects itself but rather in a wrapper (-abstraction,...) editing and running a program are really to different things, even though the workflows are closely related.
but i admit that i might be a bit conservative in my views.
that would open a text widget window, perhaps even on the canvas like ben's [entry]...speaking of which, I checked that out briefly, and it seems pretty nice, but I couldn't get it to print any output on bang...time to look at the code...
i think i have a hacked version around, that was able to handle linebreaks better and probably had some other bug-fixes. time to search
mfg.a.r IOhannes
On Oct 20, 2005, at 2:56 AM, IOhannes m zmoelnig wrote:
just to stress my opinion again: i think think this should be done but it should be done not within the shader-objects itself but rather in a wrapper (-abstraction,...) editing and running a program are really to different things, even though the workflows are closely related.
but i admit that i might be a bit conservative in my views.
...I understand, and it's true that a generalized solution would benefit pd more broadly...but it also introduces a new dependency, unless we put the editor object/abstraction into gem (or even pd or zexy) proper...I just think it's seductive to put a editor class in gem's program or text objects and inherit it, but that's just a narrow view and wouldn't help others that want text editing but don't care about gpu programming...
that would open a text widget window, perhaps even on the canvas like ben's [entry]...speaking of which, I checked that out briefly, and it seems pretty nice, but I couldn't get it to print any output on bang...time to look at the code...
i think i have a hacked version around, that was able to handle linebreaks better and probably had some other bug-fixes. time to search
...yeh, and like ben said, it's broken under 0.39+ apparently...I wonder if it's scrollable, too?
jamie
Hi James,
Seems to me having such an ability would be better in Pd general that just in Gem. Seems more modular to use an external... One would have the trouble of typing a shader program in a message box, but that is there right, and it could be interesting if the shader code came from a socket or some more interesting source than the PD gui itself...
As for [entry] there is no scolling... I've never done scrolling on a widget in a canvas but it should be possible. Is it always visible or only when the contents are larger than the widget?
developing entry into a full on text editor would be pretty neat... How about extending Gems text class to do multiple font, multiple colour, multiple point size "text block" objects. ;) Underlined portions for example...
Could also be used to do crazy stuff like edit the text content of an abstraction from within PD.. (yes I have needed to do this once and a while..) search & replace etc.. Ok I'm getting crazy now, Maybe its silly and we should just use an external editor to change shader programs...
b.
b.
On Oct 20, 2005, at 2:56 AM, IOhannes m zmoelnig wrote:
just to stress my opinion again: i think think this should be done but it should be done not within the shader-objects itself but rather in a wrapper (-abstraction,...) editing and running a program are really to different things, even though the workflows are closely related.
but i admit that i might be a bit conservative in my views.
...I understand, and it's true that a generalized solution would benefit pd more broadly...but it also introduces a new dependency, unless we put the editor object/abstraction into gem (or even pd or zexy) proper...I just think it's seductive to put a editor class in gem's program or text objects and inherit it, but that's just a narrow view and wouldn't help others that want text editing but don't care about gpu programming...
that would open a text widget window, perhaps even on the canvas like ben's [entry]...speaking of which, I checked that out briefly, and it seems pretty nice, but I couldn't get it to print any output on bang...time to look at the code...
i think i have a hacked version around, that was able to handle linebreaks better and probably had some other bug-fixes. time to search
...yeh, and like ben said, it's broken under 0.39+ apparently...I wonder if it's scrollable, too?
jamie
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
B. Bogart wrote:
Hi James,
developing entry into a full on text editor would be pretty neat... How about extending Gems text class to do multiple font, multiple colour, multiple point size "text block" objects. ;) Underlined portions for example...
oh, i have thought about that. probably we could use some stripped-down html for text-formatting. (at least it is easy to learn). but it really is _very low_ on my priority list.
Could also be used to do crazy stuff like edit the text content of an abstraction from within PD.. (yes I have needed to do this once and a while..) search & replace etc.. Ok I'm getting crazy now, Maybe its silly
well you could use [textfile] for that (you just need [regex])...;)
mfg.aer IOhannes
james tittle wrote:
On Oct 20, 2005, at 2:56 AM, IOhannes m zmoelnig wrote:
...I understand, and it's true that a generalized solution would benefit pd more broadly...but it also introduces a new dependency, unless we put the editor object/abstraction into gem (or even pd or
well: while i think that gpu-programming in a nice editor is something cool, i think of it as a "cool" feature rather than a necessary one.
so i would have no problem, if we would have an external dependency (up till now, Gem knows nothing about the brutal tcl/tk-world. i would rather keep it like that) the only thing i would want to have, is that the editor should work and work an all platforms.
zexy) proper...I just think it's seductive to put a editor class in gem's program or text objects and inherit it, but that's just a narrow view and wouldn't help others that want text editing but don't care about gpu programming...
and i really would think it a folly if we would write a text-editor for pd (which is missing a usable one) and then restrict its use to something very specialist like gpu-programming.
...yeh, and like ben said, it's broken under 0.39+ apparently...I wonder if it's scrollable, too?
oh, i surely haven't tried it with 0.39. but/and i had no time to look for it (was busy doing threaded movie-loading...)
mfg.adr IOhannes
james tittle schrieb:
hi tebjan,
On Oct 18, 2005, at 2:55 PM, Tebjan Halm wrote:
i know shaders only from directX hlsl like they are implemented in vvvv. there you edit the shader by rightclick on a shader node in a way like james want to have it.
...yeh, but instead of a rightclick on the node, I was thinking of sending a [edit< message to the object (keeping with "the pd way"), and that would open a text widget window, perhaps even on the canvas like ben's [entry]...speaking of which, I checked that out briefly, and it seems pretty nice, but I couldn't get it to print any output on bang...time to look at the code...
the shader code itself contains ALL, that means paramters, vertexshaders, pixelshaders and the way how they should compiled together.
...snip...
that means everything is in one textfile and you just need one object to load and/or edit the shader code, simple and clear.
...that spec looks very similar to CgFX project files, but I don't know of something similar yet for glsl: perhaps we could quickly put something together with XML and start a standard with GEM/GLSL? No time atm, sadly...otoh, a pd patch with the several shader objects, presets, and such would also be similar, although not human readable in the least bit...
best way at all would be to make objects for the shader functions ! graphical shader programming, sheer madness ! ;)
nice greets from the meso office ;)
...meso and vvvv!?! Whatcha doin' slum-ing around here? ;-)
i'm just an intern at meso, i havn't done that much on vvvv, i coded some nodes for math with complex numbers, intersection nodes (quad/line, ray/mesh), midi clock and midi time code, and i added a time filter to the mainloop.
but pd was my first contact with graphical programming and i loved it (and still do). was spending many days and nights with pd programming. first just audio, but soon i learned to use gem, that was perfect for my researches in number theory, to display functions or searching patterns in prime number related questions. but i had often performance problems and so a friend told me about vvvv and that they have spreads (lists, arrays) and every node can handle that spreads and that the gui is more user friendly. so i tried it out and was really impressed. ... at the end i'm landed here. but for audio pd is still unreachable.
Seriously, I've always admired the screenshots and specs of vvvv, but never have had a machine to play around with it :-( ...I'm strictly ppc/osx, tho I guess next year even that'll change.... 'twould be nice if ya'll moved to opengl and went more cross platform :-)
oh yes, thats always a hot discussion, atm it seems that it will be rewritten in c# for all platforms, but no date is set, minimum 2-3 years. vvvv is framerate based (every node has to have finite state at each frame) not event based like pd, so a [t a b a a b] node is not necessary because everything happens in the same time, much better to debug ... but try it yourself if you can ...
l8r, james
cheers
[entry] could use a real programmers attension...
basically a text widget wrapped in Guenter's [button] C-code.
b.
...one thing that I REALLY want to add to this (and possibly the ARB program objects) is a way to edit the programs without using an external editor, and this'll be pretty easy to do with the tcl text widget, I'd imagine...then we have a really cool system for playing with GPU programming!
jamie
-
B. Bogart -
IOhannes m zmoelnig -
james tittle -
Tebjan Halm