design changes for gephex-0.5

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In this post I try to summarize the design changes for gephex-0.5
that we came up with during the piksel workshop.

- ------

The most important change was a simplification of the
unit interface. The new interface looks something like:

~  const char* get_spec();
~  const char* get_port_spec(int port);
~  void update(Link* ports[]);

Note that there is no instance pointer, no set_port,
no notion of strong dependencies or patching.
The argument to update is an array of pointers to
the links that are connected to the respective ports.

- ------

The second change we decided was to simpify the passing
of the function-tables for all plugin types (links, linktypes,
units). We no longer use the "array of strings and function pointers"
that is ultra-compiler-independent but also awkward to work with.
Instead we just pass c structures with function pointers which
are assumed to be packed (no alignment between pointers).

- ------

The third change was to change the interface to core to be more
c-like (no member functions for classes, only one header etc).
This will ease the integration of core into a scripting language.

- ------

Fourth, we decided to handle optimizations (like strong dependencies
or patching) in a new, unified way.
The unit itself does not deal with it anymore. Instead, we introduce
a special "lazy if" directive in the scripting language.

This lazy if will have two inputs (of arbitrary, but equal linktype).
Additionally it will have one boolean input which decides which of the
two firstmentioned inputs will be used. The core will process this
like a switch in the graph, with the effect that the unneeded input
(and the whole subgraph that is behind it) will not be updated.


OK, to make this clear I show you how this can be used to implement
a strong dependency and patching behaviour vor a xfader. I use a graph
oriented description and add a scheme equivalent below.

~   xfader_simple
~      ____
~    -|x   |
~    -|f1 f|-
~    -|f2  |
~     '----'

First I describe the intended behaviour:
~  * if the x value is 0, the subgraph connected to f2 should not
~    be updated and f1 should be directly patched to the output f.
~  * if the x value is 1, the subgraph connected to f1 should not
~    be updated and f2 should be directly patched to the output f.

So we add two new units:

~   ______            ______
~ -|x 0? b|-        -|x 1? b|-
~  '------'          '------'

which take a number and ouput a boolean value whether it is 0 or 1.
Further, the "lazy if" is denoted by

~    ____
~  -|b   |
~  -|1  o|-
~  -|2   |
~   '----'

The resulting graph that implements the behaviour we want (and which
is implemented in gephex-0.4 with strong_dependencies + patching)
looks like that:
~        ________________________________________________________
~       |                               ______                   |
~       |     ,------------------------|x 1? b|-                 |
~       |    /              ______     '------' \                |
~       |   /--------------|x 0? b|-\    ____    \      ____     |
~   <x>-|---   ____        '------'  ---|b   |    -----|b   |    |f
~       |   \-|x   |             <f1>---|1  o|-  <f2>--|1  o|----|-
~  <f1>-|-----|f1 f|--------------------|2   | \-------|2   |    |
~  <f2>-|-----|f2  |                    '----'         '----'    |
~       |     '----'                                             |
~       ---------------------------------------------------------

(Note that I duplicated the input links <f1> and <f2> inside the graph
for better readability).

In scheme, this could possibly look like (some detail regarding exposed
ports etc omitted):

(define xfade (lazy_if (1? x)
~                        f2
~                        (lazy_if (0? x)
~                                 f1
~                                 (xfade_simple x f1  f2))))

where x_fade_simple is the xfader without optimizations.
This xfade define will then behave indentically to the current 0.4 xfader.

- ------------

At the end I want to explicitly mention that many of the presented ideas
are not originally from me. For example the lazy if approach came from
martin, while the initial idea to move into a more functional direction
was from me. And the details of the solution were worked out by philipp,
martin, and me in many discussions.

Regards,

Georg

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBlI9H/rP0cdKF/ToRAhX9AJ9enckYgNLqi0JHorEH5hX+db/vrACgvR48
KMrfher7gJlAF/3wQlslZRI=
=lAVS
-----END PGP SIGNATURE-----