[Dev] Henrik Frisk: Re: connections

[Henrik Frisk]

Forgot to 'reply all' on this...

------- Forwarded Message

From: Henrik Frisk <mail at henrikfrisk.com>
To: Stephen Sinclair <sinclair at music.mcgill.ca>
Subject: Re: [Dev] connections 
In-reply-to: <47030330.6080109 at music.mcgill.ca> 
References: <47030330.6080109 at music.mcgill.ca>
Comments: In-reply-to Stephen Sinclair <sinclair at music.mcgill.ca>
   message dated "Tue, 02 Oct 2007 22:49:20 -0400."
X-Mailer: MH-E 8.0.3; nmh 1.1; GNU Emacs 21.4.1
Date: Wed, 03 Oct 2007 10:38:04 +0200
Message-ID: <16033.1191400684 at henrikfrisk.com>
Sender: henrikfr at henrikfrisk.com

Hi Stephen,

Thanks for your email. It's very good you took this initiative to bring
GUI and library efforts in sync.

Stephen Sinclair <sinclair at music.mcgill.ca> wrote:

> Hi,
> 
> 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.
> 
> If I understand correctly, an ntg_instance has an array of connections, 
> each which points to a module's port number.  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.  By the 
> way, is there a missing "n_connections" member?
> 
Hmmm, let's wait for Jamie's response on this. Immediately, I'm not sure
it's needed, but I'm probably wrong. Concerning port/attribute, I guess
this may seem confusing. A port is a result of a module having an attribute.

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

Sounds sensible.
> 
> 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.
> 
If you have questions or suggestions please put them forward. There is
no reason, in certain cases, why terminology in the library can't
change, unless, of course, it's central to the way things are designed.
 
> 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.
> 
> A piece of music then is basically defined by a list of instance IDs?  I 
> hope my question is clear.
>
I'm not sure I understand your question, but there's a distinction to be
made between an 'instance' of a module definition that may be stored as
part of a 'collection' in the database with time based data (presets
etc) attached to it and an 'instance' of a module that is 'instantiated'
in an intance host. When the GUI creates an instance of a module its
definition should be read and exists within the library. It isn't until
the user 'stores' or 'saves' the instance that it is being serialized
and stored in the database, now as part of a collection (even if this
collection only holds one (1) module) with its current state. If I
remeber correctly this operation results in the creation of a new table
in the database.

Again, I may have completely misunderstood your question.

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

/henrik f
------- End of Forwarded Message