[gephex-devel] What we need

[Jean-Sebastien Senecal]

Hi Martin,

Martin Bayer wrote:

[...]

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


That sounds good. I think that would cover most of the video effects we 
could think of. Mathematically speaking, we don't have a need for n-ary 
operators for n > 2 since these can be implemented by combining unary 
and binary operations.

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


We thought about that recently since we started adding this 
categorisation concept in Drone. However, we came to the conclusion that 
the best option was to make the categorisation implicit to the 
localisation of the libraries in the directories hierarchy. For 
instance, the module whose path would be 
"$PLUGINS_ROOTDIR/video/io/videosource.so" would be categorized as 
"video -> io". I like the fact that the categorization is not hardcoded.

As for icons (and every software-specific characteristics), that could 
easily be solved by adding an associated description file with the 
module. This description file wouldn't be in the frei0r specs, but there 
is no problem to add it in Drone or Gephex.

>>    2- LiViDO (good, but I like the simplicity of frei0r so...)
>
>
> After the exhausting discussions the last month the list seems to 
> hibernate again.


Sorry, I don't really get that. I haven't followed the discussion. In 
fact, I'm pretty curious to know more about the "history" of LiViDO vs 
frei0r and other Piksel-related topics.

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


That sounds good. I'll encourage a couple of non-developper in my 
surroundings to post there too. And it's ok for me if we have our 
discussion on the mailing list first.

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


That sounds good to me. I've never used arch, but I've used CVS and SVN 
alot.

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


I agree on that. Now let's kick some asses. ;)

  J.S. aka Tats