[Dev] XML parsing functionality in the GUI

[Henrik Frisk]

> >
> > With regard to what I said previously about the translation path: XML ->
> OSC -> Max
> >
> > We should remember that the "OSC -> Max" part would be pretty trivial,
> so don't let that necessarily stop us from using it if it seems like a
> good idea.
> >
Agreed.

> > As Jamie said, only the "master" will have to deal with XML.  I would
> actually argue however that the DSP engine should be the master.
> >
> 
> I think the library should be designed in such a way that it is fairly
> straightforward to have either the GUI or the engine as master. However,
> the more I think about it, having the engine as master does seem sensible
> for the reasons you state below.
> 
> > In that case, the GUI's job is to dynamically send "create", "destroy",
> and "connect" messages to the DSP engine for instantiating and
> > connecting modules.  However, the DSP engine is the one actually doing
> the saving and loading of the current "state" into the XML file.  In
> that case, the GUI would simply sit there as a "dumb terminal", and the
> DSP engine would be responsible for telling it what to do.
> >
The library is doing the saving and loading of modules, either on
request from a user in real time or by reading an XML file (see below)

> > This is how PureData works, and it seems to be a successful paradigm.
> One argument is that the DSP will sometimes need to function without a
> GUI, so being able to load XML by itself is necessary, while the
> converse isn't true.
> >
> 
> That's why I proposed the 'standalone' mode
> (http://www.integralive.org/dokuwiki/doku.php/lib:comms), right at the
> bottom :-)
> 
> Actually it was pd -nogui that made me think of this mode.
> 
Except we also have to worry about format conversion between different
engines and dispatching messages to the right locations.

> > One alternative we might consider is a 3rd-process application, some
> sort of "Integra manager", that sits in between the GUI and DSP to deal
> with module-level"connections, and saving/loading/database stuff.  It
> could keep its own internal representation of the module network, and be
> responsible for ensuring that all GUI and engine instances are in the
> correct state.
> >
> > In any case, if both the GUI and DSP engine are designed to act as
> "slaves", then we can embed this "master" application into either side
> as we see fit.  Writing it as a separate process might make for easier
> development in the meantime.
> >
> > In short:
> >
> >     DSP <-osc-> Manager(XML) <-osc-> GUI
> >                     |
> >                 Db Server
> >
> >
> > Where "Manager" either runs on its own, or is embedded into DSP or GUI,
> possibly both (as long as only one is enabled).  At least implementing
> this OSC layer should allow us to move around this "manager" layer more
> easily if we want to.
> >
> >
> I absolutely agree with all of this. With the scenario above, we could
> have many nodes attached to the Manager, all implemented 'inside'
> different DSP environments, which is really something Integra strives for.
> 
Well, this is exactly how I've imagined the functionality of the
library. What is the need for a separate application to handle this? To
enable standalone mode we only need to write a binary that links to the
library - a simple CLI from which you can load ready made collections
and make adjustments to them with the same OSC-like syntax we're using
for the GUI->library communication. What we may want to do, as Jamie has
already proposed, is to have separate libraries to handle the different
tasks. So far we have the libIntegraXml and libIntegraManager (that
isn't a great name...) and perhaps libIntegraOsc?

While working on the tests for the library (see the svn:
library/branches/dev/inheritance-test/) here's how I imagine the
'manager' to create it's own representation of the current collection:

List<Classes>  List<instnce>  List<attr>   Linked<conn>

Slider	 ->    slider	 ->   pos   ->     f-ptr->listener

Each collection stores a LinkedList with the Integra classes used (this
could go away if we decide on a good way to handle dynamic
instantiation). Each class object holds a linked list of all the
instances. Each instance holds a linked list of all its attributes. Each
attribute holds a linked list of all its connections (in another
terminology, if the frequency of an oscillator is controlled by a
slider, the frequency attribute of the osc registers a listener with the
pos attribute of the slider). The connections are however handled
through a proxy object that deals with necessary format conversions and
up/down sampling. The connection object also holds information of the
location and environment for the DSP objects and the GUI objects and
makes sure the messages are dispatched in the correct way.

Now, as far as the Max external in the GUI the mapping between the GUI
widgets (the slider on the screen) could also be handled by means of
connection proxies. If the user creates a new Slider the message 

/new Slider slider

is sent to the external. If the Class 'Slider' is already loaded it
makes a copy of itself and adds it to the end of the list of instances,
else it (down)loads the class specification and creates the Integra
Class object, creates a new connection proxy that stores a pointer to
itself in the list of connections within the slider's pos attribute and
returns a pointer to the connection proxy object. DSP objects in the
engine(s) are registered in the same manner.

Finally, for the real-time performance data, the connections objects are
also responsible for tracking and maintaining the current status of all
the parameter data. The notion of the player (which is actually the
connections object), the ensemble (a module containing connection
objects) and the conductors fits well into this model.

Alright, this thread has maybe gotten a little out of hand, but, I felt
it was the right time to sare these thoughts with you since it's highly
relevant to the current discussion and since I needed to write it
down. I'm sure there's a million loop holes in my reasoning, but it has
an element of design consistency that I like. And, in this scenario, we
can actually do without XML handling in the GUI. Saving a collection is
'only' a matter of serializing the current status of the library
(manager?). 

> The only thing that I would add is that nodes registering with the Integra
> Manager (service?), should still 'contain' a client that links to the 
> Integra lib. I think this is the best design for providing
> functionality for module instantiation, which as a minimum, means the
> ability to parse module definitions (XML), and the mechanism to translate
> these into environment-native form, and to receive commands via OSC. Doing
> it this way (using the lib in each node including the server), makes the
> system more homogeneous/maintainable/scalable I think.
> 
Yes! 

/Henrik