Re: [Linuxsampler-devel] Lates CVS commit

[Rui N. C. <rn...@rn...>]

Hi Vladimir,

>
> I think you may need to add liblscp.a as part of "all" in
> liblscp/Makefile. Otherwise only .so is built and make failes
> when trying to link.
>

I guess you're talking about the Makefile that's included with liblscp
source tarball. By applying my patch you'll get all liblscp source files
under src/network/liblscp and linuxsampler statically linked with
liblscp.a. Of course, all relevant automake files are also patched to this
effect, so the original liblscp Makefile is completely overriden on
configure.

Have you tried the patch? To make it easier, these are straight steps:

  LS_CVSROOT=:pserver:ano...@cv...:/home/schropp/linuxsampler
  cvs -z3 -d$LS_CVSROOT export -r HEAD linuxsampler
  cd linuxsampler
  gzip -dc ../linuxsampler-0.1-cvs20040306b.patch.gz | patch -p1
  make -f Makefile.cvs
  ./configure
  make

Then run it...

  src/linuxsampler --server --gig /path/to/yourfile.gig

You build the stand-alone test client separatelly:

  tar -zxvf liblscp-0.0.6.tar.gz
  cd liblscp-0.0.6
  make

Run it right away:

  LD_LIBRARY_PATH=. ./lscp_client_test

There you can enter LSCP commands and communicate to current running
server (linuxsampler). Enter command like this:

  lscp_client> RESET CHANNEL 0
  lscp_client> SET CHANNEL VOLUME 0 0.5
  lscp_client> LOAD INSTRUMENT /path/to/another/file.gig 0 0

Hope you enjoy.

>
> But more importantly . . . I sort of agree with Christian that a hand
> crafted parser might not be the best fit for this application. Having
> said that, i also believe that parser is not that important and we could
> easily replace it later with another one that will call the same
> callbacks.

Yes, that's my idea too. For the current specification of LSCP the simple
and raw approach is quite enough, and it works too ;)

> So as long as we've written those callbacks we should be OK no matter
> what the parser looks like.
> I'll just try to write a few callbacks here and there and let you guys
> sort out your design differences (as far as hand crafted parser,
> yacc/bison or any other solution you see fit).
>

Guess that the priority now are those LSCPServer methods that aren't
currently implemented, that map directly to each LSCP command. Everything
else is already handled by liblscp.

> Or . . . if you want me to participate in this discussion then just let
> me know and i'll be at your service :) Short summary of my position is:
> Parsers may be less efficient, but they make code much easier to
> maintain and enhance. Hand crafted code may be more efficient, but
> strcmp isn't the most efficient solution (if by efficient we mean
> runtime speed).
>

OK. See you then.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...