[Dev] Henrik Frisk: Re: connections
Stephen Sinclair
sinclair at music.mcgill.ca
Wed Oct 3 15:54:00 BST 2007
> You're probably thinking of module definitions. The actual definition is
> stored in the global module definitions table, and a new table is
> created to hold the module's instance data.
>
Sorry I probably confused you with my "CREATE" suggestion in the last
email. It was late last night and I'd spent the entire day staring at
source code of one form or another... I haven't done SQL since my
undergrad. ;-)
I really did mean INSERT, I swear.
Thanks for your replies, I'm currently absorbing them.
However I'll just take the opportunity to ask a question now that I've
slept on it...
Assume a GUI module (say, slider) is instantiated. I am guessing that
this module should then be actually represented in two instance_hosts.
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.
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?) 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? 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? How do "subattributes" come
into play here?
cheers,
Steve
More information about the Dev
mailing list