[gephex-devel] Similar project

[Georg Seidel]

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


|
|> ~  * 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.)
|
|
| Actually, the same concept holds in Drone. We've got a GearGui that may
| be associated with each Gear: those define the gears' look. That allows
| us to design any kind of interface for the gears (see MiniTV and Slider
| for instance).

OK, then I just misunderstood that in your code. Btw, drone now compiled
and runs, but crashes when trying to play avi files.

|> ~  * 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)
|
|
| Yes, this is something we would like to see in Drone. I guess that could
| be a common ground. Looking at the code, there are a few things I don't
| get however; I'll send you another mail to ask you a few questions, if
| you don't mind.

Sure, I am looking forward to your questions and comments.

|> ~  * gephex has a client server architecture, the gui is a different
|> ~    program
|
|
|
| Why did you choose to do so?

In the beginning we had the plan to use gephex for long-running
interactive installations, and thought it would be nice to
just let the engine run and detach the gui. So far we did never
do an installation, but detaching and attaching the gui proved
useful nevertheless (e.g. a crashing gui does not crash the
engine).

[...]

| Actually, the next big step we'd like to make is to design what we call
| "metagears", which is the equivalent of functional programming
| facilities in Drone. The idea is, we'd like the user to be able to
| create graphs and "wrap" them in a single gear. Another example is a
| gear that loops over an array and calls another gear for each element. I
| guess this is what you call "hierarchical graphs".

With hierarchcal graphs I mean something like your metagears.
We never thought about loops.

|> 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.
|
|
|
| I don't see why it'd make optimisations more efficient.

OK, let me expand a little. One of our main optimisations is
to not recalculate effect modules whose inputs did not change.
But since modules might keep state, this is only a safe thing
to do if the modules have a special "deterministic" flag set.

With the new design in gephex-0.5, where the core can "see" all
state, this kind of optimisation can be done automatically and
even dynamically (imaging modules that only _somtimes_ change
their state, with the gephex-0.4 design there is only a static
deterministic flag).

Hope this makes it a little clearer.

|> 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.
|
|
| Well, this is ok if your state consists of such a simple thing as a
| random seed; but what if it consists of many different parameters?
| You'll have to remember to plug all of them back in the inputs. Or you
| could create a specific class (type) for them, but then that adds more
| complexity IMHO. I don't know if it is much suitable for a graphical
| interface (but then, I guess that would all be in the "runtime layer"
| and the GUI would contain objects in which these things are abstracted).

Yes, you are right, this additional complexity would be hidden by the
runtime layer. We thought about simple scheme fragments that do these
"state connections".

One other point: in our experience, the only modules that require a lot
of state, and complex state, are IO modules like a video input/output,
audio input/output etc.
And we planned to eliminate these modules in gephex-0.5, because they
also introduce possible locking issues and instabilities into the
core update process. So instead of having I/O modules, we will create
specific I/O servers for video, audio etc which pipe their input to
the core via a simple piping protocol.

| I'll need to discuss with the Drone team ASAP. However, this week is
| Drone's first week at school: we're doing a first live performance
| thursday and a first interactive installation saturday... so we're much
| occupied! I'll call for a meeting next week.

Sure, take your time! We should not hurry too much and carefully
consider the best way to join forces.

Regards,

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

iD8DBQFBkSDd/rP0cdKF/ToRApH+AKDfXWaFbRVgMT+68/DBI0YwB8sf+wCdHnvq
FCBQ6XcSQ8VblvBtHL4lr3c=
=XVk9
-----END PGP SIGNATURE-----