[Dev] connections

[jb at integralive.org]

Hi Steve,

It's fantastic that you've taken the time to look at this. Thank you!

> Well I've now done my homework... I read through the ICMC paper and have
> been actively reading over the source code for libIntegra.  I think I
> have a much better understanding now, but there are things that are
> still unclear.  It's a big task to get up to scratch on this work, so to
> keep things in perspective I've been keeping my current job in mind,
> which is to ensure that the routing GUI will be usable for looking at
> modules and making connections between them.

Sounds like a good strategy.

> If I understand correctly, an ntg_instance has an array of connections,
> each which points to a module's port number.

Yes.

> I was confused for a while
> between the words "port" and "attribute", but I think I have this sorted
> now.. ports are implicitly defined by a module's attributes.

That's right. I've just updated the glossary
(http://www.integralive.org/dokuwiki/doku.php/glossary) to hopefully
explain this. Basically, ports are used to store connections, attributes
are used to store 'current state'.

>  By the
> way, is there a missing "n_connections" member?

Yes. I just added it. Thanks for spotting that.

> For GUI development then, I'll continue to refer to the libIntegra code,
> making the assumption that the "bridge" will eventually provide methods
> for enumerating modules, attributes, and instances, and getting and
> setting attributes, enumerating connections between ports, etc.  (I may
> very well contribute to building this bridge, but for the moment it's
> probably more important to get a functioning GUI using the storage stub.)

I agree. There is a semi-functioning integra_max_bridge in
trunk/bridges/Max. It basically works, but the hidden patcher that stores
the modules doesn't get the "DSP" message. However, for the first
libIntegra release I had it in mind that we could use Pd (in no-gui mode)
as the engine. This would at least enable you test your system with a
working engine...

> I'd like to ensure that the OSC messages internally used in the GUI will
> be as close as possible to the terminology and structure of libIntegra.
> So far this unfortunately hasn't really been the case, imho, but we'll
> improve it in the coming weeks.

Are you talking about the addresses for loading, connecting, removing
modules etc? e.g.
http://www.integralive.org/dokuwiki/doku.php/lib:comms#the_library

... I didn't spend a massive amount of time working this out, so if you
have another suggestion, just update the wiki, or add a new section
"proposed commands" or whatever..

If you want to discuss it, perhaps we can arrange an IRC meeting.

> A last question: it seems like the "instances" in the database are
> basically in a big soup, so that a "piece" is really just a collection
> of specific instances that exist amidst all the other instances, all
> serialized flatly to one giant database.  Is this correct?  So when the
> GUI creates an instance, this will filter through the bridge and
> instance host to eventually become a CREATE call to a PostgreSQL table.

In the first case the data is represented locally as XML. The mechanism
for storing the module collection for a given piece (the equivalent of a
top-level Max patch) is the "Integra collection" file
(http://www.integralive.org/dokuwiki/doku.php/lib:collections). This is
essentially a collection of module instances.

Eventually this gets added to the database using an INSERT query. Table
fields represent attributes, rows represent instance data (i.e. saved
attribute state). Collections have a separate table, which holds the
connections (ids of source and target instances). The schema for
collections hasn't been deivised yet, so I can't tell you much more about
it.

> A piece of music then is basically defined by a list of instance IDs?  I
> hope my question is clear.

That is basically correct. The IDs also include documentation, setup
instructions, audio files, SDIF, other resources.

> I'm sure I'll have further questions but I'll defer until I've distilled
> all this information a little more.  Sorry if this email seems a bit
> all-over-the-place.
>
>

Not at all.

best,

Jamie