[Dev] Henrik Frisk: Re: connections

[Jamie Bullock]

On Wed, 2007-10-03 at 10:54 -0400, Stephen Sinclair wrote:
> Assume a GUI module (say, slider) is instantiated.  I am guessing that 
> this module should then be actually represented in two instance_hosts.  

Assuming that we have libIntegra instances - one for the GUI, and one
for everything else, then the module instance will only be represented
in one of them: the master. The slave libIntegra just acts as a proxy
for communicating between the module host (Max/MSP, PD, or whatever) and
the master instance host. The slave will perform module instantiation
through the bridge on behalf of the master, and will forward data from
the module instances back to the master instance host, which will hold
their instance data. The master also takes care of all storage using an
Integra 'bundle' with all the resources for the piece. The slave does
not store any instance data.

> The GUI has one instance_host and the Engine has another instance_host.  
> (Each with their own bridge.)  I am assuming that communication between 
> these two instance_hosts will take place, somehow, so that the slider in 
> the GUI can send information to the slider in the Engine.

Yes, using a stripped-down Supercollider-style OSC syntax.

> Well, one thing to think about is that the Engine may place the instance 
> somewhere.  (You could open the resulting Pd patch and it should be 
> legible, right?) 

OK. We need to separate two things here - the module instance, and the
module's instance data. The module instance is instantiated by the
bridge in the module host (target environmnent), the module instance
data is stored by the by the instance host (master libIntgra). 

So to answer your question, if you opened the Pd patch on 'the engine',
then you would just see the engine's module instances, not the GUI's.

>  The GUI may also place the instance on the screen 
> somewhere when viewing the routing configuration.  Additionally, the GUI 
> may place the slider instance somewhere else for what we are calling the 
> "performance pane".  Is it correct to assume that all these things will 
> be saved as instance attributes?
>
> slider:
>   - value
>   - name
>   - performance/css stylesheet for [type (knob/slider), color, style, size]
>   - performance/x
>   - performance/y
>   - routing/x
>   - routing/y
>   - engine/x
>   - engine/y
>   - connections
> 
> Is this the right way of thinking about attributes?  

I don't think so. A simple slider could have the attributes: 'postion',
and (maybe) 'name'. It's connections are part of it's instance data, but
not 'attributes of the module' as such. In a way connections are like
modules in their own right - something we instantiate.

The graphical stuff is a different matter. To me it looks like your
performance and routing panes are different views of the same object: a
slider. I would suggest that the way to handle this would be to have
several stylesheets associated with the module collection rather than
having esoteric attributes in the module definition that relate to one
specific GUI. (Someone else might want to do a GUI that doesn't have a
performance and routing pane, and this is why I would argue that this
information shouldn't be part of the attributes of a module.)

So I would represent the above slider as follows:

Inherited attributes:
	-name
Attributes:	
	-position

Its current state and connections would be held by the (master) instance
host and stored in the Integra collection:
	-mycollection.ixd

And the GUI-specific data, two stylesheets:
	-performance.xsl
        -routing.xsl

We pass the stylesheets to the GUI when the collection gets loaded.

> An instance really 
> has several attributes that are not necessary in the module definition. 
>  
> Does that mean that instances have multiple inheritance with an 
> "instance" or even "GUI instance" class? 

I'm not sure what you mean here, but maybe the above answers it...

>  How do "subattributes" come 
> into play here?

I would like to deprecate subattributes unless someone can come up with
a really convincing argument why we should keep them. We did have a
'get' subattribute, for getting the current value of an attribute, but
currently we use the an empty message as a getter:

/freq 440 (sets the value of the attribute if appropriate)
/freq (gets the current value if appropriate)


best,


Jamie


-- 
www.postlude.co.uk