Menu
▾
▴
linuxsampler-devel
|
From: Christian S. <chr...@ep...> - 2004-01-07 20:41:58
|
Hi!
I updated the protocol document:
http://www.linuxsampler.org/api/draft-linuxsampler-protocol-02.pdf
http://www.linuxsampler.org/api/draft-linuxsampler-protocol-02.sxw
Changes:
- the response of LS on a successful subscription of the frontend with
"SUBSCRIBE NOTIFICATION" now looks like this:
"OK[<session-id>]"
- the command for unsubscribing the frontend now looks like that:
"UNSUBSCRIBE NOTIFICATION <session-id>"
Parameter <session-id> is not optional.
As demanded, I also added these links to the "Downloads" section on the
LinuxSampler webpage today:
http://www.linuxsampler.org/downloads.html
CU
Christian
|
|
From: Vladimir S. <ha...@so...> - 2004-01-08 01:50:06
|
Hi Christian, Everybody!
I'm so glad i found linuxsampler project. My thanks to everybody for making
this great idea a reality.
I am a software engineer now (or at least i was able to trick some
co-workers into thinking that i am :) but i was raised in a family of
musicians and had to play the piano for about 8 hours a day since i was 6
till about 17 so i can still play a little . . .
And now i can play in Linux! Sampler was one of the last apps i needed
windows for. Now i'm almost 100% linux :)
Anyway, long story short the only thing that i didn't enjoy about linux
sampler was that clicking noise that results from no release sample support,
so i've decided to try to do something about it.
I'd like to help out on this project (if i can).
Unfortunately, my coding experience is all in embedded and networking and
not at all in audio so my attempt to solve the clicking problem is more of a
research or an ugly hack that probably has no long term value. That's why i
don't want to send it as a patch but just as a proof of concept, something
to discuss, etc.
Anyway, what i did was:
1) added a private float to class Voice (i called it "Releasing" for lack of
imagination)
it's not actually going to be a float.
2) set that to 0 in the constructor
3) in Voice::RenderAudio() i added this at the beginning:
if (Releasing > 0.9999) {
Releasing = 0;
PlaybackState = playback_state_end;
}
4) added a method to voice class: void Release() { Releasing = 0.000001; }
again, please disregard these weird constants for now.
5) in AudiThread::ReleaseVoice() replaced pVoice->Kill() with
pVoice->Release() just like the comment said. For now i also put return;
right after that but that needs to be implemented correctly.
6) in both stereo and mono Interpolate inline functions, i've added the
following:
effective_volume = effective_volume - (effective_volume *
(Releasing/128));
Releasing = sqrt(Releasing);
sqrt and division by 128 are just here for proof of concept code. they will
not actually be needed.
Releasing doesn't need to be float either. there can just be a precalculated
array and Releasing could be an index in such array and effective volume
could be adjusted based on the value in that array. This way there will be
no need for any conditional stuff in tight loops either.
The point of that code was again just to see if something simple like this
could actually sound OK.
And you know . . . IMHO it does. I have pretty good hearing, pretty good
headphones and i can't hear any clicking at all.
I've compared it to GS and i can't really tell the difference (at least not
with the samples i have).
I've played using a few different samples, with and without sustain, mostly
mono, mostly Soeren Bovbjerg's Steinway sample.
Christian, I think you've asked a while ago somewhere on usenet about free
piano samples. This one is free and IMHO pretty good.
If you don't have it yet, check it out:
http://www.musik.auc.dk/~bovbjerg/piano4.html
CPU utilization on my old 850Mhz Athlon did not seem to change much either
even though it was doing lots of sqrt()s :)
I'd like to know what the pros think about this simple method. So shoot, but
please don't kill.
On the other hand . . . kill, why not? :)
If this was already discussed and decided upon, please don't kick too hard .
. .
About sustain . . . you probably already know this, but anyway. I'm not sure
what the right terminology for this is, but when i quickly release and apply
sustain right back in GS what i get is the sound is still alive. Just like a
real piano. Not in LS though :( As soon as i release the sound is dead. It
may sound insignificant but when you play certain peices like one of
Rachmaninov's preludes or for instance where sustain is used a lot you don't
get the same realistic feel that you do with gs.
What do you guys think?
Regards,
Vladimir.
|
|
From: Mark K. <mar...@co...> - 2004-01-08 02:31:41
|
Vladimir,
Ah, you are definitely the high point of my day! It's great to have
another person here working on the code and making LS sound better. Even
better is that you have access to GSt so we can compare notes. (It
sounds like you are a better keyboardist than I which will help also!)
I think that I'd love to try out your release sample patches when you
are ready. However, release samples are only part of the click and pop
problem. Since many gig files do not have release samples there needs to
be some sort of envelope placed on the signal being played, taking its
value down to 0 at a known rate, to eliminate all of the clicks.
I don't know the term for double clutching the sustain pedal, and
actually I hadn't noticed this before, so there is certainly something
there we need to look into.
I'll need to think a bit about your general math ideas for doing the
release. I'm a bit tired this evening, but I'm not clear how you are
varying the energy of the release sample based on what the current
volume of the playing sample is? I.e. - If you play a loud note, and
then release fairly quickly, to move cleanly into that note we have to
do nothing to that release sample. However, if you play a sustained
piano note, but wait 10 seconds before releasing, do we not need to do
something to make it fit cleanly together? I'm not sure, but I had
thought so.
Anyway, very good to have you here and I look very forward to trying
out your patches.
Cheers,
Mark
On Wed, 2004-01-07 at 17:48, Vladimir Senkov wrote:
> Hi Christian, Everybody!
>
> I'm so glad i found linuxsampler project. My thanks to everybody for making
> this great idea a reality.
> I am a software engineer now (or at least i was able to trick some
> co-workers into thinking that i am :) but i was raised in a family of
> musicians and had to play the piano for about 8 hours a day since i was 6
> till about 17 so i can still play a little . . .
> And now i can play in Linux! Sampler was one of the last apps i needed
> windows for. Now i'm almost 100% linux :)
>
> Anyway, long story short the only thing that i didn't enjoy about linux
> sampler was that clicking noise that results from no release sample support,
> so i've decided to try to do something about it.
> I'd like to help out on this project (if i can).
> Unfortunately, my coding experience is all in embedded and networking and
> not at all in audio so my attempt to solve the clicking problem is more of a
> research or an ugly hack that probably has no long term value. That's why i
> don't want to send it as a patch but just as a proof of concept, something
> to discuss, etc.
> Anyway, what i did was:
> 1) added a private float to class Voice (i called it "Releasing" for lack of
> imagination)
> it's not actually going to be a float.
> 2) set that to 0 in the constructor
> 3) in Voice::RenderAudio() i added this at the beginning:
> if (Releasing > 0.9999) {
> Releasing = 0;
> PlaybackState = playback_state_end;
> }
> 4) added a method to voice class: void Release() { Releasing = 0.000001; }
> again, please disregard these weird constants for now.
> 5) in AudiThread::ReleaseVoice() replaced pVoice->Kill() with
> pVoice->Release() just like the comment said. For now i also put return;
> right after that but that needs to be implemented correctly.
> 6) in both stereo and mono Interpolate inline functions, i've added the
> following:
> effective_volume = effective_volume - (effective_volume *
> (Releasing/128));
> Releasing = sqrt(Releasing);
> sqrt and division by 128 are just here for proof of concept code. they will
> not actually be needed.
> Releasing doesn't need to be float either. there can just be a precalculated
> array and Releasing could be an index in such array and effective volume
> could be adjusted based on the value in that array. This way there will be
> no need for any conditional stuff in tight loops either.
>
> The point of that code was again just to see if something simple like this
> could actually sound OK.
> And you know . . . IMHO it does. I have pretty good hearing, pretty good
> headphones and i can't hear any clicking at all.
> I've compared it to GS and i can't really tell the difference (at least not
> with the samples i have).
> I've played using a few different samples, with and without sustain, mostly
> mono, mostly Soeren Bovbjerg's Steinway sample.
> Christian, I think you've asked a while ago somewhere on usenet about free
> piano samples. This one is free and IMHO pretty good.
> If you don't have it yet, check it out:
> http://www.musik.auc.dk/~bovbjerg/piano4.html
> CPU utilization on my old 850Mhz Athlon did not seem to change much either
> even though it was doing lots of sqrt()s :)
> I'd like to know what the pros think about this simple method. So shoot, but
> please don't kill.
> On the other hand . . . kill, why not? :)
> If this was already discussed and decided upon, please don't kick too hard .
> . .
>
> About sustain . . . you probably already know this, but anyway. I'm not sure
> what the right terminology for this is, but when i quickly release and apply
> sustain right back in GS what i get is the sound is still alive. Just like a
> real piano. Not in LS though :( As soon as i release the sound is dead. It
> may sound insignificant but when you play certain peices like one of
> Rachmaninov's preludes or for instance where sustain is used a lot you don't
> get the same realistic feel that you do with gs.
> What do you guys think?
>
> Regards,
> Vladimir.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
|
|
From: Mark C. <ma...@re...> - 2004-01-08 02:55:12
|
> > http://www.musik.auc.dk/~bovbjerg/piano4.html Glug. Sorry to be boring but would anyone have a plain uncompressed linux-friendly version of any of these files available online somewhere, particluarly the gig ? --markc |
|
From: <be...@ga...> - 2004-01-08 10:45:03
|
the sfArk decompression utility (for Windows) works without any problem under Linux using Wine. download the sample in .sfark format. download SfArk from http://www.melodymachine.com/sfark.htm wine sfark_setup.exe and then use the application's filedialog to load and decompress the file. easier than that ? :-) Anyway those samples are in SF2 format so for now of little use for LinuxSampler. BTW in my post about the Sample Library producers I forgot to say that those that will come at NAMM agreed to give us a few free sampling CDs that LinuxSampler developers can use for development and testing purposes. Very nice ! cheers, Benno http://www.linuxsampler.org Scrive Mark Constable <ma...@re...>: > > > http://www.musik.auc.dk/~bovbjerg/piano4.html > > Glug. Sorry to be boring but would anyone have a plain > uncompressed linux-friendly version of any of these files > available online somewhere, particluarly the gig ? > > --markc > > ------------------------------------------------- This mail sent through http://www.gardena.net |
|
From: Vladimir S. <ha...@so...> - 2004-01-08 13:43:17
|
Benno, Most of those samples are in SF2 format, but not all. There is one pretty good 35M .gig sample there. That's the one I have been using . . . Good news about free samples from NAMM! How do we get them? :) Regards, Vladimir. PS: I'm pretty sure there was an "unrar" utility for linux, but I haven't used it with self extracting archives. I can probably ask the author for permission to redistribute his .gig (or maybe he could put it out there in .gz instead of rar self extractor for us linux users, I'm sure he'll be excited to know that he can use linux sampler with his own sample too :) -----Original Message----- From: lin...@li... [mailto:lin...@li...] On Behalf Of be...@ga... Sent: Thursday, January 08, 2004 5:45 AM To: lin...@li... Subject: Re: [Linuxsampler-devel] Release samples, sustain quick release the sfArk decompression utility (for Windows) works without any problem under Linux using Wine. download the sample in .sfark format. download SfArk from http://www.melodymachine.com/sfark.htm wine sfark_setup.exe and then use the application's filedialog to load and decompress the file. easier than that ? :-) Anyway those samples are in SF2 format so for now of little use for LinuxSampler. BTW in my post about the Sample Library producers I forgot to say that those that will come at NAMM agreed to give us a few free sampling CDs that LinuxSampler developers can use for development and testing purposes. Very nice ! cheers, Benno http://www.linuxsampler.org Scrive Mark Constable <ma...@re...>: > > > http://www.musik.auc.dk/~bovbjerg/piano4.html > > Glug. Sorry to be boring but would anyone have a plain > uncompressed linux-friendly version of any of these files > available online somewhere, particluarly the gig ? > > --markc > > ------------------------------------------------- This mail sent through http://www.gardena.net ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Linuxsampler-devel mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Vladimir S. <ha...@so...> - 2004-01-08 03:00:44
|
Mark, > sounds like you are a better keyboardist than I which will help also!) Doubt it . . . i haven't had any serious practice for almost 10 years now :( > I think that I'd love to try out your release sample patches when you > are ready. However, release samples are only part of the click and pop > problem. Since many gig files do not have release samples there needs to > be some sort of envelope placed on the signal being played, taking its > value down to 0 at a known rate, to eliminate all of the clicks. My dirty hack was not about playing release samples from the gig file. It was actually about 3 things: 1) Keeping playing whatever is to be played instead of killing the voice 2) Gradually reduce the volume of that "to be killed" voice using some curve 3) Eventually kill the voice when it's "would be effective volume" gets low enough. So it is generating a release envelope, not playing one from the sample. It does (as far as i can tell) remove the clicks, but for "realistic" sound you do need release samples from the gig file too as far as i understand. > I don't know the term for double clutching the sustain pedal, and > actually I hadn't noticed this before, so there is certainly something > there we need to look into. > I'll need to think a bit about your general math ideas for doing the > release. I'm a bit tired this evening, but I'm not clear how you are > varying the energy of the release sample based on what the current > volume of the playing sample is? I.e. - If you play a loud note, and > then release fairly quickly, to move cleanly into that note we have to > do nothing to that release sample. However, if you play a sustained > piano note, but wait 10 seconds before releasing, do we not need to do > something to make it fit cleanly together? I'm not sure, but I had > thought so. I'm adjusting the effective volume from whatever it would otherwise be if i just kept playing the note forever. I'm them removing a % from that effective volume when the sound is created. So it always starts from whatever it was at the time of the release and then it goes down according to some formula. Formula whatever it may be should be impelented as a precomputed array but for now i came up with something that doesn't require any conditional code, so the code that runs is the same regardless of the voice being in release state or not. I use the sqrt() function to give me a curve from anywhere close to 0 to just about 1. The theory behind it was initially to have from 0%(0) to 100%(1) of the volume removed. I then practiced with this code a little bit and decided to reduce the effect of that formula to make sound last a bit longer by dividing that 0..1 coefficient by a constant. I found that when the constant was too big the clicking noise would appear again as this generated release envelope would not bring the volume low enough. 128 seemed ok. It was late at night though so my hearing might not have been at it's best :) > Anyway, very good to have you here and I look very forward to trying > out your patches. I'm currently not doing the right thing about sustain state of that voice and something else so i'll probably have to research that before creating any kind of a meaningful patch. Regards, Vladimir. |
|
From: Mark K. <mar...@co...> - 2004-01-08 03:57:57
|
On Wed, 2004-01-07 at 18:59, Vladimir Senkov wrote: > My dirty hack was not about playing release samples from the gig file. It > was actually about 3 things: > 1) Keeping playing whatever is to be played instead of killing the voice > 2) Gradually reduce the volume of that "to be killed" voice using some curve > 3) Eventually kill the voice when it's "would be effective volume" gets low > enough. > > So it is generating a release envelope, not playing one from the sample. Actually, that sort of thinking can be very valuable I think. Most gig files don't have release samples, so good strategies for handling them is a great thing to build up some understanding around. > It does (as far as i can tell) remove the clicks, but for "realistic" sound > you do need release samples from the gig file too as far as i understand. For the pianos, yes... > > I'm adjusting the effective volume from whatever it would otherwise be if i > just kept playing the note forever. > I'm them removing a % from that effective vol Yes, I can see that now with your explanation. Thanks. <SNIP> > It was late at night though so my hearing might not have been at it's best > :) My ears are old. I know their hearing is not the best. ;-) > > > Anyway, very good to have you here and I look very forward to trying > > out your patches. > > I'm currently not doing the right thing about sustain state of that voice > and something else so i'll probably have to research that before creating > any kind of a meaningful patch. > Even playing wit just your computed release envelopes will be interesting. |
|
From: <be...@ga...> - 2004-01-08 10:21:00
|
Great Vladimir ! I'm heading to NAMM ( http://www.thenammshow.com/ ) with a company that produces Linux based musical instruments ( http://www.lionstracs.com ). I asked on northernsounds.com (a forum frequented by sample library producers, hollywood composers etc :-) ), if anyone wants to see LinuxSampler in action and that we seek collaboration with sample library producers and the response was very positive. see my post here: http://www.northernsounds.com/ubb/NonCGI/ultimatebb.php?ubb=get_topic;f=3;t=006841;p=1 For now about 3-4 well known sample library producers have agreed to speak with us. That's very nice, they see the big potential of LS. But for the NAMM (begins January, 15) it would be cool if someone could produce a quick "hack" like Vladimir did to add simple a release envelope to get rid of clicks at note-offs. That way we make a much better impression when the sample producer guys will listen at it. Unfortunately I have no time to lend you a hand because this weeek is very stressful so it would be cool if Vladimir together with Christian and others could produce this quick "release envelope hack" to show off at NAMM. (the important thing is that it should not crash when you press/release sustain) I count on you guys ! (let me know here on the mailing list if you produce a patch for that date). cheers, Benno http://www.linuxsampler.org Scrive Vladimir Senkov <ha...@so...>: > > Anyway, long story short the only thing that i didn't enjoy about linux > sampler was that clicking noise that results from no release sample support, > so i've decided to try to do something about it. ------------------------------------------------- This mail sent through http://www.gardena.net |
|
From: David O. <da...@ol...> - 2004-01-08 11:23:39
|
On Thursday 08 January 2004 11.21, be...@ga... wrote: [...] > But for the NAMM (begins January, 15) it would be cool if someone > could produce a quick "hack" like Vladimir did to add simple a > release envelope to get rid of clicks at note-offs. That way we > make a much better impression when the sample producer guys will > listen at it. I have a simple DAHDSR EG in Audiality. It generates timestamped,=20 sample accurate <target, duration> events that are very easy to=20 handle. Sections are linear only, but I guess that'll do for now. It's fixed point, but converting to float should be trivial, and I'm=20 going to do that anyway. (Audiality is probably overkill for=20 handhelds and low end games anyway, and all PC style machines and=20 most consoles have decent FPUs these days, at least for floats.) I'll go have a look at the code... //David Olofson - Programmer, Composer, Open Source Advocate =2E- Audiality -----------------------------------------------. | Free/Open Source audio engine for games and multimedia. | | MIDI, modular synthesis, real time effects, scripting,... | `-----------------------------------> http://audiality.org -' --- http://olofson.net --- http://www.reologica.se --- |
|
From: David O. <da...@ol...> - 2004-01-08 11:53:49
|
On Thursday 08 January 2004 12.23, David Olofson wrote: [...Audiality EG...] > I'll go have a look at the code... Well, there are some issues: =09* It doesn't handle volume changes during sections, =09 so you can't fade while playing a note. (Not an =09 issue if volume is handled elsewhere in the signal =09 chain, though.) =09* Sustain->release is a one-way state change. No =09 sustain double clutching, that is. =09* And it's a DAHDSR, of course... Generic N-section =09 envelopes are much more flexible. This is stuff I'll need to fix eventually anyway. The envelope should=20 have a "gain" input that supports ramp events, for "live" volume=20 control. (Could be used for chaining/multiplying EGs and stuff as=20 well.) Sustain should be an event driven control, rather than a state=20 change call, and the envelope should be programmed using a list of=20 generic sections rather than the fixed DAHDSR parameter set. Problem is I have to get a real time scripting engine and various=20 hardware drivers to work within a few weeks, so I'm pretty much=20 hacking around the clock. :-/ //David Olofson - Programmer, Composer, Open Source Advocate =2E- Audiality -----------------------------------------------. | Free/Open Source audio engine for games and multimedia. | | MIDI, modular synthesis, real time effects, scripting,... | `-----------------------------------> http://audiality.org -' --- http://olofson.net --- http://www.reologica.se --- |
|
From: Vladimir S. <ha...@so...> - 2004-01-08 13:59:25
|
Benno, I should have time this weekend to work on a (better) hack. I need to figure out what to do with the remainder of the AudiThread::ReleaseVoice(). If Christian had time too that'd be awesome because I really understand very little about ls architecture yet. For now I just call Release() there but there is some sustain handling there I need to figure out how to do. If I leave it there now there as is it cores on the next attack if I take it out completely it seems to work but there is usually something wrong with taking something you don't understand completely out so I need to learn and understand it first . . . But I must point out that sustain seems to work still (somehow). For a hack solution, Jan15 doesn't sound that bad, but it will probably remain mostly untested. Too bad I'm not in California otherwise I'd check it out . . . I'm glad you are getting lots of positive responses on namm forum! Regards, Vladimir. -----Original Message----- From: lin...@li... [mailto:lin...@li...] On Behalf Of be...@ga... Sent: Thursday, January 08, 2004 5:21 AM To: lin...@li... Subject: [Linuxsampler-devel] Sample Library producers meet LinuxSampler at NAMM :-), was: Release samples, sustain quick release Great Vladimir ! I'm heading to NAMM ( http://www.thenammshow.com/ ) with a company that produces Linux based musical instruments ( http://www.lionstracs.com ). I asked on northernsounds.com (a forum frequented by sample library producers, hollywood composers etc :-) ), if anyone wants to see LinuxSampler in action and that we seek collaboration with sample library producers and the response was very positive. see my post here: http://www.northernsounds.com/ubb/NonCGI/ultimatebb.php?ubb=get_topic;f= 3;t=006841;p=1 For now about 3-4 well known sample library producers have agreed to speak with us. That's very nice, they see the big potential of LS. But for the NAMM (begins January, 15) it would be cool if someone could produce a quick "hack" like Vladimir did to add simple a release envelope to get rid of clicks at note-offs. That way we make a much better impression when the sample producer guys will listen at it. Unfortunately I have no time to lend you a hand because this weeek is very stressful so it would be cool if Vladimir together with Christian and others could produce this quick "release envelope hack" to show off at NAMM. (the important thing is that it should not crash when you press/release sustain) I count on you guys ! (let me know here on the mailing list if you produce a patch for that date). cheers, Benno http://www.linuxsampler.org Scrive Vladimir Senkov <ha...@so...>: > > Anyway, long story short the only thing that i didn't enjoy about > linux sampler was that clicking noise that results from no release > sample support, so i've decided to try to do something about it. ------------------------------------------------- This mail sent through http://www.gardena.net ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Linuxsampler-devel mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Rui N. C. <rn...@rn...> - 2004-01-15 14:38:16
Attachments:
liblscp-0.0.4.tar.gz
|
Hi all,
On the path for a GUI for linuxsampler, I've been taking some of my spare
time by writing an early implementation for the LSCP (the LinuxSampler
Control Protocol), as defined from the current available draft document.
My implementation, while still rather crude, is taking the form of a
programming library for plain conventional C, codenamed liblscp.
One of my objectives is that liblscp evolves as the implementation for a
linuxsampler API, while being a fair abstraction for the network and/or
ipc aspects of LSCP.
For the facts, liblscp is actually a wrapper for the LSCP specification,
taking all the TCP/UDP socket communication into it's main control, hiding
all or some of the protocol bureoucracy from the user and exposing a
simple and opaque C programming language interface, mainly by mapping
events to user function callback handlers.
The design of liblscp assumed that the programming interface provided is
useable and applicable either for server (linuxsampler itself) and/or
client (gui's) development.
Some design features (no rocket-sci here :)
* Multi-threaded server; but clients blocks for synchronous request calls.
* Multi-client; one server instance serves many clients, local and/or
remote.
* Server events broadcasted and delivered to client callbacks.
* Client requests processed on server supplied callback.
Please note that (as usual :) documentation is none at this stage but I'll
challenge you to look at the source code provided on the tarball below. A
barebones server and client test programs are included (lscp_server_test
and lscp_client_test).
As a quick reference for the server programming, one links to liblscp to
create a server instance, just like this:
#include <lscp_server.h>
lscp_server_t *server;
server = lscp_server_create (server_port, server_callback,
server_data);
where server_port is the port number where the server will be
listening for connections; server_callback is the server supplied
callback function that will handle every client request; server_data is
any reference to data that will be fed into server_callback without
modification.
The server callback function must have the following prototype:
lscp_status_t server_callback ( lscp_connect_t *conn, const char
*request, int reqlen, void *server_data );
where conn is just a client connection handle, that shall be used for the
server responses; the request text which has a length of reqlen bytes;
server_data is the same value given on lscp_server_create.
While handling each request the server must cook it's response and
eventually issue the following:
lscp_server_result (conn, result, reslen);
where conn is the client handle, and result is a pointer to the server
response literal text of reslen bytes. Of course the response shall obey
to the protocol specification.
The server issues a broadcast to its subscribers by simply issuing:
lscp_server_broadcast (server, buf, buflen);
which will trigger the client callback function, which will be fed with an
exact copy of buf/len; this is the intended way to deliver all
notifications to each subscribed client.
When its time to shutdown the server instance, just don't forget to call
the server destructor:
lscp_server_destroy (server);
and we're done with the server.
Likewise, as for client programming, you create a client instance just
like that:
#include <lscp_client.h>
lscp_client_t *client;
client = lscp_client_create (server_host, server_port,
client_callback, client_data);
where server_host is the hostname of the server we wish to connect, and
server_port is the respective port number; client_callback is the client
supplied callback function that will handle every server notification
event; client_data is intended for client context and will be fed to
client_callback without intervention.
The client may issue a request to server by use of:
lscp_client_call (client, request, reqlen, &result, &reslen);
and the server response will be returned on result.
The client callback function prototype is very similar to the server one:
lscp_status_t client_callback ( lscp_client_t *client, const char
*buf, int buflen, void *client_data );
where buf will be a pointer to the event text which is buflen bytes in
length; client_data is exactly the same value given on lscp_client_create
call.
This callback function is the place to handle all server notifications and
will be only called if the client is currently subscribed. No response
from the client is expected while processing an event within
client_callback.
A client subscribes to receive notifications by calling:
lscp_client_subscribe (client);
after which it will start receiving events by means of the supplied
client_callback function. To unsubscribe and stop this deliverance:
lscp_client_unsubscribe (client);
Finally, when a client is about to quit, the proper terminator is in order:
lscp_client_destroy (client);
Nuff said. If you care or dare, you may check out the tarball attached to
this message (liblscp-0.0.4.tar.gz) or better yet, track the revolving
under:
http://www.rncbc.org/ls/
Please note that the code is known to compile and run on linux AND on
win32 (!). On linux the main target is a shared library (liblscp.so) so
remember to set your LS_LIBRARY_PATH accordingly before running the test
programs.
A final disclaimer goes to the fact that I AM NOT a socket nor thread
programming guru, whatsoever. So fundamental mistakes may be lying around,
somewhere. Besides that ItJustWorks(tm:).
I'm eager to hear your feedback and comments. As usual, destructive
criticism will be sent to /dev/null ;)
Hope to be on the right track,
and towards linuxsampler integration.
Otherwise sorry for the bandwidth waste.
Cheers.
--
rncbc aka Rui Nuno Capela
rn...@rn...
|
Thanks for helping keep SourceForge clean.
X