Menu
▾
▴
linuxsampler-devel — This list is for discussing LinuxSampler development issues and ideas
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(27) |
Nov
(120) |
Dec
(16) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(65) |
Feb
(2) |
Mar
(53) |
Apr
(15) |
May
|
Jun
(19) |
Jul
(8) |
Aug
(35) |
Sep
(17) |
Oct
(70) |
Nov
(87) |
Dec
(94) |
| 2004 |
Jan
(133) |
Feb
(28) |
Mar
(45) |
Apr
(30) |
May
(113) |
Jun
(132) |
Jul
(33) |
Aug
(29) |
Sep
(26) |
Oct
(11) |
Nov
(21) |
Dec
(60) |
| 2005 |
Jan
(108) |
Feb
(153) |
Mar
(108) |
Apr
(44) |
May
(72) |
Jun
(90) |
Jul
(99) |
Aug
(67) |
Sep
(117) |
Oct
(38) |
Nov
(40) |
Dec
(27) |
| 2006 |
Jan
(16) |
Feb
(18) |
Mar
(21) |
Apr
(71) |
May
(26) |
Jun
(48) |
Jul
(27) |
Aug
(40) |
Sep
(20) |
Oct
(118) |
Nov
(69) |
Dec
(35) |
| 2007 |
Jan
(76) |
Feb
(98) |
Mar
(26) |
Apr
(126) |
May
(94) |
Jun
(46) |
Jul
(9) |
Aug
(89) |
Sep
(18) |
Oct
(27) |
Nov
|
Dec
(49) |
| 2008 |
Jan
(117) |
Feb
(40) |
Mar
(18) |
Apr
(30) |
May
(40) |
Jun
(10) |
Jul
(30) |
Aug
(13) |
Sep
(29) |
Oct
(23) |
Nov
(22) |
Dec
(35) |
| 2009 |
Jan
(19) |
Feb
(39) |
Mar
(17) |
Apr
(2) |
May
(6) |
Jun
(6) |
Jul
(8) |
Aug
(11) |
Sep
(1) |
Oct
(46) |
Nov
(13) |
Dec
(5) |
| 2010 |
Jan
(21) |
Feb
(3) |
Mar
(2) |
Apr
(7) |
May
(1) |
Jun
(26) |
Jul
(3) |
Aug
(10) |
Sep
(13) |
Oct
(35) |
Nov
(10) |
Dec
(17) |
| 2011 |
Jan
(26) |
Feb
(27) |
Mar
(14) |
Apr
(32) |
May
(8) |
Jun
(11) |
Jul
(4) |
Aug
(7) |
Sep
(27) |
Oct
(25) |
Nov
(7) |
Dec
(2) |
| 2012 |
Jan
(20) |
Feb
(17) |
Mar
(59) |
Apr
(31) |
May
|
Jun
(6) |
Jul
(7) |
Aug
(10) |
Sep
(11) |
Oct
(2) |
Nov
(4) |
Dec
(17) |
| 2013 |
Jan
(17) |
Feb
(2) |
Mar
(3) |
Apr
(4) |
May
(8) |
Jun
(3) |
Jul
(2) |
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
(1) |
| 2014 |
Jan
(6) |
Feb
(26) |
Mar
(12) |
Apr
(14) |
May
(8) |
Jun
(7) |
Jul
(6) |
Aug
(6) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
(9) |
Feb
(5) |
Mar
(4) |
Apr
(9) |
May
(3) |
Jun
(2) |
Jul
(4) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(3) |
| 2016 |
Jan
(2) |
Feb
(4) |
Mar
(5) |
Apr
(4) |
May
(14) |
Jun
(31) |
Jul
(18) |
Aug
|
Sep
(10) |
Oct
(3) |
Nov
|
Dec
|
| 2017 |
Jan
(39) |
Feb
(5) |
Mar
(2) |
Apr
|
May
(52) |
Jun
(11) |
Jul
(36) |
Aug
(1) |
Sep
(7) |
Oct
(4) |
Nov
(10) |
Dec
(8) |
| 2018 |
Jan
(3) |
Feb
(4) |
Mar
|
Apr
(8) |
May
(28) |
Jun
(11) |
Jul
(2) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(25) |
| 2019 |
Jan
(12) |
Feb
(50) |
Mar
(14) |
Apr
(3) |
May
(8) |
Jun
(17) |
Jul
(10) |
Aug
(2) |
Sep
(21) |
Oct
(10) |
Nov
|
Dec
(28) |
| 2020 |
Jan
(4) |
Feb
(10) |
Mar
(7) |
Apr
(16) |
May
(10) |
Jun
(7) |
Jul
(2) |
Aug
(5) |
Sep
(3) |
Oct
(3) |
Nov
(2) |
Dec
(1) |
| 2021 |
Jan
|
Feb
(5) |
Mar
(13) |
Apr
(13) |
May
(7) |
Jun
|
Jul
(1) |
Aug
(11) |
Sep
(12) |
Oct
(7) |
Nov
(26) |
Dec
(41) |
| 2022 |
Jan
(23) |
Feb
|
Mar
(8) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(1) |
Dec
(1) |
| 2023 |
Jan
|
Feb
(5) |
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(11) |
Sep
(5) |
Oct
(1) |
Nov
|
Dec
|
| 2024 |
Jan
(2) |
Feb
(4) |
Mar
(1) |
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(10) |
Dec
|
| 2025 |
Jan
|
Feb
(4) |
Mar
(1) |
Apr
(2) |
May
|
Jun
(17) |
Jul
(1) |
Aug
(4) |
Sep
(7) |
Oct
(1) |
Nov
(8) |
Dec
|
|
From: Christian S. <chr...@ep...> - 2004-03-15 22:25:34
|
Es geschah am Friday 12 March 2004 14:34 als Piotr Sawicki schrieb: > It is working. Some gig files play as they should! but some don't, for > example 00_GM500_MegaPiano.gig is pitch shifted a tritone, Do you have a Gigasampler instrument editor? If yes you could use 'gigdump' (coming with libgig) to compare the values libgig reads (libgig is used in LinuxSampler to load the gig files) with the ones your Gigasampler instrument editor shows. You can checkout the latest version of libgig also from cvs.linuxsampler.org, with the same command line as LinuxSampler, just replace "co linuxsampler" by "co libgig". Unfortunately cvs.linuxsampler.org is currently down due to construction works, but I hope it will be online in the next days again. > pe_Rhodes_Slow.gig is not pitch shifted but the decay is to long. Which decay stage? Decay 1, decay 2? What are the exact values? CU Christian |
|
From: Daniel M. <dm...@ne...> - 2004-03-15 04:31:38
|
I just compiled libgig on OS X 10.3.2 (darwin-ppc/7.2.0, gcc 3.3). Two things: First, even when I './configure --enable-shared=yes' and the output says: checking whether to build shared libraries... yes only static (.a) libraries are produced. There's no .la file produced either, suggesting libtool isn't getting called? Second, why doesn't 'make install' install the .h headers? Having a .a library is pretty useless without a defined interface. dan -- Daniel Macks dm...@ne... http://www.netspace.org/~dmacks |
|
From: Piotr S. <pe...@pl...> - 2004-03-12 13:52:28
|
>As always, does the following work? > >=09cd ~ >=09rm -r linuxsampler >=09cvs -z3 -d:pserver:ano...@cv...:/home/schropp/l= inuxsampler co linuxsampler >=09cd linuxsampler >=09make -f Makefile.cvs >=09./configure && make > Yes, Thanks It is working. Some gig files play as they should! but some don't, fo= r=20 example 00_GM500_MegaPiano.gig is pitch shifted a tritone,=20 pe_Rhodes_Slow.gig is not pitch shifted but the decay is to long. Thanks again Piotr --=20 Kopalnia D=BCwi=EAku Piotr Karol Sawicki=20 email: pe...@pl... strona domowa: www.piotr.art.pl |
|
From: Christian S. <chr...@ep...> - 2004-03-11 19:43:07
|
Es geschah am Thursday 11 March 2004 15:42 als Piotr Sawicki schrieb: > Hi, > I used to compile the previous versions of linuxsampler, but since last > two commits I can not. > What am I doing wrong? As always, does the following work? cd ~ rm -r linuxsampler cvs -z3 -d:pserver:ano...@cv...:/home/schropp/linuxsampler co linuxsampler cd linuxsampler make -f Makefile.cvs ./configure && make CU Christian |
|
From: Piotr S. <pe...@pl...> - 2004-03-11 14:59:42
|
Hi, I used to compile the previous versions of linuxsampler, but since la= st=20 two commits I can not. What am I doing wrong? Thanks Piotr [piotr@pececik linuxsampler]$ ./configure checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking whether byte ordering is bigendian... no checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking whether x86 architecture... yes checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking alsa/asoundlib.h usability... yes checking alsa/asoundlib.h presence... yes checking for alsa/asoundlib.h... yes checking for main in -lasound... yes checking Alsa version... 0.9.8 checking for pkg-config... /usr/bin/pkg-config checking for jack... yes checking JACK_CFLAGS... checking JACK_LIBS... -ljack -lpthread -ldl -lrt checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking for a sed that does not truncate output... /bin/sed checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... no, using cp -p checking how to recognise dependent libraries... pass_all checking dlfcn.h usability... yes checking dlfcn.h presence... no configure: WARNING: dlfcn.h: accepted by the compiler, rejected by th= e=20 preprocessor! configure: WARNING: dlfcn.h: proceeding with the compiler's result checking for dlfcn.h... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for epcf90... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for gfortran... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared=20 libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared=20 libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared=20 libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool configure: creating ./config.status config.status: creating Makefile config.status: creating src/Makefile config.status: creating config.h config.status: executing depfiles commands [piotr@pececik linuxsampler]$ make cd . && /bin/sh /home/piotr/linuxsampler/missing --run aclocal-1.6 cd . && \ /bin/sh /home/piotr/linuxsampler/missing --run automake-1.6 --forei= gn =20 Makefile cd . && /bin/sh /home/piotr/linuxsampler/missing --run autoconf /bin/sh ./config.status --recheck running /bin/sh ./configure --no-create --no-recursion checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking whether byte ordering is bigendian... no checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking whether x86 architecture... yes checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking alsa/asoundlib.h usability... yes checking alsa/asoundlib.h presence... yes checking for alsa/asoundlib.h... yes checking for main in -lasound... yes checking Alsa version... 0.9.8 checking for pkg-config... /usr/bin/pkg-config checking for jack... yes checking JACK_CFLAGS... checking JACK_LIBS... -ljack -lpthread -ldl -lrt checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking for a sed that does not truncate output... /bin/sed checking whether ln -s works... no, using cp -p checking how to recognise dependent libraries... pass_all checking command to parse /usr/bin/nm -B output... ok checking how to run the C++ preprocessor... g++ -E checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for ranlib... ranlib checking for strip... strip checking for objdir... .libs checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... no checking if we can lock with hard links... no configure: WARNING: `gcc' does not support `-c -o', so `make -j' may = be=20 unsafe checking if gcc supports -fno-rtti -fno-exceptions... yes checking whether the linker (/usr/bin/ld) supports shared libraries..= . yes checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... GNU/Linux ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking whether -lc should be explicitly linked in... no creating libtool configure: creating ./config.status cd . && /bin/sh ./config.status Makefile config.status: creating Makefile cd . && /bin/sh /home/piotr/linuxsampler/missing --run autoheader WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' WARNING: and `config.h.top', to define templates for `config.h.in' WARNING: is deprecated and discouraged. WARNING: Using the third argument of `AC_DEFINE' and WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without WARNING: `acconfig.h': WARNING: AC_DEFINE([NEED_MAIN], 1, WARNING: [Define if a function `main' is needed.]) WARNING: More sophisticated templates can also be produced, see the WARNING: documentation. touch ./config.h.in cd . && /bin/sh ./config.status config.h config.status: creating config.h make all-recursive make[1]: Entering directory `/home/piotr/linuxsampler' Making all in src make[2]: Entering directory `/home/piotr/linuxsampler/src' cd .. && /bin/sh ./config.status src/Makefile depfiles config.status: creating src/Makefile config.status: executing depfiles commands make[2]: Leaving directory `/home/piotr/linuxsampler/src' make[2]: Entering directory `/home/piotr/linuxsampler/src' Making all in network make[3]: Entering directory `/home/piotr/linuxsampler/src/network' make[3]: *** No rule to make target `all'. Stop. make[3]: Leaving directory `/home/piotr/linuxsampler/src/network' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/piotr/linuxsampler/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/piotr/linuxsampler' make: *** [all] Error 2 [piotr@pececik linuxsampler]$ --=20 Kopalnia D=BCwi=EAku Piotr Karol Sawicki=20 email: pe...@pl... strona domowa: www.piotr.art.pl |
|
From: Mark K. <mar...@co...> - 2004-03-11 02:17:10
|
On Wed, 2004-03-10 at 17:51, Christian Schoenebeck wrote: > Es geschah am Thursday 11 March 2004 01:58 als Mark Knecht schrieb: > > Christian, > > I'm not sure if you saw an earlier email I sent to you. I never saw a > > reply so maybe it didn't get there or I forgot to send it? > > > > Anyway, I was looking at the GSt help files and they showed decay_1 > > as an exponential decay and not linear as is shown in your eg1.pdf file > > below. Maybe you've already changed it to exponential in LS and the > > diagram just didn't get updated? Or possibly you have a reason to leave > > it linear and be different from GSt? > > I received it and haven't forgotten. I just felt that it wouldn't be that > important for the moment, but I will fix it to exp. with the next commit. > Works for me! Take care, Mark |
|
From: Christian S. <chr...@ep...> - 2004-03-11 02:11:20
|
Es geschah am Thursday 11 March 2004 01:58 als Mark Knecht schrieb: > Christian, > I'm not sure if you saw an earlier email I sent to you. I never saw a > reply so maybe it didn't get there or I forgot to send it? > > Anyway, I was looking at the GSt help files and they showed decay_1 > as an exponential decay and not linear as is shown in your eg1.pdf file > below. Maybe you've already changed it to exponential in LS and the > diagram just didn't get updated? Or possibly you have a reason to leave > it linear and be different from GSt? I received it and haven't forgotten. I just felt that it wouldn't be that important for the moment, but I will fix it to exp. with the next commit. CU Christian |
|
From: Mark K. <mar...@co...> - 2004-03-11 01:16:41
|
Christian, I'm not sure if you saw an earlier email I sent to you. I never saw a reply so maybe it didn't get there or I forgot to send it? Anyway, I was looking at the GSt help files and they showed decay_1 as an exponential decay and not linear as is shown in your eg1.pdf file below. Maybe you've already changed it to exponential in LS and the diagram just didn't get updated? Or possibly you have a reason to leave it linear and be different from GSt? Either way is OK with me as long as you have a reason you feel is appropriate. Anyway, I'm just following up as this seemed to be the only difference I found between the two implementation's documentation. With best regards, Mark On Wed, 2004-03-10 at 14:23, Christian Schoenebeck wrote: > Changes: > > * src/eg_vca.cpp: added following transitions to the envelope > generator: 'Attack_Hold' -> 'Release', 'Decay_1' -> 'Release' in > case of a release event. Here the new state chart diagram for EG1: > > http://www.linuxsampler.org/doc/engines/gig/eg1.pdf > http://www.linuxsampler.org/doc/engines/gig/eg1.scd > > The latter is as always the TCM source file of the diagram. > > * EG1 parameters 'Attack Time', 'Release Time' and 'Sustain Time' > are now controllable by a MIDI controller defined in the .gig > file. The amount of influence the controller can cause has still > to be adjusted to the orginal behavior of Gigasampler though. > > * src/voice.cpp: fixed bug in pitch calculation which caused new > triggered voices to be played back without honoring the current > pitch bend value. The power of paranthesis... ;) (only one single > paranthesis was missing) > > CU > Christian > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Christian S. <chr...@ep...> - 2004-03-10 22:42:54
|
Changes: * src/eg_vca.cpp: added following transitions to the envelope generator: 'Attack_Hold' -> 'Release', 'Decay_1' -> 'Release' in case of a release event. Here the new state chart diagram for EG1: http://www.linuxsampler.org/doc/engines/gig/eg1.pdf http://www.linuxsampler.org/doc/engines/gig/eg1.scd The latter is as always the TCM source file of the diagram. * EG1 parameters 'Attack Time', 'Release Time' and 'Sustain Time' are now controllable by a MIDI controller defined in the .gig file. The amount of influence the controller can cause has still to be adjusted to the orginal behavior of Gigasampler though. * src/voice.cpp: fixed bug in pitch calculation which caused new triggered voices to be played back without honoring the current pitch bend value. The power of paranthesis... ;) (only one single paranthesis was missing) CU Christian |
|
From: Christian S. <chr...@ep...> - 2004-03-08 21:55:03
|
Hi Rui, hi Vladimir! I reply to your mails together in one... Am Montag, 8. M=E4rz 2004 12:09 schrieb Rui Nuno Capela: > Current linuxsampler server does NOT respond as soon as a valid syntax > command is received. > > For example, when a client sends just "ADD CHANNEL", the server seems to > wait for an additional character before it responds. > > If otherwise the client sends "ADD CHANNEL\n", the server recognizes the > command properly and responds right away. In fact, it ONLY responds when > any other character is present, not necessarily "\n". The parser waits until the command line is terminated, this can either be=20 "\r\n" or "\n" or EOF, thus if you just send "ADD CHANNEL", the parser=20 actually calls the AddChannel() function when you close the network=20 connection. You will see that on server side when you increment the debug=20 level. But to solve this misapprehension now once and forever; every command line= =20 should be CRLF terminated. I updated the protocol document therefore today. > Chris, I'm willing to devel into your bison/yacc nightmare :) I'm still > insisting in patching liblscp into the linuxsampler server, but this time > using the bison based parser. Yes, I'm telling you that I can get rid of > my handcrafted-pseudo-parser but sticking with liblscp. Why do you think bison is a nightmare? Of course, things you are not used t= o=20 are always less convenient than things you know, but you will see that this= =20 solution is pretty simple, very easy to maintain and it will definitely pay= =20 off when this protocol grows in complexity. Regarding your liblscp code migrating on server side, these are the issues = I'm=20 complaining about: a) I'm against a hand-crafted parser. b) There should be a fixed amount of threads, created on application start = and awaken as needed, instead of creating a new one on every client connecti= on. c) I don't want to see client code in the LS codebase. d) I prefer the server side completely to be implemented in C++. Regarding c) and d) I suggest to split liblscp into two parts, so liblscp j= ust=20 contains the client side and will be commited into CVS as separate module,= =20 whereas the server side goes directly into the LS codebase. I really don't= =20 want to blow the LS codebase with code we don't need in the LS engine anywa= y.=20 There's only one file that should be shared by liblscp (the client side) an= d=20 the server side in LS: one header file containing defines for warning and=20 error codes (currently meant to be the empty file src/network/lscp.h). The= =20 last point d) is of course more a matter of taste, but as the whole=20 application is written in C++, I also like the server to be and it should=20 take you only a couple of minutes to refactor your server code from C to C+= +. If you'll solve these four issues, than I'm very happy to accept your=20 solution. Am Montag, 8. M=E4rz 2004 15:39 schrieb Vladimir Senkov: > In other words, we should be able to automate EG testing, etc. test gigs > should be perhaps generated but I don't think we currently have support > for that in libgig . . . It's not currently. It would perhaps take about 2 - 4 days to extend the li= b=20 so it's also capable to create and edit .gig files. I thought about it, but= I=20 don't think it's important at the moment. Am Montag, 8. M=E4rz 2004 15:58 schrieb Rui Nuno Capela: > How do you think we can feed the parser with input from a callback? I know > that the redefined YYINPUT macro is the place to look, but it does not > seem to accomodate the callback model, at least directly. That's one of the points why I left the server single threaded. As it's not= on=20 my priotity list, I haven't really looked into this subject, but there is o= ne=20 solution that comes to my mind: a fifo, then we can even completely drop to= =20 override YY_INPUT and just set the input file descriptor to the fifo (inste= ad=20 of the standard one, which is stdin). We should research for other solution= s,=20 I don't think we're the first ones using flex/bison within a network server. CU Christian |
|
From: Christian S. <chr...@ep...> - 2004-03-08 21:54:52
|
Hi!
I updated the protocol document:
http://www.linuxsampler.org/api/draft-linuxsampler-protocol-04.pdf
http://www.linuxsampler.org/api/draft-linuxsampler-protocol-04.sxw
Major changes:
* clearified CRLF issue as pointed out recently by Rui on this list
* GET CHANNEL BUFFER_FILL command returns empty line if there are no active
disk streams
Suggestions, improvements and corrections always appreciated!
CU
Christian
|
|
From: Rui N. C. <rn...@rn...> - 2004-03-08 15:16:14
|
Chris, Vladimir, I'm facing a problem with this yacc/bison monster: How do you think we can feed the parser with input from a callback? I know that the redefined YYINPUT macro is the place to look, but it does not seem to accomodate the callback model, at least directly. I'm affraid that double-buffering is one solution, or using a pipe maybe another one. What do you think and hopefully suggest? -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Vladimir S. <ha...@so...> - 2004-03-08 14:56:09
|
Hi Rui, Christian, I think we should rely on line termination rather than the fact that someone does one send() or several. Think about eventually proxying those connections, all kinds of automation, etc, etc. And of course connection should be kept up for as long as client needs it. I think liblscp (or server part of it) needs to be merged with bison parser in some way and checked in at some point. I'm up for testing and writing callbacks. When some of these callbacks are complete I was thinking about creating a test setup driven by an expect script where test gigs could be loaded, LS and JACK could be configured such that the output be recorded into a file, some sort of midi over network driver be loaded, LS be connected to it, midi commands be sent into LS and then output files be stored and some sort of QA be done on those files. In other words, we should be able to automate EG testing, etc. test gigs should be perhaps generated but I don't think we currently have support for that in libgig . . . Regards, Vladimir. -----Original Message----- From: lin...@li... [mailto:lin...@li...] On Behalf Of Rui Nuno Capela Sent: Monday, March 08, 2004 6:10 AM To: lin...@li... Subject: Re: [Linuxsampler-devel] Lates CVS commit Hi Christian, >> >> But you're right. It's not clear enough. I will fix that. That was an >> implied assumption fault by me, because usually network protocols >> allow this multi line behavior, because it doesn't make sense to >> establish a new connection for every single network command. >> > > It's not a question of just allowing multi-line/command or not, is > also that "feature" that whether every command must be CRLF > terminated. > > On my recent tests, your bison-based parser only recognizes a command > if there's a CRLF terminator. If one's missing, you do nothing, don't > even respond to a client that issues a single command but without > terminating it with CRLF. > > It was this "undocumented" behaviour that I was referring to. > To make myslef a little bit more clear, about this behavioral issue: Current linuxsampler server does NOT respond as soon as a valid syntax command is received. For example, when a client sends just "ADD CHANNEL", the server seems to wait for an additional character before it responds. If otherwise the client sends "ADD CHANNEL\n", the server recognizes the command properly and responds right away. In fact, it ONLY responds when any other character is present, not necessarily "\n". Again, if a client only sends e.g. "GET CHANNELS" and nothing more, it will hang forever for a reply that will never arrive. Think this is wrong. My suggestion is either: 1) fix the server parser to reply immediately as soon a valid command is detected, OR 2) make that LF/CR+LF command terminator officially part of the command protocol, at least for client request strings. I do prefer the first solution, as it complies by default with the current LSCP document draft (rev.03), but can surely live with second if it's made "official" :) Please note that my complaint is not about whether the server can handle more that one command in a batch or single tcp transaction. That's fine with me, although liblscp was primarily designed with a single-command-per-transaction semantics in mind. Note that current liblscp does not make a new connection on each command. It connect()'s, then for each command transaction a send() and recv() sequence pair is performed. The session would be only close()'d when the client is done. OTHO, the problem with Vladimir's netcat test was that several commands were being buffered and stuffed in one send(), for which the latest liblscp patched linuxsampler version does not work -- my LSCPServer::server_callback was designed to handle and parse only one command buffer at a time. That can be changed of course. And I will try to comply to it. Chris, I'm willing to devel into your bison/yacc nightmare :) I'm still insisting in patching liblscp into the linuxsampler server, but this time using the bison based parser. Yes, I'm telling you that I can get rid of my handcrafted-pseudo-parser but sticking with liblscp. So, as a first timer, I wish to make liblscp's oriented LSCPServer::server_callback() to pump all received data into your parser. Note that this callback is called whenever the server recv()'s data from the client. No translation is done to the data between recv() and the callback. A session handle that uniquely identifies a client, is also given on each callback, which shall be used when responding back to the client, so it must be preserved along the whole parsing. Now we've got an emerging problem: if we expect to have several clients simultaneously, together with support for multi-line/command buffering, we must preserve the parser state between each callback (or recv() for that matter). That makes for the server maintaining a pool of parser instances, one instance for each client connection and identified by an opaque connection handle? OK. Why I'm in insisting on liblscp? Mainly 'coz of reusability and it already does multi-client, multi-threading and also because the UDP event notification stuff is already there too: you have only to call lscp_server_broadcast() when an change event pops up, liblscp takes care of all the rest ;) Hope to have made my position clear. Cheers. -- rncbc aka Rui Nuno Capela rn...@rn... P.S. Chris I'll try to be on IRC this afternoon and/or evening. ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Linuxsampler-devel mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Rui N. C. <rn...@rn...> - 2004-03-08 11:26:42
|
Hi Christian, >> >> But you're right. It's not clear enough. I will fix that. That was an >> implied assumption fault by me, because usually network protocols allow >> this multi line behavior, because it doesn't make sense to establish a >> new connection for every single network command. >> > > It's not a question of just allowing multi-line/command or not, is also > that "feature" that whether every command must be CRLF terminated. > > On my recent tests, your bison-based parser only recognizes a command if > there's a CRLF terminator. If one's missing, you do nothing, don't even > respond to a client that issues a single command but without terminating > it with CRLF. > > It was this "undocumented" behaviour that I was referring to. > To make myslef a little bit more clear, about this behavioral issue: Current linuxsampler server does NOT respond as soon as a valid syntax command is received. For example, when a client sends just "ADD CHANNEL", the server seems to wait for an additional character before it responds. If otherwise the client sends "ADD CHANNEL\n", the server recognizes the command properly and responds right away. In fact, it ONLY responds when any other character is present, not necessarily "\n". Again, if a client only sends e.g. "GET CHANNELS" and nothing more, it will hang forever for a reply that will never arrive. Think this is wrong. My suggestion is either: 1) fix the server parser to reply immediately as soon a valid command is detected, OR 2) make that LF/CR+LF command terminator officially part of the command protocol, at least for client request strings. I do prefer the first solution, as it complies by default with the current LSCP document draft (rev.03), but can surely live with second if it's made "official" :) Please note that my complaint is not about whether the server can handle more that one command in a batch or single tcp transaction. That's fine with me, although liblscp was primarily designed with a single-command-per-transaction semantics in mind. Note that current liblscp does not make a new connection on each command. It connect()'s, then for each command transaction a send() and recv() sequence pair is performed. The session would be only close()'d when the client is done. OTHO, the problem with Vladimir's netcat test was that several commands were being buffered and stuffed in one send(), for which the latest liblscp patched linuxsampler version does not work -- my LSCPServer::server_callback was designed to handle and parse only one command buffer at a time. That can be changed of course. And I will try to comply to it. Chris, I'm willing to devel into your bison/yacc nightmare :) I'm still insisting in patching liblscp into the linuxsampler server, but this time using the bison based parser. Yes, I'm telling you that I can get rid of my handcrafted-pseudo-parser but sticking with liblscp. So, as a first timer, I wish to make liblscp's oriented LSCPServer::server_callback() to pump all received data into your parser. Note that this callback is called whenever the server recv()'s data from the client. No translation is done to the data between recv() and the callback. A session handle that uniquely identifies a client, is also given on each callback, which shall be used when responding back to the client, so it must be preserved along the whole parsing. Now we've got an emerging problem: if we expect to have several clients simultaneously, together with support for multi-line/command buffering, we must preserve the parser state between each callback (or recv() for that matter). That makes for the server maintaining a pool of parser instances, one instance for each client connection and identified by an opaque connection handle? OK. Why I'm in insisting on liblscp? Mainly 'coz of reusability and it already does multi-client, multi-threading and also because the UDP event notification stuff is already there too: you have only to call lscp_server_broadcast() when an change event pops up, liblscp takes care of all the rest ;) Hope to have made my position clear. Cheers. -- rncbc aka Rui Nuno Capela rn...@rn... P.S. Chris I'll try to be on IRC this afternoon and/or evening. |
|
From: Vladimir S. <ha...@so...> - 2004-03-08 01:21:38
|
jfyi, I was able to get rid of gdb crashes by rebuilding ls with -O0. I have a total of two cores: 1) RESET after failing to load .gig file. (pInstrument was NULL when RenderAudio() was running. My understanding was that RenderAudio() should not have been called since instrument loading failed, so this should be simple to fix) 2) core when running out of voices (i think this started happening after last EG changes, looks like Stream object got corrupted when RenderAudio() was running. pRingBuffer is bad) Both cores are reproducible. I'll look into both of them next weekend, unless you guys happen to figure them out by then. Regards, Vladimir. Vladimir Senkov wrote: > Here is a patch with a few more callbacks: > GetAvailableEngines() > GetEngineInfo() > GetChannelInfo() (except for OUTPUT_CHANNEL and INPUT_CHANNEL) > I've also fixed a bug that i've previously put in --alsa_output > command line processing. > > I've noticed that ls consistenly crashes if: > 1) i try to load a gig and fail (no file found) > 2) i reset the channel > 3) i try to play something on the keyboard. > Unfortunately, i can't open the corefile . . . gdb crashes :( I'll try > to figure this out later. > > I've also noticed that output from GetBufferFill often prints out > empty lines. > > I'll keep looking into implementing other commands. This weekend was > busy and i couldn't do much but hopefully next weekend will be better. > > Regards, > Vladimir. > > > Christian Schoenebeck wrote: > >> Changes: >> >> - Implemented parser for the LinuxSampler control protocol >> (LSCP) by >> using flex / bison (where src/network/lscp.l is the input file >> for lex / >> flex and src/network/lscp.y is the input file for yacc / >> bison). Parser and >> scanner can be regenerated by 'make parser' (only necessary >> though if one >> of the two input files where modified). >> To be honest I'm not quite sure so far if this parser solution >> is a good >> choice, especially because I'm a bit disappointed about it's >> runtime >> efficiency (a main problem is that lexical analyzer and >> semantic analyzer >> are separated which is a big disadvantage for the parser >> generator in >> regards of optimization), but this lex/yacc soultion has the >> advantage >> of defining the protocol on a higher level and is thus easier >> to maintain >> in regards of a growing and possible complex protocol. We'll >> see... >> If somebody's not familiar with lex/yacc, I can give an >> introduction to the >> current LSCP implementation in a short mail if demanded. >> If somebody has a suggestion for another parser generator, let >> me know! >> >> - Implemented LSCP network server (only single threaded so far, >> thus is only >> capable to handle one connection at one time), LSCP server will >> be launched >> if LinuxSampler was started with the new "--server" flag. So far I >> implemented the following LSCP commands: >> >> * "LOAD INSTRUMENT" >> * "GET CHANNEL VOICE_COUNT" >> * "GET CHANNEL STREAM_COUNT" >> * "GET CHANNEL BUFFER_FILL" >> * "SET CHANNEL VOLUME" >> * "RESET CHANNEL" >> >> In src/network/lscpserver.cpp there already all methods which >> will be >> called in case of the respective network command. But most of them >> currently just return a "ERR:0:Not implemented yet" error >> message, so these >> methods need to be "wired" now with the engine and have to >> return a >> meaningful response message. If anybody likes to implement one >> of those >> methods I would appreciate that! (Vladimir perhaps?) >> - disk thread now started within the engine >> >> CU >> Christian >> >> P.S. It's time for a frontend... :) >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: IBM Linux Tutorials >> Free Linux tutorial presented by Daniel Robbins, President and CEO of >> GenToo technologies. Learn everything from fundamentals to system >> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >> _______________________________________________ >> Linuxsampler-devel mailing list >> Lin...@li... >> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel >> >> > |
|
From: Vladimir S. <ha...@so...> - 2004-03-08 00:19:25
|
Here is a patch with a few more callbacks: GetAvailableEngines() GetEngineInfo() GetChannelInfo() (except for OUTPUT_CHANNEL and INPUT_CHANNEL) I've also fixed a bug that i've previously put in --alsa_output command line processing. I've noticed that ls consistenly crashes if: 1) i try to load a gig and fail (no file found) 2) i reset the channel 3) i try to play something on the keyboard. Unfortunately, i can't open the corefile . . . gdb crashes :( I'll try to figure this out later. I've also noticed that output from GetBufferFill often prints out empty lines. I'll keep looking into implementing other commands. This weekend was busy and i couldn't do much but hopefully next weekend will be better. Regards, Vladimir. Christian Schoenebeck wrote: >Changes: > > - Implemented parser for the LinuxSampler control protocol (LSCP) by > using flex / bison (where src/network/lscp.l is the input file for lex / > flex and src/network/lscp.y is the input file for yacc / bison). Parser and > scanner can be regenerated by 'make parser' (only necessary though if one > of the two input files where modified). > To be honest I'm not quite sure so far if this parser solution is a good > choice, especially because I'm a bit disappointed about it's runtime > efficiency (a main problem is that lexical analyzer and semantic analyzer > are separated which is a big disadvantage for the parser generator in > regards of optimization), but this lex/yacc soultion has the advantage > of defining the protocol on a higher level and is thus easier to maintain > in regards of a growing and possible complex protocol. We'll see... > If somebody's not familiar with lex/yacc, I can give an introduction to the > current LSCP implementation in a short mail if demanded. > If somebody has a suggestion for another parser generator, let me know! > > - Implemented LSCP network server (only single threaded so far, thus is only > capable to handle one connection at one time), LSCP server will be launched > if LinuxSampler was started with the new "--server" flag. So far I > implemented the following LSCP commands: > > * "LOAD INSTRUMENT" > * "GET CHANNEL VOICE_COUNT" > * "GET CHANNEL STREAM_COUNT" > * "GET CHANNEL BUFFER_FILL" > * "SET CHANNEL VOLUME" > * "RESET CHANNEL" > > In src/network/lscpserver.cpp there already all methods which will be > called in case of the respective network command. But most of them > currently just return a "ERR:0:Not implemented yet" error message, so these > methods need to be "wired" now with the engine and have to return a > meaningful response message. If anybody likes to implement one of those > methods I would appreciate that! (Vladimir perhaps?) > > - disk thread now started within the engine > >CU >Christian > >P.S. It's time for a frontend... :) > > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >_______________________________________________ >Linuxsampler-devel mailing list >Lin...@li... >https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > |
|
From: Rui N. C. <rn...@rn...> - 2004-03-07 23:29:33
|
Hi Christian, > > But you're right. It's not clear enough. I will fix that. That was an > implied assumption fault by me, because usually network protocols allow > this multi line behavior, because it doesn't make sense to establish a > new connection for every single network command. > It's not a question of just allowing multi-line/command or not, is also that "feature" that whether every command must be CRLF terminated. On my recent tests, your bison-based parser only recognizes a command if there's a CRLF terminator. If one's missing, you do nothing, don't even respond to a client that issues a single command but without terminating it with CRLF. It was this "undocumented" behaviour that I was referring to. Cheers, -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Christian S. <chr...@ep...> - 2004-03-07 22:41:59
|
Es geschah am Sonntag, 7. M=E4rz 2004 21:37 als Rui Nuno Capela schrieb: > Vladimir, > > > But . . . bison also works and it is easier to maintain :) > > Could you give me a quick summary of why you dislike bison? > > Yeah I know, but I don't have a clue about all that bison/flex/yacc stuff. > I know the principles and theory but completely lack in the practice. As already said, I can give a short introduction if anybody's interested,=20 constrained to the things we actually need. It's really simple. > > I wrote a simple netcat script to test the parser (attached) and i'm > > having some issues with your parser, while bison generated code appears > > to be working correctly. > > Hmm. If I may put this way, that's not a parser question but a network > protocol one, AFAICT. On liblscp, each command must be isolated on each > send/recv exchange and does not rely on being CR/LF terminated, which I > think is an "undocumented" feature of the bison one :) Undocumented? src/network/lscp.y is the LSCP definition, given in Backus-Na= ur=20 =46orm (BNF), which is commonly used in all protocol definition documents (= e.g.=20 HTTP) and many file format references, so this file _is_ a document and fro= m=20 lscp.y: input : line | input LF line | input CR LF line ; > I think netcat sends the whole buffer of commands in one send(), and that > is not accepted on liblscp (probably only the first line is). AFAICT the > protocol draft doesn't mention that we can send more than one command, as Page 3 from the LSCP document: "The frontend application establishes a TCP connection to the LinuxSampler= =20 instance on a certain host system. Then the frontend application will send= =20 certain ASCII based commands" But you're right. It's not clear enough. I will fix that. That was an impli= ed=20 assumption fault by me, because usually network protocols allow this multi= =20 line behavior, because it doesn't make sense to establish a new connection= =20 for every single network command. CU Christian |
|
From: Rui N. C. <rn...@rn...> - 2004-03-07 20:55:32
|
Vladimir, >> > But . . . bison also works and it is easier to maintain :) > Could you give me a quick summary of why you dislike bison? > Yeah I know, but I don't have a clue about all that bison/flex/yacc stuff. I know the principles and theory but completely lack in the practice. > I wrote a simple netcat script to test the parser (attached) and i'm > having some issues with your parser, while bison generated code appears > to be working correctly. Hmm. If I may put this way, that's not a parser question but a network protocol one, AFAICT. On liblscp, each command must be isolated on each send/recv exchange and does not rely on being CR/LF terminated, which I think is an "undocumented" feature of the bison one :) I think netcat sends the whole buffer of commands in one send(), and that is not accepted on liblscp (probably only the first line is). AFAICT the protocol draft doesn't mention that we can send more than one command, as CRLF delimited lines. IIUC, the bison implementation does, as it parses a whole multi-line buffer, which I think is not conformant with the draft, although both were written by the same author ;) If you send each command at a time, liblscp works as well but still not equivalent with Chris' original one. OTOH, the parsing code used on the liblscp version is not complete nor thoroughly tested (e.g the ADD CHANNEL command isn't being recognized at the time of this writing, same happens with other commands that have no parameters). Many thanks for the feedback. Cheers. -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Vladimir S. <ha...@so...> - 2004-03-07 19:01:02
|
Hi Rui, >Yes, that's my idea too. For the current specification of LSCP the simple >and raw approach is quite enough, and it works too ;) > > But . . . bison also works and it is easier to maintain :) Could you give me a quick summary of why you dislike bison? I wrote a simple netcat script to test the parser (attached) and i'm having some issues with your parser, while bison generated code appears to be working correctly. First of all, netcat gets stuck after first command. So my script is not working and i have to input command manually. Then some specific commands didn't work correctly: GET CHANNELS GET AVAILABLE_ENGINES SET CHANNEL AUDIO_OUTPUT_TYPE QUIT Regards, Vladimir. |
|
From: Rui N. C. <rn...@rn...> - 2004-03-07 15:59:18
|
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... |
|
From: Vladimir S. <ha...@so...> - 2004-03-07 06:47:58
|
Hi Rui, 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. 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. 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). 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). Regards, Vladimir. Rui Nuno Capela wrote: >Continuing from my last post, > > > >>OK. My parser is still strcmp based FWIW, and tonight I'll try it to be >>functional, that is processing real LSCP commands. >> >> >> > >The latest patch (see http://www.rncbc.org/ls, or attached to this post) >is almost complete. That is, it already maps to every LSCPServer method, >although some of them aren't implemented yet. > >This makes it on par of current "official" linuxsampler CVS, but patched >to use "my" liblscp stuff for the server-side of the linuxsampler control >protocol. > >Chris, Vladimir, forgive me if I seem to rush you, but could you check >this out and comment on this? Whenever you get the time, of course. > >Why I'm rushing you? 'Coz it's GUI time ;) > >Happy weekend. >-- >rncbc aka Rui Nuno Capela >rn...@rn... > > |
|
From: Rui N. C. <rn...@rn...> - 2004-03-06 19:58:23
|
Continuing from my last post, > > OK. My parser is still strcmp based FWIW, and tonight I'll try it to be > functional, that is processing real LSCP commands. > The latest patch (see http://www.rncbc.org/ls, or attached to this post) is almost complete. That is, it already maps to every LSCPServer method, although some of them aren't implemented yet. This makes it on par of current "official" linuxsampler CVS, but patched to use "my" liblscp stuff for the server-side of the linuxsampler control protocol. Chris, Vladimir, forgive me if I seem to rush you, but could you check this out and comment on this? Whenever you get the time, of course. Why I'm rushing you? 'Coz it's GUI time ;) Happy weekend. -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Rui N. C. <rn...@rn...> - 2004-03-06 11:18:44
|
Hi, Last night I've merged "my" liblscp (http://www.rncbc.org/ls) into linuxsampler code tree and made some tests on rewritting network/lscpserver.{h,cpp}, and apparentely things worked out fine. The biggest problem was, as always, adapting the autocrap stuff :) OK. My parser is still strcmp based FWIW, and tonight I'll try it to be functional, that is processing real LSCP commands. Chris, Vladimir, could you look into my code also? It boils down to applying the 'linuxsample-0.1-cvs20040305b.patch.gz' with 'patch -p1' and peek on lscpserver.cpp. On LSCPServer::server_callback member function is where all the action is (or would be). Maybe it wouldn't be a bad idea to fork an experimental branch on CVS. Cheers. -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Vladimir S. <ha...@so...> - 2004-03-06 05:45:10
|
Christian, Good stuff! I agree parser solution is suboptimal but i think it probably is good enough for now. ASCII protocol is also suboptimal, but i'm pretty sure it is worth it. BTW, some folks will argue that strcmp is also suboptimal and you must have hashtable(s) . . . Then again some folks will argue that C++ or C is suboptimal and you must write your parsers in assembly to have greater control over your pipelines and caches :))) We can always optimize parser later in case it ever becomes an issue. Engine stuff should be designed for performance from the very beginning, but parser doesn't really matter. I'll start implementing other commands then . . . Regards, Vladimir. Christian Schoenebeck wrote: >Changes: > > - Implemented parser for the LinuxSampler control protocol (LSCP) by > using flex / bison (where src/network/lscp.l is the input file for lex / > flex and src/network/lscp.y is the input file for yacc / bison). Parser and > scanner can be regenerated by 'make parser' (only necessary though if one > of the two input files where modified). > To be honest I'm not quite sure so far if this parser solution is a good > choice, especially because I'm a bit disappointed about it's runtime > efficiency (a main problem is that lexical analyzer and semantic analyzer > are separated which is a big disadvantage for the parser generator in > regards of optimization), but this lex/yacc soultion has the advantage > of defining the protocol on a higher level and is thus easier to maintain > in regards of a growing and possible complex protocol. We'll see... > If somebody's not familiar with lex/yacc, I can give an introduction to the > current LSCP implementation in a short mail if demanded. > If somebody has a suggestion for another parser generator, let me know! > > - Implemented LSCP network server (only single threaded so far, thus is only > capable to handle one connection at one time), LSCP server will be launched > if LinuxSampler was started with the new "--server" flag. So far I > implemented the following LSCP commands: > > * "LOAD INSTRUMENT" > * "GET CHANNEL VOICE_COUNT" > * "GET CHANNEL STREAM_COUNT" > * "GET CHANNEL BUFFER_FILL" > * "SET CHANNEL VOLUME" > * "RESET CHANNEL" > > In src/network/lscpserver.cpp there already all methods which will be > called in case of the respective network command. But most of them > currently just return a "ERR:0:Not implemented yet" error message, so these > methods need to be "wired" now with the engine and have to return a > meaningful response message. If anybody likes to implement one of those > methods I would appreciate that! (Vladimir perhaps?) > > - disk thread now started within the engine > >CU >Christian > >P.S. It's time for a frontend... :) > > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >_______________________________________________ >Linuxsampler-devel mailing list >Lin...@li... >https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > |
161 messages has been excluded from this view by a project administrator.
