[gephex-devel] opengl and gephex

[Georg Seidel]

>>There are some detailed mails from Georg around that sum up important
>>design discussions. I consider most of them quite official. :)
> 
> 
> thanks for the tip. for future reference, i've added some archive links which 
> seemed relevant. probably have missed a bunch, though.

cool, thanks for doing so.

> keywords: gephex-0.5 design / gephex-0.5 architecture
> 
> http://lists.gephex.org/pipermail/gephex-devel/2004-January/000010.html

well, these were first thoughts, in the meantime we decided to use
scons [1] as our build system. So far it seems a good choice.

> http://lists.gephex.org/pipermail/gephex-devel/2004-February/000040.html

This was fun to play with and implement, but as it turned out we threw
away all the interface definition language in favour of a pure C++
interface (see message 235).

However, it is not decided yet whether we will have a simple plugin
compiler (pluc) which creates wrapper code and initial code skeletons
from unit and type spec files. The current pluc is broken, but would not
need too much work to be reactivated.

So maybe the following post is still relevant in parts:

http://article.gmane.org/gmane.comp.video.gephex.devel/49

> http://lists.gephex.org/pipermail/gephex-devel/2004-May/000070.html

We sticked with scheme, plt scheme to be more specific [2].

> http://lists.gephex.org/pipermail/gephex-devel/2004-August/000108.html

This still reflects current design, and is simplified by having C++ link
superclass which can implement timestamp handling.

> http://lists.gephex.org/pipermail/gephex-devel/2004-November/000216.html

The followup is also relevant:

http://lists.gephex.org/pipermail/gephex-devel/2004-November/000217.html

Together both emails introduce the "lazy-if" mechanism in gephex-0.5,
which can be used to implement the more specific optimizations of
gephex-0.4 (in-place processing, strong-dependencies).

> http://lists.gephex.org/pipermail/gephex-devel/2004-November/000235.html
> http://lists.gephex.org/pipermail/gephex-devel/2004-November/000247.html

In this email martin talks about a more uniform serialisation for links
(although this is now obsoleted by the use of OSC?)

http://lists.gephex.org/pipermail/gephex-devel/2004-November/000269.html

> http://lists.gephex.org/pipermail/gephex-devel/2005-February/000415.html
> http://lists.gephex.org/pipermail/gephex-devel/2005-March/000505.html
> http://lists.gephex.org/pipermail/gephex-devel/2005-April/000611.html

There is (at least) one more new thing which has been posted to
gephex-devel: a change in the format units and link types use to report
meta-data(like number and type of ports, description, ...):

http://lists.gephex.org/pipermail/gephex-devel/2005-April/000612.html

For the interface see http://tinyurl.com/d2swl
(Current version in arch might be newer).

Here is an email of martin regarding video types in 0.5:

http://article.gmane.org/gmane.comp.video.gephex.devel/697

(btw, gmane offers a more comfortable archive because it does not
  cut threads into months...)


Here is one more little design piece regarding the C++ link and unit
interfaces, which talks about enhancing the gephex-0.5 type system to
support subtyping:

http://article.gmane.org/gmane.comp.video.gephex.devel/279


This is about a new GUI concept (philipp: the screenshot is broken,
can you upload it again?):

http://article.gmane.org/gmane.comp.video.gephex.devel/152


One more try on image data types:

http://article.gmane.org/gmane.comp.video.gephex.devel/116


There is also another unsolved issue: the format used to communicate
video data between video servers, gephex and video outputs (which will
be different processes in gephex-0.5).

An old proposal:

http://article.gmane.org/gmane.comp.video.gephex.devel/38


Sorry for the somewhat confusing email, I just went through the ml
archive backwards in time and included everything I assumed relevant.


It would be nice to update the features site and put this list of
postings there (grouped by issue) to make it easier for people to track
current 0.5 design and progress.


Regards,

Georg


[1] http://www.scons.org/
[2] http://www.plt-scheme.org/