[gephex-devel] Re: GePhex and scripting

[Georg Seidel]

Hi Teemu!

Thanks a lot for your interesting email.
Glad to hear you like GePhex and find it useful for your work.

>I have a question about a feature that would really make GePhex even more 
>useful for our purposes:
>GePhex seems to be very object-oriented by architecture, the design is 
>strikingly modular. This lead me into wondering if it would be difficult 
>to embed, say, a Python interpreter in it - in the spirit of Blender's 
>Python scripting. That would allow for some really cool things, especially 
>if you can import external Python libraries like Blender allows you to 
>do.
>
Let me explain the current situation.
At the moment we have two different branches of development for GePhex.
The first is GePhex-0.4. This is the stable version. What we do here is 
mostly
fixing bugs and doing small improvements (like new modules, 
optimizations,...).

The other branch is GePhex-0.5. This is a complete rewrite. A few of the 
main
characteristics are:
   * simpler design (we feel that the 0.4 design is a little 
overengineered in some
       aspects, because we had design goals that proved to be not very 
important
       for the way we use GePhex now. As an example, in the original 
design it
       was possible to use the engine and the gui on different 
computers, making
       the handling of video and image files harder than necessary...)
   * better usability, especially for live gigs (you really can do nice 
things with
      the current system, but you need some time to prepare, and 
creating new effects
      live is really hard work)
   * better plugin system, making support for different effect plugin 
formats easier
      (for example, we want to support freeframe effects)

Part of the "simpler design" is, that we have a rather minimal core that 
is responsible
for loading plugins, connecting them and updating them in the correct order
(this is already done).
Layered upon this core will be some kind of scripting engine (we have 
experimented
with guile, a scheme interpreter, but did not decide yet which language 
to use).
And layered on top of this scripting engine we will have the new user 
interface.
This will hopefully make it possible to access this scripting layer from 
the user interface.
So our current plan is embedding the scripting language.

Unfortunately, the development of GePhex-0.5 is not really fast at the 
moment
(all developers are in their final year in university, and consolidation 
in the 0.4 branch
takes some time, too).
We already have a plugin infrastructure (including a compiler which 
generates some
glue code), and a working core. But the scripting stuff, and most 
importantly the user
interface is missing.

>There may already be work in this area that I am not aware of, so 
>apologies for my ignorance if so. I did look in the mailing list 
>archives, but did not see anything regarding scripting.
>
There was not much discussion regarding the scripting language.
However, we have at least three criteria regarding any solution:
  * must be free software (GPL compatible license)
  * must be available at least on win32, GNU/Linux and osx
    (preferably also on (Free|Open|Net)BSD)
  * must not involve too many external dependencies

>Python is a rather nice language for embedded scripting. Below are a 
>couple of related links. The former gives a nice example of embedding a 
>Python interpreter in a C/C++ application, while the latter is the 
>official documentation on the same topic.
>
I agree that python is a nice language. It has the advantage of having a 
bigger
user base than scheme as far as I know (at least in the open source world).
The thing I like about scheme is the "missing syntax", i.e. the extreme 
syntactic
simplicity.

>"Embedding Python in Multi-Threaded C/C++ Applications", Linux Journal 
>http://www.linuxjournal.com/article.php?sid=3641
>
>"Python/C API Reference Manual", PythonLabs 
>http://docs.python.org/api/api.html
>
>BTW: Some enthusiasts argue that, instead of embedding Python as described 
>in the article linked above (or as done in Blender), you would be better 
>of extending it. No doubt you can tell best which model would suit GePhex. 
>The rant is here:
>
>"Extending Vs. Embedding - There is Only One Correct Decision", Lefkowitz 
>http://twistedmatrix.com/users/glyph/rant/extendit.html
>
>Any thoughts? I am not familiar with the code-level workings of GePhex, so 
>I may be far off the track here.
>
Thanks for the links, I'm going to dig into this when I find some more 
spare time!

I cross-posted this email to gephex-devel at lists.gephex.org, because I 
think the discussion
belongs there.

Regards,

Georg