[Dev] XML parsing functionality in the GUI

Stephen Sinclair stephen.sinclair at mail.mcgill.ca
Tue Mar 20 14:24:34 GMT 2007


> I think that for now, the GUI should use Steve's javascript approach, but
> on the basis that at some point this will be replaced by libIntegra.
>   

Just keep in mind here that we're only talking about a difference 
between one programming language and another.  As far as I'm concerned 
there's nothing inherently "better" about doing it in Max's javascript 
vs. programming an external that calls to libIntegra.  If we can avoid 
duplicating effort then it's a better solution.  Not to mention that 
javascript will never be able to make database queries.


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.

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.

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.

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.

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.


Steve
ps. I've moved this discussion onto the dev list.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://integralive.org/pipermail/dev_integralive.org/attachments/20070320/16bf7691/attachment.html 


More information about the Dev mailing list