[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