[Fluxus] thinking about fluxus

[Dave Griffiths]

>>> 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.

Yes. I agree. And as Evan says, hsv, single value=grey - and similar,
scale with a single value = uniform scale.

>>> what's most difficult is finding a good scheme tutorial
>>> that caters to time-based graphics programming - using counters,
>>> persistent variables.
> i haven't looked into this yet, but the new plt documentation looks quite
> good. they have a section on frtime at
> http://docs.plt-scheme.org/frtime/index.html

One of the major improvements of plt 4 is the documentation. I'll look
into using their doc system (scribble) for fluxus too.

>> I wonder if we can use vi as a library and just plug in the input and get
>> the text buffer out?
> this would be excellent.

It would be the clever way of doing it. I really don't want to get into
the realms of writing another text editor, unless we can show that it's
the only way (things we need to do for livecoding that other editors can't
do).

> 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.

Yeah, I suppose so, it might have outlived it's amusement value now :)

> 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?

It would be nice to have this. Render passes are already abstracted out to
the scheme layer, so we should also bind the FBO setup and describe the
passes and shader assignment in scheme.

I have a long term aim to move to deferred shading, and write a complete
lighting model using glsl - but this is a bit far off and low priority.

And fluxus always has to run on old hardware too.

> 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

Yup.

> - abstract event system to be able to replay the recorded events on
>   various platforms (different platforms have different keycodes).

Yup - I'd need some help with that being without an apple.

> - following the previous issue, it would be nice to solve exporting all
> kinds of input events (osc, midi) not just keys, mouse events

Funnily enough, fluxus pre 0.12 had osc recording in the keypress
recorder, but after making everything modular I had to take it out. The
best way to do this now is to do all this work in scheme (as this is the
only place that should have direct contact with any of the modules).

> - more complete support of the osc protocol

Agreed

I should have some time to look at fluxus in more detail again soon, but
any help is always appreciated. What I'll do is open up the process a
little, and get better organised, I've started building up a todo list
here:

https://savannah.nongnu.org/task/?group=fluxus

Feel free to add, or even take on the tasks :)

cheers,

dave