Re: What we need

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