[gephex-devel] As promised, a few more questions

[Georg Seidel]

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

Hi Jean-Sebastian

|    I've found a little time to ask you a few questions, if you don't mind.
|
|    First, in one of your mails you said that you had built a C-interface
| for module loading. My question is simple: why build it in C? Why did
| you choose not to create a C++ interface with a class instead? Is it for
| efficiency reasons? I've never worked with dynamic loading: is it
| incompatible with a C++ interface?

I think our initial reasons were:
~  1/ allow plugins to be written in different languages (every language
~     that has C-bindings)

~  2/ avoid problems due to name-mangling in C++ (which is or was at that
~     time not standardized between compilers)

For 1: this is no longer an important point for us. I think martin,
philipp, and I agree that C++ only plugins would be OK.

For 2: I'm not quite sure about the status of this. You could say:
"I don't mind, I'm only using gcc on linux", then you would not care.
We, however, at the moment also support the microsoft visual c++
compiler on win32. (Martin should know more details about name
mangling...)

|    Second: you said that in Gephex 0.5, you "want to move into a more
| functional style of modules because [you] think this makes it easier to
| write effects and also makes the core conceptually simpler and
| optimisations more efficient". I see how it can make the core simpler,
| however I don't really get how it could make optimisations more
| efficient. Plus, as I already said, in my humble opinion it doesn't
| makes it a lot easier to write effects. Since (as I understand it) the
| effects will still be coded in C/C++, it actually makes the programmer's
| job more difficult, since it adds to its task the responsibility of
| making sure that he doesn't keeps any internal states. Or maybe I get it
| wrong and all of the effects will be coded in Scheme; but in this case I
| don't grasp how you could keep all of it efficient and I don't see
| what's the purpose of frei0r.

First: no, the plugins stay in C/C++.

Second: it does not necessarily make the programmers job more difficult.
Especially not for those simple effects that just do not need state.
In out experience this is the majority of all effects, but this of
course depends on the kind of effects you want to implement :)
The gephex philosophy could be paraphrased with "write simple
effects in C/C++ as efficient as possible and use them to build more
complex effects by chaining them together".

Third: Regarding the optimisations, I already answered this in this
post [1].

Fourth: More important than the somewhat simpler core is the following
benefit of disallowing state in effects: all state is explicitly
present in the connection of the effects. It can be easily saved and
restored, which is quite cool. This way you can make a snapshot of
at any point in time and resume with pixel-accurate results later.

Fifth: It is not so difficult to make sure that you do not have internal
state, if the plugin interface is designed properly.
For example if the interface is just:

~ void update(Param1*, Param2*, ..., ParamN*);

Then there is no instance or this pointer where state _could_ be saved.


Hope that answers your questions. Please don't hesitate to ask if I did
not express myself clearly!

Regards,


Georg

[1] http://article.gmane.org/gmane.comp.video.gephex.devel/219
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBmbbJ/rP0cdKF/ToRAitcAKDqG85EDIzeGuOb7vJWKe5YmCGX/wCgzGfL
JdesNaxlmtbHScRgYLfdp9o=
=JUSr
-----END PGP SIGNATURE-----