[Dev] gui instance host question

[Jamie Bullock]

Hi Steve,

More good questions!

Firstly, a general point that should be made clear is that there is no
*requirement* for any host wishing to support Integra to use libIntegra.
The purpose of libIntegra is simply to provide the 'glue' code and a
basic framework to make it substantially *easier* to support Integra.
However, any host the follows the Integra OSC *protocol* can communicate
with another Integra host, and any host that writes XML following the
Integra XML *schema* can have its files read by another host that
supports the schema (including the Integra database). The point is that
the protocol and the Schema are the important things not libIntegra --
although I would think that everyone's hosts will be more maintainable
if they do use libIntegra ;-) (See specific answers below)

On Mon, 2008-07-07 at 19:29 -0400, Stephen Sinclair wrote:
> Hi,
> 
> Say, theoretically, that a GUI has its own instance host (and bridge)
> instead of relying on OSC to communicate with Integra.  The examples
> in library/trunk show that a Pd server (audio engine) can respond to
> OSC messages from a GUI, where examples are given in Python and Pd.
> However, if the *GUI* already has its own instance_host, can it not
> communicate with the instance_host directly instead of sending OSC
> messages?  
> That is, does the instance_host provide a C API similar to
> the OSC messages it handles?  

Not at the moment, although there is a plan to add this. Internally each
OSC address node corresponds to a function call, but the functions
follow the liblo callback prototype, so it wouldn't be very nice to
expose them through the public API. Eventually we'll have something like

liblo_style_callback(liblo_type args){

	public_instance_host_method();

}

But also...

dbus_style_callback() {

 	public_instance_host_method();

}

python_method() {

...

java_method() {

...

etc

Because we'd like to (optionally) support other protocols, not just OSC.


> When the bridge calls "ih_callback", it
> seems to be limited to messages that change port values.  How would a
> bridge be used to create and connect module instances?

Communication between *modules* and the bridge is bi-directional and
environment native. This means, for example that Integra modules in Max
only need to send/receive Max messages to/from the bridge.
Communication  between the *module host* and the *Instance Host* is also
bidirectional. For example, the module host chooses one of the public
APIs e.g. OSC, and makes 'method calls' to the Instance Host, and
receives messages back via that protocol if required e.g.:

send:
/register <my ip> <my port>
receive:
/registered <your ip>
send:
/load <module name>
receive:
/loaded <instance name>

etc.

The *bridge* should be viewed as working on *behalf* of the Instance
Host. The instantiation messages etc, always go to the IH, and then the
bridge does the actual work. However, as I mentioned above, I'd like to
provide a number of interfaces to the IH to make it nice and flexible
for devs.

Does that make sense? Does it answer the question?

best,

Jamie

-- 
www.postlude.co.uk
http://www.linkedin.com/in/jamiebullock