More on bindings (was Re: hello world in BSE)

[Артём Попов <tfwo mail ru>]

On mer, 2004-09-22 at 06:02 +0200, Tim Janik wrote:
> yeah, that's on my TODO list as well, has a couple hundred items above
> it though ;)
> i can't say i'd recommend writing a language binding to anyone except stefan
> and me at this point, but if you really want to do this, you'll need to
> implement something like sfidl-clientc*.cc to generate your binding.

Well, I want to learn more about BSE in a practical way. I've used the
gtk# code generator until now. I guess it was not the appropriate tool.
At least it's not good for the bse-procedures... Now I'm not even sure
about BSE core language: scheme or idl lol? :) a bedevilled system
indeed :)

> > I'm also having a problem dynamically loading the methods:
> > register_core_plugins
> > register_scripts
> > register_ladspa_plugins
> > Are they renamed somehow in .so? The runtime just says:
[...]
> i don't know the C# runtime. however BSE doesn't provide functions
> named e.g. "register_core_plugins". what you can do is call a BSE
> procedure manually like this (provided you have a server handle):
>   sfi_glue_vcall_void ("BseServer+register-core-plugins", 'p', bse_server_object, 0);

But what about, say, BseServer methods declared in bseserver.h, like
bse_server_get, bse_server_create_project, etc. Or they're unsupposed to
be in the bindings at all?

In that case, will it still be possible to use such bindings to create
standalone applications?? Like a pure gtk# mini-beast :) targeted to a
specific performance, etc.

> due to the project being slowly ported to C++ (at least the BSE part), there
> are two way currently to implement a BSE procedure. a BSE procedure differs
> from an ordinary C function, in that it is callable from outside the BSE
> core thread, i.e. from the user program (which may call none of the ordinary
> BSE functions). the original way in pure C to define a procedure is to
> use the GObject property system in conjunction with function pointers.
> because it was so tedious to use manually, i wrote a small perl script,
> that parses .proc files adds some tedious glue code and generates readily
> compilable .c files (simplified):
> METHOD (BseServer, register-core-plugins) {
>   HELP  = "Register core plugins.";
>   IN    = g_param_spec_object ("server", BSE_TYPE_SERVER, G_PARAM_READWRITE);
> }
> BODY (BseProcedureClass *proc,
>       const GValue      *in_values,
>       GValue            *out_values)
> {
>   /* extract parameter values */
>   BseServer *server = g_value_get_object (in_values++);
>   SfiRing *ring;
>   /* check parameters */
>   if (!BSE_IS_SERVER (server))
>     return BSE_ERROR_PROC_PARAM_INVAL;
>   bse_server_register_plugins (server);
>   return BSE_ERROR_NONE;
> }
> 
> where bse_server_register_plugins() would be an internal BSE function
> that can not be called from the user program. the majority of the procedures
> as listed in bse-procs are stil limplemented in .proc files.
> 
> the second and new way to implement procedures is with IDL files and C++:
> --- IDL ---
> namespace Bse {
> Int  source_get_mix_freq   (Source          obj);
> };
> --- C++ ---
> namespace Bse {
> namespace Procedure {
> Int
> source_get_mix_freq::exec (BseSource *self)
> {
>   if (!self)
>     throw std::runtime_error ("invalid arguments");
>   return BSE_SOURCE_PREPARED (self) ? bse_engine_sample_freq() : 0;
> }
> } // Procedure
> } // Bse
> 
> (modulo some magic registration macro ;)
> 
> we hope to have -at some point- all of the core ported to C++, so we can
> get rid of stuff like the .proc files. (we started out with the C++ migration
> in summer 2002).

If I understood this right, a complete C# binding would be a binding to
all the bse-procedures + my last question: the managed way to start the
core thread. Did I miss anything else?

--Artem