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

[Tim Janik <timj gtk org>]

On Wed, 22 Sep 2004, [iso-8859-5] °àâñÜ ¿ÞßÞÒ wrote:

> On mer, 2004-09-22 at 06:02 +0200, Tim Janik wrote:

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

right, they are not supposed to be in the binding at all, the server related
procedures exported through the glue layer are though:
       bse_server_can_load (server, file-name);
       bse_server_construct_note (server, semitone, octave, fine-tune);
       bse_server_describe_note (server, note, fine-tune);
       bse_server_get_custom_effect_dir (server);
       bse_server_get_custom_instrument_dir (server);
       bse_server_get_demo_path (server);
       bse_server_get_effect_path (server);
       bse_server_get_instrument_path (server);
       bse_server_get_ladspa_path (server);
       bse_server_get_midi_notifier (server);
       bse_server_get_mp3_version (server);
       bse_server_get_plugin_path (server);
       bse_server_get_sample_path (server);
       bse_server_get_script_path (server);
       bse_server_get_version (server);
       bse_server_n_scripts (server);
       bse_server_note_from_freq (server, freq);
       bse_server_note_from_string (server, name);
       bse_server_preferences_locked (server);
       bse_server_register_core_plugins (server);
       bse_server_register_ladspa_plugins (server);
       bse_server_register_scripts (server);
       bse_server_save_preferences (server);
       bse_server_use_new_project (server, name);

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

yes, it definitely is. beast-gtk/beast also uses only the functionality
exported through the glue layer, so you're not lacking any essential features.

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

to all the bse procedures, all the structures (bse-structs) and a few other
things provided by the glue layer, e.g. properties: sfi_glue_proxy_set/
sfi_glue_proxy_get, or signals: sfi_glue_proxy_connect/sfi_glue_proxy_disconnect.
i.e. you will want to read over sfiglue.h, sfiglueproxy.h and maybe
sfigluecodec.h.

as mentioned earlier, it'll be easier if you copy over something like
sfidl-clientcxx.h+sfidl-clientcxx.cc and start modifying the source it generates.

>
> --Artem
>

---
ciaoTJ