Hello!
I should have
mentioned here that of course you also have a
"user_data" variable available for the callbacks. So you can register
the same callback function for several faders but differentiate them
by sending a different pointer or index in the user_data variable for
each fader.
Do you mean "fader <index> <value>" or "/fader
<some_blob> <value>". Both
would work for separating gui/core but the second one makes it impossible to
use other osc-apps (like pd/etc.)...
No, sorry I didn't mean to imply <some_blob>. The "user_data"
variable is only what is registered with the callback, it is not sent
in the OSC stream. But it allows you to use the same block of code to
process several messages. (Or, rather, the same message for several
objects, without having to parse the path yourself.)
For example, if you have several instances of some object type Fader,
you could do:
Fader fader[3];
lo_server_add_method("/fader/1/position","f",my_callback,&fader[0]);
lo_server_add_method("/fader/2/position","f",my_callback,&fader[1]);
lo_server_add_method("/fader/3/position","f",my_callback,&fader[2]);
Then when the message is received: "/fader/3/position 2.4", the
callback my_callback would be called with user_data set to the address
of fader[2]. It has nothing to do with blobs, it only allows you to
register your callback with some context information. Most callback
systems support something like this.
Steve