Alfons Adriaensen wrote on Thu, 12-May-2005:
- There will be one UDP server socket. This socket is
left
unconnected, and will receive OSC commands from any source.
These commands give you complete control over most aspects
of Aeolus (excluding the stop definition editor which will
remain in the local GUI only).
Have you considered process separation for the engine and the
"local GUI" ? At least an option to run aeolus with no gui/x.
/addclient ,s host:port and
/remclient ,s host:port
Registered clients can request information (e.g. a list of all
available stops), and will receive notification of everything
that may affect a user interface, again by UDP messages to
their port of choice. They will still send all their commands
to the unique server port above. Second question: is this a
good idea, or would it be better to create a TCP connection
for this type of client ?
This is similar to how SooperLooper and Om handle bidirectional
OSC communication. SL has both the concept of single request
return values (by taking a return URI and osc path as arguments
in the request) and the concept of clients registering themselves in the
engine for changes to specific values, and for autoupdating of
values that continuously change. My register calls usually take
a URI and an osc path that will be used for the callback message
(with predetermined arguments).
It seems to work fairly well, I like the idea of all communications
using the same mechanism.
jlc