| 1 |
capela |
103 |
/** |
| 2 |
|
|
|
| 3 |
|
|
@mainpage liblscp |
| 4 |
|
|
|
| 5 |
|
|
|
| 6 |
|
|
@section Intro |
| 7 |
|
|
|
| 8 |
|
|
Hi all, |
| 9 |
|
|
|
| 10 |
|
|
On the path to a GUI for linuxsampler, I've been taking some of my spare |
| 11 |
|
|
time by writing an early implementation for the LSCP (the LinuxSampler |
| 12 |
|
|
Control Protocol), as defined from the current available draft document |
| 13 |
capela |
144 |
(http://www.linuxsampler.org/api/draft-linuxsampler-protocol-11.pdf). |
| 14 |
capela |
103 |
|
| 15 |
|
|
My implementation, while still rather crude, is taking the form of a |
| 16 |
|
|
programming library for plain conventional C, codenamed liblscp. |
| 17 |
|
|
|
| 18 |
|
|
One of my objectives is that liblscp evolves as the implementation for a |
| 19 |
|
|
linuxsampler API, while being a fair abstraction for the network and/or |
| 20 |
|
|
IPC aspects of LSCP. |
| 21 |
|
|
|
| 22 |
|
|
For the facts, liblscp is actually a wrapper for the LSCP specification, |
| 23 |
|
|
taking all the TCP/UDP socket communication into it's main control, hiding |
| 24 |
|
|
all or some of the protocol bureoucracy from the user and exposing a |
| 25 |
|
|
simple and opaque C programming language interface, mainly by mapping |
| 26 |
|
|
events to user function callback handlers. |
| 27 |
|
|
|
| 28 |
|
|
The design of liblscp assumed that the programming interface provided is |
| 29 |
|
|
useable and applicable either for server (linuxsampler itself) and/or |
| 30 |
|
|
client (gui's) development. |
| 31 |
|
|
|
| 32 |
|
|
Some design features (no rocket-sci here :) |
| 33 |
|
|
|
| 34 |
|
|
- Multi-threaded or multiplexed server; clients block for synchronous |
| 35 |
|
|
request calls. |
| 36 |
|
|
- Multi-client; one server instance serves many clients, local and/or |
| 37 |
|
|
remote. |
| 38 |
|
|
- Server events broadcasted and delivered to client callbacks. |
| 39 |
|
|
- Client requests processed on server supplied callback. |
| 40 |
|
|
|
| 41 |
|
|
Please note that (as usual :) documentation is none at this stage but I'll |
| 42 |
|
|
challenge you to look at the source code provided on the tarball below. A |
| 43 |
|
|
barebones server and client test programs are included (lscp_server_test |
| 44 |
|
|
and lscp_client_test). |
| 45 |
|
|
|
| 46 |
|
|
|
| 47 |
|
|
@section Client |
| 48 |
|
|
|
| 49 |
|
|
As a quick reference for the client programming, one links to liblscp to |
| 50 |
|
|
create a client instance handle, just like this:<pre> |
| 51 |
|
|
|
| 52 |
|
|
#include <lscp/@ref:client.h> |
| 53 |
|
|
|
| 54 |
|
|
@ref lscp_client_t *client; |
| 55 |
|
|
|
| 56 |
|
|
client = @ref lscp_client_create (server_host, server_port, |
| 57 |
|
|
client_callback, client_data); |
| 58 |
|
|
|
| 59 |
|
|
</pre>where server_host is the hostname of the server we wish to connect, and |
| 60 |
|
|
server_port is the respective port number; client_callback is the client |
| 61 |
|
|
supplied callback function that will handle every server notification |
| 62 |
|
|
event; client_data is intended for client context and will be fed to |
| 63 |
|
|
client_callback without intervention. |
| 64 |
|
|
|
| 65 |
|
|
The client may issue a request to server by use of:<pre> |
| 66 |
|
|
|
| 67 |
|
|
@ref lscp_client_query (client, query); |
| 68 |
|
|
|
| 69 |
|
|
</pre>where you'll submit a single command to the server and wait for it's response. |
| 70 |
|
|
The query string must be null terminated. The server response result maybe |
| 71 |
|
|
retrieved by:<pre> |
| 72 |
|
|
|
| 73 |
|
|
char *result; |
| 74 |
|
|
|
| 75 |
|
|
result = @ref lscp_client_get_result(client); |
| 76 |
|
|
|
| 77 |
|
|
</pre>and the eventual error status code:<pre> |
| 78 |
|
|
|
| 79 |
|
|
int errno; |
| 80 |
|
|
|
| 81 |
|
|
errno = @ref lscp_client_get_errno(client); |
| 82 |
|
|
|
| 83 |
|
|
</pre>The client callback function must have the following prototype (@ref lscp_client_proc_t): |
| 84 |
|
|
|
| 85 |
|
|
- @ref lscp_status_t <i>client_callback</i> ( @ref lscp_client_t *client, |
| 86 |
capela |
156 |
@ref lscp_event_t event, const char *buf, int buflen, void *client_data ); |
| 87 |
capela |
103 |
|
| 88 |
capela |
156 |
where event is the specific event type notification, buf will be a pointer to |
| 89 |
|
|
the event text which is buflen bytes in length; client_data is exactly the same |
| 90 |
|
|
value given on @ref lscp_client_create call. |
| 91 |
capela |
103 |
|
| 92 |
|
|
This callback function is the place to handle all server notifications and |
| 93 |
|
|
will be only called if the client is currently subscribed. No response |
| 94 |
|
|
from the client is expected while processing an event within |
| 95 |
|
|
client_callback. |
| 96 |
|
|
|
| 97 |
capela |
156 |
A client subscribes to receive event notifications by calling:<pre> |
| 98 |
capela |
103 |
|
| 99 |
capela |
156 |
@ref lscp_client_subscribe (client, events); |
| 100 |
capela |
103 |
|
| 101 |
|
|
</pre>after which it will start receiving events by means of the supplied |
| 102 |
|
|
client_callback function. To unsubscribe and stop this deliverance:<pre> |
| 103 |
|
|
|
| 104 |
capela |
156 |
@ref lscp_client_unsubscribe (client, events); |
| 105 |
capela |
103 |
|
| 106 |
|
|
</pre>Finally, when a client is about to quit, the proper terminator is in order:<pre> |
| 107 |
|
|
|
| 108 |
|
|
@ref lscp_client_destroy (client); |
| 109 |
|
|
|
| 110 |
|
|
</pre>As for the current protocol draft (04), the client interface already maps |
| 111 |
|
|
the following functions defined in "@ref lscp_client.h", one for each corresponding |
| 112 |
|
|
LSCP comand:<pre> |
| 113 |
|
|
|
| 114 |
|
|
@ref lscp_get_available_engines (client); |
| 115 |
|
|
@ref lscp_get_engine_info (client, engine_name); |
| 116 |
|
|
@ref lscp_get_channels (client); |
| 117 |
|
|
@ref lscp_add_channel (client); |
| 118 |
|
|
@ref lscp_load_engine (client, engine_name, channel); |
| 119 |
capela |
156 |
@ref lscp_set_channel_audio_device (client, channel, audio_device); |
| 120 |
capela |
103 |
@ref lscp_set_channel_audio_type (client, channel, audio_type); |
| 121 |
capela |
156 |
@ref lscp_set_channel_audio_channel (client, channel, audio_in, audio_out); |
| 122 |
|
|
@ref lscp_set_channel_midi_device (client, channel, midi_device); |
| 123 |
|
|
@ref lscp_set_channel_midi_type (client, channel, midi_type); |
| 124 |
|
|
@ref lscp_set_channel_midi_port (client, channel, midi_port); |
| 125 |
capela |
103 |
@ref lscp_set_channel_midi_channel (client, channel, midi_channel); |
| 126 |
|
|
@ref lscp_set_channel_volume (client, channel, volume); |
| 127 |
|
|
@ref lscp_load_instrument (client, file_name, instr_index, channel); |
| 128 |
capela |
156 |
@ref lscp_load_instrument_non_modal (client, file_name, instr_index, channel); |
| 129 |
capela |
103 |
@ref lscp_get_channel_info (client, channel); |
| 130 |
|
|
@ref lscp_get_channel_voice_count (client, channel); |
| 131 |
|
|
@ref lscp_get_channel_stream_count (client, channel); |
| 132 |
|
|
@ref lscp_get_channel_buffer_fill (client, usage_type, channel); |
| 133 |
|
|
@ref lscp_reset_channel (client, channel); |
| 134 |
|
|
@ref lscp_remove_channel (client, channel); |
| 135 |
|
|
|
| 136 |
|
|
</pre>All these functions are wrappers to @ref lscp_client_query, and some will handle |
| 137 |
|
|
and change the result string accordingly. |
| 138 |
|
|
|
| 139 |
|
|
|
| 140 |
|
|
@section Server |
| 141 |
|
|
|
| 142 |
|
|
Likewise, and least important yet as for server programming, you create a server |
| 143 |
|
|
instance handle just like that:<pre> |
| 144 |
|
|
|
| 145 |
|
|
#include <lscp/@ref:server.h> |
| 146 |
|
|
|
| 147 |
|
|
@ref lscp_server_t *server; |
| 148 |
|
|
|
| 149 |
|
|
server = @ref lscp_server_create (server_port, server_callback, server_data); |
| 150 |
|
|
|
| 151 |
|
|
</pre>where server_port is the port number where the server will be |
| 152 |
|
|
listening for connections; server_callback is the server supplied |
| 153 |
|
|
callback function that will handle every client request; server_data is |
| 154 |
|
|
any reference to data that will be fed into server_callback without |
| 155 |
|
|
modification. |
| 156 |
|
|
|
| 157 |
|
|
The server callback function prototype is very similar to the client one |
| 158 |
|
|
(@ref lscp_server_proc_t): |
| 159 |
|
|
|
| 160 |
|
|
- @ref lscp_status_t <i>server_callback</i> ( @ref lscp_connect_t *conn, |
| 161 |
|
|
const char *request, int reqlen, void *server_data ); |
| 162 |
|
|
|
| 163 |
|
|
where conn is just a client connection handle, that shall be used for the |
| 164 |
|
|
server responses; the request text which has a length of reqlen bytes; |
| 165 |
|
|
server_data is the same value given on lscp_server_create. |
| 166 |
|
|
|
| 167 |
|
|
There's two special server callback cases, flagged by a null request pointer |
| 168 |
|
|
and described with reqlen as a boolean value: when zero it announces a new |
| 169 |
|
|
client connection, otherwise it tells that a client connection has closed. |
| 170 |
|
|
|
| 171 |
|
|
While handling each request the server must cook it's response and |
| 172 |
|
|
eventually issue the following:<pre> |
| 173 |
|
|
|
| 174 |
|
|
@ref lscp_server_result (conn, result, reslen); |
| 175 |
|
|
|
| 176 |
|
|
</pre>where conn is the client handle, and result is a pointer to the server |
| 177 |
|
|
response literal text of reslen bytes. Of course the response shall obey |
| 178 |
|
|
to the protocol specification. |
| 179 |
|
|
|
| 180 |
|
|
The server issues a broadcast to its subscribers by simply issuing:<pre> |
| 181 |
|
|
|
| 182 |
|
|
@ref lscp_server_broadcast (server, buf, buflen); |
| 183 |
|
|
|
| 184 |
|
|
</pre>which will trigger the client callback function, which will be fed with an |
| 185 |
|
|
exact copy of buf/len; this is the intended way to deliver all |
| 186 |
|
|
notifications to each subscribed client. |
| 187 |
|
|
|
| 188 |
|
|
When its time to shutdown the server instance, just don't forget to call |
| 189 |
|
|
the server destructor:<pre> |
| 190 |
|
|
|
| 191 |
|
|
@ref lscp_server_destroy (server); |
| 192 |
|
|
|
| 193 |
|
|
</pre>and we're done with the server. |
| 194 |
|
|
|
| 195 |
|
|
|
| 196 |
|
|
@section Outro |
| 197 |
|
|
|
| 198 |
|
|
Nuff said. If you care or dare, track the revolving under: |
| 199 |
|
|
|
| 200 |
|
|
- http://www.rncbc.org/ls/ |
| 201 |
|
|
|
| 202 |
|
|
Please note that the code is known to compile and run on Linux AND on |
| 203 |
|
|
win32 (!). On Linux the main target is a shared library (liblscp.so) so |
| 204 |
|
|
remember to set your LS_LIBRARY_PATH accordingly before running the test |
| 205 |
|
|
programs. |
| 206 |
|
|
|
| 207 |
|
|
A final disclaimer goes to the fact that I AM NOT a socket nor thread |
| 208 |
|
|
programming guru, whatsoever. So fundamental mistakes may be lying around, |
| 209 |
|
|
somewhere. Besides that ItJustWorks(tm:). |
| 210 |
|
|
|
| 211 |
|
|
I'm eager to hear your feedback and comments. As usual, destructive |
| 212 |
|
|
criticism will be sent to /dev/null ;) |
| 213 |
|
|
|
| 214 |
|
|
Hope to be on the right track, and towards linuxsampler integration. |
| 215 |
|
|
|
| 216 |
|
|
Otherwise sorry for the bandwidth waste. |
| 217 |
|
|
|
| 218 |
|
|
Cheers. |
| 219 |
|
|
|
| 220 |
|
|
rncbc aka Rui Nuno Capela |
| 221 |
|
|
rncbc@rncbc.org |
| 222 |
|
|
|
| 223 |
|
|
@see http://www.linuxsampler.org |
| 224 |
|
|
|
| 225 |
|
|
*/ |
Parent Directory
| 
Revision Log