[gephex-devel] Similar project

[Georg Seidel]

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

Hi Jean-Sébastien!

Just had a short look at your project, and I find it very promising.
Especially the GUI screenshot is very nice - the way you paint your
effects (are they called gears in drone-speech?) seems very good to me.

Unfortunately I could not manage to compile drone-0.0.1. After qmake and
make I got the following error:

~  g++ -c -pipe -Wall -W -g -D_REENTRANT  -DQT_THREAD_SUPPORT -DQT_SHARED
~     -DQT_NO_DEBUG -I/usr/share/qt3/mkspecs/default -I. -I. -Isrc
~     -Isrc/gears -Isrc/types -I/usr/include/libmpeg3 -I/usr/include/qt3
~     -o Gear_AudioInput.o src/gears/Gear_AudioInput.cpp
~  In file included from src/gears/Gear_AudioInput.cpp:2:
~  src/gears/Gear_AudioInput.h:9:23: portaudio.h: No such file or
~  directory

I could not find the file "portaudio.h" anywhere in the sources.

So far I only had a very superficial look at your source code.
But maybe long enough to outline some of the most obvious differences
I see between drone and gephex (which are equally important as the
conceptual similarities if we want to cooperate):

~  * gephex has a clear separation of modules (= effects =? gears)
~    and their representation in the gui. Modules do not contain any
~    GUI code, just meta-data about their parameters (e.g. which widget
~    to use etc.)

~  * gephex has a C-interface to its modules (because modules are
~    loaded in shared libraries at run-time this is just simpler and
~    more portable) - this interface is very small
~    (if you are interested, you can check it in engine/src/dllmodule.h,
~     and the interface for types in engine/src/dlltype.h)

~  * gephex has a client server architecture, the gui is a different
~    program

~  * gephex-0.4 is totally bloated :)

What I really like a lot about your code is the use of modern C++
features, and its relative (compared to gephex-0.4) simplicity.

I want to outline the new design we have for gephex-0.5 shortly, just
to inform you about the direction we are currently heading.
The new design can be seen as consisting of three layers:

~        1         gphx_core
~                -----------
~        2        gphx_runtime
~                ------------
~        3          gphx_gui


Layer 1, gphx_core will be written in C++. It will be a minimal core
that can build up graphs of effects and updated the effects in the
resulting order.

Layer 2, gphx_runtime will be written in a scripting language, current
favourite is scheme, but we did not decide yet. It will add the
abstraction of hierarchical graphs (if you see it as a graphical
programming language, the equivalent of procedures or functions).

Layer 3, gphx_gui will be the high-level interface to gephex-0.5.
However, we want to create a gui that is more suitable for live
vj usage than the current one.


The next important change for gephex-0.5 is the module interface:
we want to move into a more functional style of modules because
we think this makes it easier to write effects and also makes
the core conceptually simpler and optimisations more efficient.
The basic idea is that the new effects (we call them units)
are not allowed to keep internal state - instead they must
produce the same output whenever the input is the same
(in other words they define an injective mapping from input to output).
Whenever state is required (e.g. random generator with seed)
it has to be provided by a feedback:
just connect the output of the random generator with its seed input.
This way, the state is inherent in the connection of the effect graph
and can be easily safed and restored.
If you see the whole thing as a graphical programming language, we
want to create a functional graphical programming language instead
of the imperative one we have now.

So this is an as-short-as-possible outline of our plans. I should add
that the new core is almost finished, but the runtime and gui layers
are not even started yet.


I have more to say, especially on possible areas of cooperation,
but this email is already long enough.

Awaiting your comments,

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

iD8DBQFBkKhp/rP0cdKF/ToRAutkAKCJunhRFeD7GCgL3KWmag6EGVba+wCdGPoQ
au7GnnJwb3sASa7fcFrO/6U=
=XUEH
-----END PGP SIGNATURE-----