[gephex-devel] What we need
Georg Seidel
georg at gephex.org
Sat Dec 18 16:56:39 CET 2004
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
| 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
I have a different proposal for frei0r 2.0.
It is motivated by the wish to have multiple effects per plugin.
I propose that in frei0r 2.0 plugins, only one function is exposed
by the plugin, let's call it
~ struct frei0r2_effect* get_frei0r2_effect(int index);
struct frei0r2_effect would be a structure holding function pointers to
the frei0r functions as defined for frei0r 1.0 + the update2 function
(or we could use three different update functions update_source,
update_filter, and update_mixer).
The rest could stay unchanged to frei0r 1.0.
This way one plugin can implement any number of frei0r 2.0 effects
(and even one frei0r 1.0 effect in addition).
Advantage: multiple effects/plugins (makes code sharing between
~ related effects much easier).
Disadvantage: Slightly more complicated to write new effects,
~ frei0r 1.0 plugins cannot be loaded by frei0r 2.0 only hosts.
What do you think?
Regards,
Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBxFM3/rP0cdKF/ToRAlTmAKDyIPJr4xepqZ53ffPktEI+vuJpLQCfc3rr
Zh5zhuLfVA97jm+g9fVmlxs=
=Dqmm
-----END PGP SIGNATURE-----
More information about the gephex-devel
mailing list