So I had another small look at liblo and the dssi plugins. Here's what I
gathered, correct me if I'm wrong:
* The host creates a server_thread and attahces methods to it, which change
engine paameters according to incoming lo_sends.
* But the engine itself must use lo_send, when it updates parameters due to
new patches loaded or other sources of outside control, right?
* The client also should have a thread connected to the server, so it can
updates and changes based on engine/server changes
* The client must have other methods attached to it - if that is possible -
to just change the display of the UI.
* the client must lo_send user-changes to the server.
Did I basically get this right? I've seen no way to query the lo_server for
existing paths or types of certain nodes.
So paths and types must be included in a description file.
One node (OSC parameter) can have several values attached, these can be of
different types (float, int, string,...). To make sense, they have to be in
the order determined by the Engine developer.
So for the UI/client side one must first somehow find or be given the
server-adress, read the description file, build the tree structure. Then one
must send out a message to the server, that one would like to have current
info on all the nodes. So the engine can go through its internal values (the
real thing) and lo_send each parameter again/or for the first time.
This will mean, that we have at least one OSC-path for internal
server/client communication. It wouldn't need to be standardised, but it might
be nice. You can always put that "query_all" path into the description file as
Did I miss anything important for a start?
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
Linux-audio-user mailing list