[gephex-devel] Similar project

[Jean-Sebastien Senecal]

Georg Seidel wrote:

[...]

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


Yes, we call them "gears".

[...]

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


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

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

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


Why did you choose to do so?

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

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

We've also thought about adding an extra layer in a language such as 
python or scheme. Scheme seems fine to me, so that might be another 
common ground.

[...]

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

[...]

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

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.

Cheers,

    J.S.