[Fluxus] thinking about fluxus

[Dave Griffiths]

Hi all,

I recently asked Evan for some opinions as a new fluxer, and he came up
with a lot of excellent points, so I thought I'd open this up to the
list... I'd like to hear more opinions on what needs working on from a
usability pov (or anything really).

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

This is confusion on my part and needs to be fixed (now on the todo), for
the record, (opacity a) sets the alpha state in the same way as (colour
(vector r g b)) which takes a vector3, sets the colour.

The confusion arises when using colours in pdata arrays, where colour is
*sometimes* specified along with alpha as (vector r g b a). I think poly
vertcols are 4 elements whereas particle colours are 3 - it all needs to
be unified and sorted out.

I also remember your request for hsv colour support...

> frisbee looks way cool but i can't get it working.

The frisbee examples should work with the final release of plt 4 - but I
haven't confirmed this yet, and it's still very early days with that code.

> what's most difficult is finding a good scheme tutorial
> that caters to time-based graphics programming - using counters,
> persistent variables.

Well, the interesting thing is that in terms of persistent
variables/state, the way we are used to programming graphics is not really
encouraged in scheme, so not many examples are useful for this sort of
thing. Functional programming, which scheme encourages, but doesn't force
you to use, is by it's nature time-less.

The solution to this is two-fold I've found - one is to find how schemers
deal with similar problems (I recommend looking at plt's structs and
classes for encapsulating data, but I'll write a tutorial into using them
with fluxus now) and the other is to look for ways where we're doing
animation programming badly. Frisbee is the result of looking in this
direction - FrTime does appear to simplify the job of describing behaviour
well (although I need more practice at it).

> lambda functions are really confusing...
> sometimes you need them explicitly, sometimes not?

It's completely up to you when you use them, if at all, and it's not
really very much of a big deal, i.e.:

(define (invert-normals)
  (pdata-map!
    (lambda (n)
      (vmul n -1.0)) ; map this function over the normals
    "n"))

is exactly the same as (if my code is correct):

(define (invert n)
  (vmul n -1.0))

(define (invert-normals)
  (pdata-map! invert "n")) ; map invert over the normals

It's just that in the first instance the function is anonymous and
described at the same place you use it. It's really a convenience feature,
although it does make things more succinct in a lot of places, you can
overdo it.

> the particle
> functions are great, i've been starting to look into them more. using
> (clear) produces errors - i know its in my usage, but it's a beginner's
> tripping point.

Do you mean - *not* using (clear) produces errors? I'm going to provide an
alternative to f5 which nukes everything - clears the interpreter, and
calls (clear) for you.

> features i'd like to see (or haven't found):
>
> 1. some variable or function or example to get screen width/height  in
> pixels

(get-screen-size)
It returns a vector with the window width and height in it.

> 2. basic built-in increment/mod function (like (incmod X Y Z) which
> would add Y to X and mod it by Z - simple but handy for livecoding
> frame-based actions)

You don't specify it, but do you mean you want to keep X as persistent
state? This is an example where schemers would prefer something like:

(define (incmod speed mod)
    (modulo (* (time) speed) mod)))

no X is needed...

I'm ignoring that modulo only takes integers, which leads us on to...

> 3. explanations of how floating points and integers are handled (in
> scheme, or by fluxus)

Yes, I need to brush up on this too. Scheme has exact numbers (integers)
and inexact (floating point). See:
http://docs.plt-scheme.org/reference/numbers.html
I need to add an fmod, as it doesn't seem to be in plt scheme anywhere I
can see.

> 4. put editor key commands in main online documentation with
> functions, etc

I want to sort the presentation of the documentation out completely, it's
like we have the content now, it's just not presented well at all.

> 5. some more editor functionality - like in emacs or vi, with
> jumping words, lines, or to EOL, find/replace, autocomplete (!)

'end' should go to EOL - but maybe apple gets in the way.
I wonder if we can use vi as a library and just plug in the input and get
the text buffer out?

> 6. code word-wrap on screen? sometimes it goes off the side

The cursor should follow the text, but word wrap make things more
confusing with code I think.

> Of course, a few of those are fairly large features... but i threw them
> in the list anyway.

No problem - I really like feature requests!

> In general, my biggest gripe with 3D is getting a good sense of
> scale of the drawing - numbers rapidly get meaningless in 3D worlds (how
> large is a cube of size 1. 1. 1. on screen, after all?)
> Something Processing does well is to translate to pixels and back,
> according to what you want to accomplish.  If you want to do exact
> graphics, having that kind of control is really key.  Anyway, that's more
> of a general rant...

I think this is a conceptual difference between 2D and 3D. You really
don't want to be thinking in terms of pixels or frames, as it breaks
things (you absolutely want to be independant of both resolution and
framerate).

The way it works in my experience is that you pick a scale to use - ie
units are meters/cm/nautical leagues or whatever, and model and animate
everything in that scale. There is more in common with theatre or film set
design than 2D work - as you have to think about positioning lights and
cameras too.

It's less of a problem for most of the things we use fluxus for, as it's
largely trial and (mostly) error - but if you want to plan things, this is
probably the best way to go about it.

Having said all this, there are times when you need to find pixel
coordinates of something in the scene, or vice versa, mainly for
interacting via the (flat) screen and I'll add an example which does that.

> overall, so far so good.  there's a lot to look at and learn from! i'll
> keep you posted if i think of anything else.

Thanks!

dave