[Fluxus] thinking about fluxus

[evan.raskob [lists]]

On Jun 19, 2008, at 10:47 AM, gabor papp wrote:

>>> your examples are good, and there are lots... colors are a bit  
>>> hard to
>>> understand - are they vector3's or 4's? i can't seem to figure  
>>> out how to
>>> use alpha.
> i think it would be nice if both could be used everywhere like  
> glcolor3f/4f.

I second that - or even (to steal from Processing) a single value to  
be interpreted as grayscale.

And of course, as Dave reminded me, HSV mode!


>
>>> Something Processing does well is to translate to pixels and back,
> processing was created for novice users, and it works very well for  
> them, but i'm afraid this approach is not really ideal for more  
> complex projects. it causes many problems in processing when you  
> are dealing with matrices, frustums and cameras and the environment  
> starts to behave very strange and differently in p3d and opengl  
> mode for the same code.
> so, i second dave's opinion.

Yes, this is very true and Processing can make 3D a real nightmare if  
you try to use OpenGL and do anything complex.  Although, an issue I  
run into is using fixed-size screens (like LED screens) and needing  
pixel-accurate rendering, which is incredibly hard if not impossible  
using OpenGL.  Of course, I recognize this isn't for everyone.

What I do using other systems is a combination of GUI "playing" with  
the camera to find the right settings and then code them into a  
visual app, because as you said, Dave, it's like filmmaking and in  
filmmaking you write storyboards but when you go to shoot the picture  
you've got to play with the camera and cinematography and see what  
works in the space.  What I do in other environments (Max/MSP/Jitter)  
is move the camera around with the mouse and auto-save things like  
camera position, rotation, scale, object positions in "presets."  I  
don't know how this would translate into livecoding/fluxus - maybe an  
interesting feature would be to define a "preset" variable that gets  
its value autosaved into the scheme file.  So, you could say "link my  
preset value to the current mouse position" somehow in code and then  
actually watch it change in your scheme code on the screen, knowing  
that saving the file saved those values.

Ok, here's an even crazier idea :)
Make all numbers typed into scheme "draggable" - change their values  
by clicking with the mouse and dragging up/down.


About the rest below - I agree with all.  The keycodes on OS X make  
the recorded examples look as if they were typed by drunken sailors :)

> i have been also thinking about improving the visual productivity  
> of fluxus. for the first step i would need to move the rendering  
> code to work in an opengl framebuffer object. i also suggest to  
> separate the rendering of the visuals and the scratchpad. i think  
> that blurring the scene should not blur the contents of the editor.  
> moving the rendering into an fbo would solve this. furthermore, it  
> would open a way to process the output in a lot of interesting  
> ways. what do you think about this?
>
> for the sake of completeness i bring up some other issues, which  
> were mentioned before.
> - one time source for everything, crucial for playing back recordings
> - abstract event system to be able to replay the recorded events on  
> various platforms (different platforms have different keycodes).
> - following the previous issue, it would be nice to solve exporting  
> all kinds of input events (osc, midi) not just keys, mouse events
> - more complete support of the osc protocol
>
> i would be more than happy to help out with any of these issues.
>
> gabor
>