Menu
▾
▴
linuxsampler-devel
|
From: Christian S. <sch...@li...> - 2014-01-30 19:27:25
|
Hi! I planned to write a shell command line application for LSCP. For this I already played around with Bison's auto generated parser tables. As a first result of these experiments, the sampler is now providing more useful error messages on LSCP syntax errors. Before, if you i.e. sent "GET S" (obviously wrong) it was spitting out something like: syntax error, unexpected '\r', expecting 'E' or 'T' now it is also spitting out this: Context: "GET S^..." -> Should be: SEND_EFFECT_CHAINS | SERVER | STREAMS For the LSCP shell I planned some convenient usability features for dealing with LSCP from the command line, either by typing and/or "running" LSCP script files: 1. Auto completion: when tab is pressed, or when return is pressed and the command line not fully completed yet and only a unique solution exists to complete the command line. 2. Auto correction: if the user mistyped something and it is obvious what he "meant", then the shell will automatically correct it for the user while typing. 3. Colored output. Probably even enabled by default. 4. Much more user friendly error messages on syntax errors, spread over several lines, with color and indicating semi-graphically the position of the issue. Maybe similar to clang compiler syntax error messages. 5. Visually aided suggestion in real-time while typing. The shell could display the possibilities to complete the current command line in the same line in thin font. Once the typed command line is at a point where there is only one solution to complete it, the line could i.e. turn green. Probably a bunch of more features, which make sense to be implemented as part of a shell. For example relative path arguments (see bug #154), that is relative to the working directory where the shell was called from. Or conveniently saving and restoring a sampler session with one command to/from the user's home directory. Or even variables to be reused in subsequent lines. I am currently unresolved yet though where to position the shell: a) on server side with the shell application just being a light-weight application that only transmits characters and prints out content in color to the console. Advantage: shell application would be easy to maintain and quite independent of the sampler's version being connected to. I.e. the same shell application could deal with different LSCP versions without problems. Disadvantage: typing would be more sluggish on remote network connections, since every single character typed would be transmitted, and result of its processing sent back. Or b) a full fledged autonomous shell application on client computer side, which implements the complete shell on its own, with all the parser work, error recovery and so on. Advantage: allows very quick and responsive typing. Disadvantage: the shell would assume/support exactly one LSCP version *or* it would need to connect to the server, ask for the LSCP version (GET SERVER INFO), but in that case we might need to maintain all LSCP versions inside the shell application, i.e. separate lscp.y files for each LSCP version in the shell's source files. Just thoughts for now. Comments, additions appreciated. CU Christian |
|
From: Raphaël M. <rmo...@gm...> - 2014-03-21 09:52:48
|
hello, i've been using the LSCP shell yesterday, and it has been of a great help, especially the command history. I had previously mentioned some enhancements, and i confirm they would be great to have >when you're in a command history, you have to use the delete key, you cannot use the left arrow to change some parameter on a long line. in fact you can use the delete key to go back. But i noticed that the line is grayed as soon as you go back, and it turns green again only when you have reached your previous end of line position. Maybe the line is not re-evaluated when you use the delete key from a previous command. >autocompletion on command parameters display a list of available commands/sub-commands on double-tab (depending on what has previously been greened) as a first shot, you could display the message that is printed when you enter an incomplete command "....expecting.....should be....." cheers, Raphaël |
|
From: Patrick S. <psh...@bo...> - 2014-01-30 20:15:06
|
On Fri, January 31, 2014 5:27 am, Christian Schoenebeck wrote: > Hi! > > I planned to write a shell command line application for LSCP. For this I > already played around with Bison's auto generated parser tables. As a > first > result of these experiments, the sampler is now providing more useful > error > messages on LSCP syntax errors. Before, if you i.e. sent "GET S" > (obviously > wrong) it was spitting out something like: > > syntax error, unexpected '\r', expecting 'E' or 'T' > > now it is also spitting out this: > > Context: "GET S^..." -> Should be: SEND_EFFECT_CHAINS | SERVER | STREAMS > > For the LSCP shell I planned some convenient usability features for > dealing > with LSCP from the command line, either by typing and/or "running" LSCP > script > files: > > 1. Auto completion: when tab is pressed, or when return is pressed and > the command line not fully completed yet and only a unique solution > exists to complete the command line. > > 2. Auto correction: if the user mistyped something and it is obvious what > he "meant", then the shell will automatically correct it for the user > while typing. > > 3. Colored output. Probably even enabled by default. > > 4. Much more user friendly error messages on syntax errors, spread over > several lines, with color and indicating semi-graphically the position > of the issue. Maybe similar to clang compiler syntax error messages. > > 5. Visually aided suggestion in real-time while typing. The shell could > display the possibilities to complete the current command line in the > same line in thin font. Once the typed command line is at a point > where there is only one solution to complete it, the line could i.e. > turn green. > > Probably a bunch of more features, which make sense to be implemented as > part > of a shell. For example relative path arguments (see bug #154), that is > relative to the working directory where the shell was called from. Or > conveniently saving and restoring a sampler session with one command > to/from > the user's home directory. Or even variables to be reused in subsequent > lines. > > I am currently unresolved yet though where to position the shell: > > a) on server side with the shell application just being a light-weight > application that only transmits characters and prints out content in color > to > the console. > > Advantage: shell application would be easy to maintain and quite > independent of the sampler's version being connected to. I.e. the same > shell application could deal with different LSCP versions without > problems. > > Disadvantage: typing would be more sluggish on remote network > connections, since every single character typed would be transmitted, and > result of its processing sent back. > > Or > > b) a full fledged autonomous shell application on client computer side, > which > implements the complete shell on its own, with all the parser work, error > recovery and so on. > > Advantage: allows very quick and responsive typing. > > Disadvantage: the shell would assume/support exactly one LSCP version > *or* it would need to connect to the server, ask for the LSCP version > (GET SERVER INFO), but in that case we might need to maintain all LSCP > versions inside the shell application, i.e. separate lscp.y files for > each LSCP version in the shell's source files. > > Just thoughts for now. Comments, additions appreciated. > Sounds like a very useful tool. Both options would be handy in different circumstances. For server side programming most of us will already be logged in with ssh anyway. For remote connections on machines with a keyboard interface and monitor it's probably better to run in client mode. -- Patrick Shirkey Boost Hardware Ltd |
|
From: Kevin U. <kv...@fr...> - 2014-01-30 22:19:59
|
> > Hello! I'm really happy about this idea! Almost everything I do with LinuxSampler is directly through the commandline, as at present I can't really use the current front-ends. Thank you for this consideration. > > Kevin > |
|
From: Christian S. <sch...@li...> - 2014-02-06 21:40:45
|
Ok, I just committed an initial version of the LSCP shell to SVN. The application is just called "lscp". There is also a man page. I decided to go the thin-client route, that is LSCP aware stuff being handled on sampler side, and the shell application is more or less just forwarding individual key strokes to the sampler and handling output format (color & printing) of the returned informations on the command line terminal. That should make the shell be versatile for being used successfully against various LinuxSampler versions, no matter what the exact LSCP version is, and keeps development/maintenance effort low. Current shell features: - Colored highlighting while typing (i.e. good portions bold white, syntactical bad portions red, if the command is complete and ready to be fired: green, ...). - Auto completion by tab key. The shell will also show a possible completion in real-time while typing. So that one does not need to guess when it is possible to tab-complete the command. You see it immediately. - Auto correction of trivial mistakes: for now this just covers auto converting i.e. lower case characters to upper case (if necessary, according to current LSCP grammar position), space characters to underscore characters and vice versa (also according to grammar position). In future: orthographically similar mistyped keywords might be auto corrected as well. Not a hard task. I actually also planned to integrate the LSCP reference into the shell. That is, if a certain LSCP command is identified, the shell would automatically show the relevant LSCP reference document section below the current command line (and paging the shown LSCP reference with PGUP, PGDOWN keys). However ... I have now to work on completely other stuff for a while, so this spare time fun is postponed for now. The Windows version of LinuxSampler is currently broken, because I used the POSIX termios API to get the required control over the command line terminal. That API does not exist on Windows. If anybody is interested in trying to fix this on Windows, it would be very much appreciated! That's it for now. CU Christian |
|
From: Patrick S. <psh...@bo...> - 2014-02-07 07:53:34
|
On Fri, February 7, 2014 7:41 am, Christian Schoenebeck wrote:
> Ok, I just committed an initial version of the LSCP shell to SVN. The
> application is just called "lscp". There is also a man page.
>
> I decided to go the thin-client route, that is LSCP aware stuff being
> handled
> on sampler side, and the shell application is more or less just forwarding
> individual key strokes to the sampler and handling output format (color &
> printing) of the returned informations on the command line terminal. That
> should make the shell be versatile for being used successfully against
> various
> LinuxSampler versions, no matter what the exact LSCP version is, and keeps
> development/maintenance effort low.
>
> Current shell features:
>
> - Colored highlighting while typing (i.e. good portions bold white,
> syntactical bad portions red, if the command is complete and ready to
> be fired: green, ...).
>
> - Auto completion by tab key. The shell will also show a possible
> completion in real-time while typing. So that one does not need to
> guess when it is possible to tab-complete the command. You see it
> immediately.
>
> - Auto correction of trivial mistakes: for now this just covers auto
> converting i.e. lower case characters to upper case (if necessary,
> according to current LSCP grammar position), space characters to
> underscore characters and vice versa (also according to grammar
> position).
> In future: orthographically similar mistyped keywords might be auto
> corrected as well. Not a hard task.
>
> I actually also planned to integrate the LSCP reference into the shell.
> That
> is, if a certain LSCP command is identified, the shell would automatically
> show the relevant LSCP reference document section below the current
> command
> line (and paging the shown LSCP reference with PGUP, PGDOWN keys).
>
> However ... I have now to work on completely other stuff for a while, so
> this
> spare time fun is postponed for now.
>
> The Windows version of LinuxSampler is currently broken, because I used
> the
> POSIX termios API to get the required control over the command line
> terminal.
> That API does not exist on Windows. If anybody is interested in trying to
> fix
> this on Windows, it would be very much appreciated!
>
> That's it for now.
>
Hi,
It compiles fine for me on debian-7.0 64bit. However it crashes on start
and I get this backtrace:
Reading symbols from /usr/bin/lscp...done.
(gdb) run
Starting program: /usr/bin/lscp
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff749449a in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
#0 0x00007ffff749449a in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1 0x0000000000408a4e in operator-- (this=<synthetic pointer>) at
/usr/include/c++/4.7/bits/stl_tree.h:203
#2 std::_Rb_tree<void*, std::pair<void* const, int>,
std::_Select1st<std::pair<void* const, int> >, std::less<void*>,
std::allocator<std::pair<void* const, int> > >::_M_insert_unique (
this=this@entry=0x60d340, __v=...) at
/usr/include/c++/4.7/bits/stl_tree.h:1295
#3 0x0000000000408b7b in std::_Rb_tree<void*, std::pair<void* const,
int>, std::_Select1st<std::pair<void* const, int> >, std::less<void*>,
std::allocator<std::pair<void* const, int> > >::_M_insert_unique_
(this=this@entry=0x60d340, __position=..., __v=...) at
/usr/include/c++/4.7/bits/stl_tree.h:1348
#4 0x00000000004080d4 in insert (__x=..., __position=..., this=0x60d340)
at /usr/include/c++/4.7/bits/stl_map.h:576
#5 operator[] (__k=<optimized out>, this=0x60d340) at
/usr/include/c++/4.7/bits/stl_map.h:458
#6 _newTermios () at TerminalCtrl.cpp:26
#7 TerminalCtrl::now () at TerminalCtrl.cpp:93
#8 0x000000000040a29f in KeyboardReader::KeyboardReader (this=0x60d060)
at KeyboardReader.cpp:16
#9 0x0000000000406caa in __static_initialization_and_destruction_0
(__initialize_p=<optimized out>, __priority=<optimized out>) at
lscp.cpp:31
#10 _GLOBAL__sub_I_main () at lscp.cpp:249
#11 0x000000000040a41d in __libc_csu_init ()
#12 0x00007ffff69fbe40 in __libc_start_main () from
/lib/x86_64-linux-gnu/libc.so.6
#13 0x0000000000406e11 in _start ()
--
Patrick Shirkey
Boost Hardware Ltd
|
|
From: raf <rmo...@gm...> - 2014-02-06 22:23:42
|
You're awesome, i jumped straight to the shell !
after updating the svn repos (libgig-svn just in case and linuxsampler-svn), it fails compiling on lscp.y
any idea ? strangely i found the very same function in lscpparser.cpp
make[3]: Entering directory '/home/seijitsu/build/linuxsampler-svn/src/linuxsampler-svn/src/network'
/bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../.. -D_FORTIFY_SOURCE=2 -Wreturn-type -ffast-math -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -pthread -MT lscpparser.lo -MD -MP -MF .deps/lscpparser.Tpo -c -o lscpparser.lo lscpparser.cpp
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -D_FORTIFY_SOURCE=2 -Wreturn-type -ffast-math -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -pthread -MT lscpparser.lo -MD -MP -MF .deps/lscpparser.Tpo -c lscpparser.cpp -fPIC -DPIC -o .libs/lscpparser.o
lscp.y: In function 'bool _isRuleTerminalSymbol(int)':
lscp.y:1319:18: error: 'yyprhs' was not declared in this scope
for (int i = yyprhs[rule]; yyrhs[i] != -1; ++i)
^
lscp.y:1319:32: error: 'yyrhs' was not declared in this scope
for (int i = yyprhs[rule]; yyrhs[i] != -1; ++i)
^
Makefile:427: recipe for target 'lscpparser.lo' failed
make[3]: *** [lscpparser.lo] Error 1
Raphaël
Le 6 févr. 2014 à 21:41, Christian Schoenebeck a écrit :
> Ok, I just committed an initial version of the LSCP shell to SVN. The
> application is just called "lscp". There is also a man page.
>
> I decided to go the thin-client route, that is LSCP aware stuff being handled
> on sampler side, and the shell application is more or less just forwarding
> individual key strokes to the sampler and handling output format (color &
> printing) of the returned informations on the command line terminal. That
> should make the shell be versatile for being used successfully against various
> LinuxSampler versions, no matter what the exact LSCP version is, and keeps
> development/maintenance effort low.
>
> Current shell features:
>
> - Colored highlighting while typing (i.e. good portions bold white,
> syntactical bad portions red, if the command is complete and ready to
> be fired: green, ...).
>
> - Auto completion by tab key. The shell will also show a possible
> completion in real-time while typing. So that one does not need to
> guess when it is possible to tab-complete the command. You see it
> immediately.
>
> - Auto correction of trivial mistakes: for now this just covers auto
> converting i.e. lower case characters to upper case (if necessary,
> according to current LSCP grammar position), space characters to
> underscore characters and vice versa (also according to grammar
> position).
> In future: orthographically similar mistyped keywords might be auto
> corrected as well. Not a hard task.
>
> I actually also planned to integrate the LSCP reference into the shell. That
> is, if a certain LSCP command is identified, the shell would automatically
> show the relevant LSCP reference document section below the current command
> line (and paging the shown LSCP reference with PGUP, PGDOWN keys).
>
> However ... I have now to work on completely other stuff for a while, so this
> spare time fun is postponed for now.
>
> The Windows version of LinuxSampler is currently broken, because I used the
> POSIX termios API to get the required control over the command line terminal.
> That API does not exist on Windows. If anybody is interested in trying to fix
> this on Windows, it would be very much appreciated!
>
> That's it for now.
>
> CU
> Christian
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
|
|
From: Christian S. <sch...@li...> - 2014-02-06 22:37:05
|
On Thursday 06 February 2014 23:23:29 raf wrote: > after updating the svn repos (libgig-svn just in case and > linuxsampler-svn), it fails compiling on lscp.y any idea ? strangely i > found the very same function in lscpparser.cpp > [snip] > lscpparser.cpp -fPIC -DPIC -o .libs/lscpparser.o lscp.y: In function > 'bool _isRuleTerminalSymbol(int)': > lscp.y:1319:18: error: 'yyprhs' was not declared in this scope > for (int i = yyprhs[rule]; yyrhs[i] != -1; ++i) > ^ > lscp.y:1319:32: error: 'yyrhs' was not declared in this scope > for (int i = yyprhs[rule]; yyrhs[i] != -1; ++i) > ^ > Makefile:427: recipe for target 'lscpparser.lo' failed > make[3]: *** [lscpparser.lo] Error 1 Maybe a Bison version issue. Which Bison version are you using? The C arrays yyprhs[] and yyrhs[] are automatically generated by Bison according to the current grammar definition in src/network/lscp.y. However there is something special about them: those two arrays are not required for Bison's basic parser work, they are rather intended to be used for debugging purposes, human readable syntax errors, custom parser code and stuff like that. That's why those two arrays are embedded into C preprocessor macros in the auto generated lscpparser.cpp file by Bison. In my Bison version I just had to add #define YYDEBUG 1 to make those arrays available (I added this define in lscpparser.h). Does your Bison version need another macro maybe? CU Christian |
|
From: raf <rmo...@gm...> - 2014-02-06 23:25:45
|
Le 6 févr. 2014 à 22:37, Christian Schoenebeck a écrit : > On Thursday 06 February 2014 23:23:29 raf wrote: >> after updating the svn repos (libgig-svn just in case and >> linuxsampler-svn), it fails compiling on lscp.y any idea ? strangely i >> found the very same function in lscpparser.cpp >> > [snip] >> lscpparser.cpp -fPIC -DPIC -o .libs/lscpparser.o lscp.y: In function >> 'bool _isRuleTerminalSymbol(int)': >> lscp.y:1319:18: error: 'yyprhs' was not declared in this scope >> for (int i = yyprhs[rule]; yyrhs[i] != -1; ++i) >> ^ >> lscp.y:1319:32: error: 'yyrhs' was not declared in this scope >> for (int i = yyprhs[rule]; yyrhs[i] != -1; ++i) >> ^ >> Makefile:427: recipe for target 'lscpparser.lo' failed >> make[3]: *** [lscpparser.lo] Error 1 > > Maybe a Bison version issue. Which Bison version are you using? > > The C arrays yyprhs[] and yyrhs[] are automatically generated by Bison > according to the current grammar definition in src/network/lscp.y. However > there is something special about them: those two arrays are not required for > Bison's basic parser work, they are rather intended to be used for debugging > purposes, human readable syntax errors, custom parser code and stuff like > that. That's why those two arrays are embedded into C preprocessor macros in > the auto generated lscpparser.cpp file by Bison. In my Bison version I just > had to add > > #define YYDEBUG 1 > > to make those arrays available (I added this define in lscpparser.h). Does > your Bison version need another macro maybe? i don't know anything about bison... i wouldn't be of any help to track down the problem. my version was 3.0.1, I updated to [seijitsu@astrux linuxsampler-svn]$ bison -V bison (GNU Bison) 3.0.2 Written by Robert Corbett and Richard Stallman. but still got the same error. looking more into the configure output I can see this message with some warnings related to bison : Searching for a parser generator...OK (/usr/bin/bison -y) Generating LSCP parser... lscp.y: warning: 1801 shift/reduce conflicts [-Wconflicts-sr] lscp.y: warning: 1045 reduce/reduce conflicts [-Wconflicts-rr] lscp.y: warning: 1801 shift/reduce conflicts [-Wconflicts-sr] lscp.y: warning: 1045 reduce/reduce conflicts [-Wconflicts-rr] Done then later on, not blocking : checking for ARTS artsc - version >= 0.9.5... no *** The artsc-config script installed by ARTS could not be found *** If ARTS was installed in PREFIX, make sure PREFIX/bin is in *** your path, or set the ARTS_CONFIG environment variable to the *** full path to artsc-config. what bison version do you have ? can a 64bits system make a difference ? Raphaël |
|
From: Christian S. <sch...@li...> - 2014-02-07 17:18:15
|
On Friday 07 February 2014 00:25:35 raf wrote: > i don't know anything about bison... i wouldn't be of any help to track > down the problem. > > my version was 3.0.1, I updated to > [seijitsu@astrux linuxsampler-svn]$ bison -V > bison (GNU Bison) 3.0.2 > Written by Robert Corbett and Richard Stallman. > > but still got the same error. Yeah, I just tested it with Bison 3.0.2 and figured that those two C arrays are not automatically generated by Bison 3.x by default anymore. > looking more into the configure output I can see this message with some > warnings related to bison : > > Searching for a parser generator...OK (/usr/bin/bison -y) > Generating LSCP parser... > lscp.y: warning: 1801 shift/reduce conflicts [-Wconflicts-sr] > lscp.y: warning: 1045 reduce/reduce conflicts [-Wconflicts-rr] > lscp.y: warning: 1801 shift/reduce conflicts [-Wconflicts-sr] > lscp.y: warning: 1045 reduce/reduce conflicts [-Wconflicts-rr] > Done Not related to this problem. It just reminds us that there are a lot of ambiguities in our LSCP grammar definition. In practice does not cause any problem for us though. > then later on, not blocking : > checking for ARTS artsc - version >= 0.9.5... no > *** The artsc-config script installed by ARTS could not be found > *** If ARTS was installed in PREFIX, make sure PREFIX/bin is in > *** your path, or set the ARTS_CONFIG environment variable to the > *** full path to artsc-config. Not related to this problem. ARTS does not exist on modern systems anymore. > what bison version do you have ? I just tested with Bison 2.x in the last few days. > can a 64bits system make a difference ? No, 32 bit or 64 bit does not make a difference. I'll try to find out how to convince Bison 3 to generate the two missing C arrays. CU Christian |
|
From: Christian S. <sch...@li...> - 2014-02-08 01:05:02
|
On Friday 07 February 2014 17:19:07 Christian Schoenebeck wrote: > > my version was 3.0.1, I updated to > > [seijitsu@astrux linuxsampler-svn]$ bison -V > > bison (GNU Bison) 3.0.2 > > Written by Robert Corbett and Richard Stallman. > > > > but still got the same error. > > Yeah, I just tested it with Bison 3.0.2 and figured that those two C arrays > are not automatically generated by Bison 3.x by default anymore. [snip] > I'll try to find out how > to convince Bison 3 to generate the two missing C arrays. Fixed in latest SVN version. Should compile without errors now. CU Christian |
|
From: raf <rmo...@gm...> - 2014-02-08 14:23:26
|
Excellent, compiles fine without errors (some warnings about deprecated midi functions) the sampler engine is running ok, but strangely the lscp shell complains that the engine is too old, although they have just been compiled together from the latest svn version... LinuxSampler 1.0.0.svn23 [seijitsu@astrux ~]$ lscp LSCPServer: Client connection established on socket:4. Error: sampler too old, it does not support shell instructions LSCPServer: Client connection terminated on socket:4. Raphaël Le 8 févr. 2014 à 01:05, Christian Schoenebeck a écrit : > On Friday 07 February 2014 17:19:07 Christian Schoenebeck wrote: >>> my version was 3.0.1, I updated to >>> [seijitsu@astrux linuxsampler-svn]$ bison -V >>> bison (GNU Bison) 3.0.2 >>> Written by Robert Corbett and Richard Stallman. >>> >>> but still got the same error. >> >> Yeah, I just tested it with Bison 3.0.2 and figured that those two C arrays >> are not automatically generated by Bison 3.x by default anymore. > [snip] >> I'll try to find out how >> to convince Bison 3 to generate the two missing C arrays. > > Fixed in latest SVN version. Should compile without errors now. > > CU > Christian > |
|
From: Christian S. <sch...@li...> - 2014-02-08 17:02:43
|
On Saturday 08 February 2014 15:23:17 you wrote: > the sampler engine is running ok, but strangely the lscp shell complains > that the engine is too old, although they have just been compiled together > from the latest svn version... > > LinuxSampler 1.0.0.svn23 > > [seijitsu@astrux ~]$ lscp > LSCPServer: Client connection established on socket:4. > Error: sampler too old, it does not support shell instructions > LSCPServer: Client connection terminated on socket:4. I am pretty sure you are running another, old version of LinuxSampler then. Try starting the sampler directly from the source build dir like this: src/linuxsampler and accordingly the shell directly from the source dir: src/shell/lscp That should do it. If that worked fine without that "too old" error, then you probably still had an old version of LinuxSampler installed somewhere, i.e. under /usr/local or you simply did not install the new version at all after compiling or did not restart linuxsampler after compiling and installing. CU Christian |
Thanks for helping keep SourceForge clean.
X