[gephex-devel] What we need

[Martin Bayer]

Hi Jean-Sebastien,

>    While working with frei0r, I started thinking about what GePhex and 
> Drone could share, at the plugin level. I think this is a good place to 
> start exchanging code, since we haven't agreed yet on a common core (*) 
> For me, frei0r is really the way to go first. 

My plan for frei0r is to make a frei0r (1.0 abi) plugin release after 
gephex 0.4.2 is ready. This is the list of plugins that are in our 
frei0r arch repository:

brightness
delay0r
invert0r
nois0r
pixeliz0r
twolay0r
bw0r
distort0r
ising0r
nosync0r
saturat0r
contrast0r
flippo
lissajous0r
onecol0r
scanline0r
tehroxx0r

Some are built on top of my c++ helper header, that reduces the 
boilerplate code of a effect plugin a lot.

> But a lot of filters I 
> want to see in Drone's basic package are video compositions i.e. binary 
> operations. We have managed to extract 20 different compositions from 
> the Gimp code, a lot of which are also available in MMX (the MMX 
> versions are not yet part of Drone however) (see our VideoMix gear
>    Related to that, I got one question and one proposition.
> ) and
> this is one of the things we work the most with.

Yes, this is also on my wishlist for the next api of freiOr. This would 
be possible by

1. changing the signature of the update function or adding a 
f0r_update_mix to the existing function to keep the 1.0 API  plugins 
compatible the the 2.0 API.

+void f0r_update2(f0r_instance_t instance, double time,
+                 const uint32_t* inframe_1, const uint32_t* inframe_2,
+                 uint32_t* outframe);

2. Adding a third effect type

#define F0R_PLUGIN_TYPE_FILTER 0
#define F0R_PLUGIN_TYPE_SOURCE 1
+#define F0R_PLUGIN_TYPE_MIXER 2

We thought about that while designing the 1.0 API but wanted to keep the 
initial version as simple as possible.

>    The question is: in what framework should we implement the binary 
> operations? Possible answers are:
>    1- Drone (this is bad, I think, cause it will double the work we have 
> to do)

Native plugins always have their advantages to cross application 
plugins. There are e.g. some small disadvantages of the frei0r effects 
if you compare them with the native(gephex) one.

- no plugin specific icon
- no hints for grouping effects in the userinterface

>    2- LiViDO (good, but I like the simplicity of frei0r so...)

After the exhausting discussions the last month the list seems to 
hibernate again.

>    3- Frei1r (**fictious name**) i.e. a framework similar to frei0r for 
> video compositions

hehe or Frei1e :)

>    I would personnaly go for option 3, and offer to implement the 
> interface. However, I'd like to have your opinion on that.

I also like to see binary operations in the next api version of frei0r.

>    Now, here is the proposition: I'd like to start building a list of 
> the basic effects both GePhex and Drone need.

We could post the a query to the gephex-user list to get some non 
developer input.

> We could put those on a 
> wiki, for instance, or maybe even a bugtracking system. 

For the initial discussion a mailing list should be enough in my opinion.

>I think that 
> would be a good first step for cooperation.

How should be manage the source code of our frei0r plugins? At the 
moment the georg, coma and i use the arch repository at 
http://arch.gephex.org. I also merged all frei0r code of other 
developers (carlo and you) into that repository.

> (*) We're planning a release of a stable core for (hopefully) 
> mid-january. When do you plan to release gephex 5.0? 

We don't have a release timeframe for 0.5 as all gephex developers are 
quite short in time at the moment and there is a lot of work needed to 
get the 0.5 code in some usable state.

> There would be an 
> opportunity, once both frameworks will be implemented, to start sharing 
> ideas and -- this is wishfull thinking, but it would be soooo nice -- 
> maybe agree on a common ground.

Improving the plugin api and sharing more effects is quite a good start 
to share knowledge and to reduce duplicate efforts.

Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://lists.gephex.org/pipermail/gephex-devel/attachments/20041216/2022ad66/signature.bin