linuxsampler-devel — This list is for discussing LinuxSampler development issues and ideas

Re: [Linuxsampler-devel] LSCP shell

[Christian S. <sch...@li...>]

On Friday 07 February 2014 17:25:27 Patrick Shirkey wrote:
> On Sat, February 8, 2014 1:01 am, Christian Schoenebeck wrote:
> > On Friday 07 February 2014 08:54:53 Patrick Shirkey wrote:
> >> It compiles fine for me on debian-7.0 64bit. However it crashes on start
> > 
> >> and I get this backtrace:
> > Does the attached patch fix it?
> 
> Moves it slightly but looks to be the same error.  I'm running lscp on a
> headless machine via ssh terminal in case that has any influence.

No, that's irrelevant.

It rather seems static variables of the application are initialized in a 
different order on your machine, but that order can be different on any 
system. Try the attached patch, it should fix it.

CU
Christian

Re: [Linuxsampler-devel] LSCP shell

[Patrick S. <psh...@bo...>]

On Sat, February 8, 2014 1:01 am, Christian Schoenebeck wrote:
> On Friday 07 February 2014 08:54:53 Patrick Shirkey wrote:
>> It compiles fine for me on debian-7.0 64bit. However it crashes on start
>> and I get this backtrace:
>
> Does the attached patch fix it?
>


Moves it slightly but looks to be the same error.  I'm running lscp on a
headless machine via ssh terminal in case that has any influence.


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  0x0000000000408ade 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=0x60d420, __v=...) at
/usr/include/c++/4.7/bits/stl_tree.h:1295
#3  0x0000000000408c0b 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=0x60d420, __position=..., __v=...) at
/usr/include/c++/4.7/bits/stl_tree.h:1348
#4  0x000000000040812c in insert (__x=..., __position=..., this=0x60d420)
at /usr/include/c++/4.7/bits/stl_map.h:576
#5  operator[] (__k=<optimized out>, this=0x60d420) at
/usr/include/c++/4.7/bits/stl_map.h:458
#6  _newTermios () at TerminalCtrl.cpp:31
#7  TerminalCtrl::now () at TerminalCtrl.cpp:100
#8  0x000000000040a32f in KeyboardReader::KeyboardReader (this=0x60d100)
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 0x000000000040a4ad in __libc_csu_init ()
#12 0x00007ffff69fbe40 in __libc_start_main () from
/lib/x86_64-linux-gnu/libc.so.6
#13 0x0000000000406e31 in _start ()





--
Patrick Shirkey
Boost Hardware Ltd

Re: [Linuxsampler-devel] LSCP shell

[Christian S. <sch...@li...>]

On Friday 07 February 2014 08:54:53 Patrick Shirkey wrote:
> It compiles fine for me on debian-7.0 64bit. However it crashes on start
> and I get this backtrace:

Does the attached patch fix it?

CU
Christian

Re: [Linuxsampler-devel] LSCP shell

[Patrick S. <psh...@bo...>]

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

Re: [Linuxsampler-devel] LSCP shell

[raf <rmo...@gm...>]

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

Re: [Linuxsampler-devel] LSCP shell

[Christian S. <sch...@li...>]

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

Re: [Linuxsampler-devel] LSCP shell

[raf <rmo...@gm...>]

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

Re: [Linuxsampler-devel] LSCP shell

[Christian S. <sch...@li...>]

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

Re: [Linuxsampler-devel] LSCP shell

[Kevin U. <kv...@fr...>]

> 
> 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
> 

Re: [Linuxsampler-devel] LSCP shell

[Patrick S. <psh...@bo...>]

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

[Linuxsampler-devel] LSCP shell

[Christian S. <sch...@li...>]

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

[Linuxsampler-devel] multiple MIDI input ports per sampler channel

[Christian S. <sch...@li...>]

Hi everybody!

I just added support for multiple MIDI input ports per sampler channel.

	SVN revision: 2500
	LinuxSampler version: 1.0.0.svn25
	LSCP version: 1.6 (new)

Until now one could only use exactly one MIDI input port per sampler channel.
Under certain conditions it makes sense however to be able to connect more
than MIDI input port on the same sampler channel (without being forced to
create new sampler channels just for that). Here is the full SVN diff:

	http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=2500

Since this is a design change, I had to modify major parts of the sampler. New
C++ API methods were added, old ones marked as being deprecated. However full
API and behavior backward compatibility *should* be provided. So your
graphical frontend(s) and/or LSCP scripts *should* still work as usual. If
something is not working anymore, then please tell me!

I added the following new LSCP commands (LSCP v1.6):

	ADD CHANNEL MIDI_INPUT <sampler-channel> <midi-device-id> [<midi-input-port>]
	http://www.linuxsampler.org/api/draft-linuxsampler-protocol.html#ADD%20CHANNEL%20MIDI_INPUT

	REMOVE CHANNEL MIDI_INPUT <sampler-channel> [<midi-device-id> [<midi-input-port>]]
	http://www.linuxsampler.org/api/draft-linuxsampler-protocol.html#REMOVE%20CHANNEL%20MIDI_INPUT

	LIST CHANNEL MIDI_INPUT <sampler-channel>
	http://www.linuxsampler.org/api/draft-linuxsampler-protocol.html#LIST%20CHANNEL%20MIDI_INPUTS

As with the C++ API changes, the old LSCP commands (and old response fields of
"GET CHANNEL INFO") are marked as deprecated, but still there and should
provide full behavior backward compatibility. If not, then it is a bug and
please tell me!

I also thought about making the MIDI channel setting individual for each MIDI
port connected. However I found that its use case would be too exotic and
would introduce a usability nightmare for users. So I decided to leave only
one single MIDI channel setting for all MIDI input ports connected to one
sampler channel.

Implementation detail: if more than one MIDI input port is connected to one
SamplerChannel/EngineChannel, then a mutex.lock() is used for each MIDI event
coming in to protect the input MIDI RingBuffer against concurrent input. If
there is only one MIDI input port, then no mutex.lock() is used. The Mutex
lock is a bit undesired, it could be avoided by changing the design a bit
more. But for now it should probably be OK.

CU
Christian

Re: [Linuxsampler-devel] first impression and questions

[Christian S. <sch...@li...>]

On Tuesday 07 January 2014 04:56:01 David Jaffe wrote:
> Second, I have a number of naive questions; please indulge me…

Don't worry about that. The code base became a bit complex with the years, so 
it always takes a bit to get used to it. So it is normal to have plenty of 
questions about it.

> I gather there is, for each engine, an audio thread, a disk thread, and an
> instrument loader thread.  Is that right?  I'm wondering if it's been
> considered to allow multiple parallel voices to be computed in separate
> threads to take advantage of machines with many cores? Or is the
> disk-reading speed the limiting factor? (probably depends somewhat on the
> disk?)

Yes, this feature was somewhat planned years ago, but then there were other 
priorities which we thought were more important, especially since there is a 
workaround for users to gain SMP support: creating one audio device per CPU 
core. So you could i.e. create 4 JACK audio device instances on a system with 
4 CPU cores. Or if you multiple disks attached to your system and want to 
leverage parallel reading, then you could use the same trick.

It works, but is a bit inconvenient for the user of course. Since he has the 
burden to control this. Especially he has to decide which sampler part 
("sampler channel") shall be connected with which audio device instance. So he 
has to think about how to distribute the load among the parts to achieve the 
best result.

> Is there one engine per audio device? Or can multiple engines talk to the
> same device? (Can more than one engine be active at a time?)

There is always exactly one sampler engine instance per audio device instance. 
And each sampler engine instance in turn has its own disk thread instance. 
This happens transparently for the user. For example: the user creates 10 
sampler parts ("sampler channels") but has not attached an audio device 
attached to any of this sampler channels yet. In this situation there is no 
sampler engine instance yet.
Then the user creates an audio device and connects it to all 10 sampler 
channels, the sampler will automatically create exactly one sampler engine 
which are now shared by the 10 sampler channels.
Then the user creates another audio device and attaches it to the first 
sampler channel. This will cause a new sampler engine instance to be created 
for the first sampler channel, where as the other 9 sampler channels still 
share the sampler engine instance. And so on.

There is just one addition: an engine instance obviously just provides support 
for exactly one sampler format. So if you have i.e. 4 sampler channels with 
the "gig" format being set and 3 sampler channels with the "SFZ" format set 
and yet another 3 sampler channels with the "SoundFont2" format set, and all 
10 sampler channels being connected to one audio device, then there there will 
be 3 engine instances, since you use 3 different formats. So obviously the 10 
sampler channels cannot share one engine instance in that scenario.

> It looks like the code defines gigasampler format in terms of DLS...true? 
> If so, was this originally a DLS sampler?  Is giga format a superset of
> DLS?

The GigaSampler/GigaStudio format was designed based on DLS. There were things 
added, but also informations from DLS removed / ignored for the gig format. So 
you can't truly say .gig is a real superset of DLS. It just comes from there, 
kind of. However since there are similarities between, it made sense in libgig 
to split the libgig code in 3 parts:

	* RIFF classes: RIFF is used on the lowest level of DLS files, gig files, 
	  but many other popular file formats like .wav, .avi and more). You 
	  could say RIFF is something like XML, however in a compact and 
	  efficient binary format.

	* DLS classes: Implements support for sounds in DLS sounds. Theoretically 
	  these could be used directly, i.e. for yet another sampler engine in 
	  LinuxSampler, however since this format never really became popular, it 
	  would not make sense.

	* gig classes: Mostly derived from the DLS classes and extended for the 
	  Gigasampler/GigaStudio specific stuff.

And to answer you other question about DLS: the sampler never supported DLS, 
simply because there were always just a hand full of DLS files out there. 
There were "so many" of them, that at one day Josh Green and I realized that 
we were using the same DLS file for testing our DLS parsing code (Josh Green 
also wrote a sampler format file library called libinstpatch - not used in 
this project though).

> I didn't see the SFZ source, is that available separately?  Also, the web

All sources regarding SFZ are in the LinuxSampler code base. You might be 
confused about the fact that SFZ is a text based, human readable format. So 
there is not a complex format parsing library (like i.e. libgig) required for 
reading SFZ files.

> page lists the Akai engine as "not started yet" in the "LS development
> road map."  Does that mean it's not available at all at this point?

There is no support for Akai sounds right now in the sampler.

When the project kicked off at the end of 2002, we were discussing which 
sampler format to use first. So during that discussion I ported libakai to 
Linux. That library does the parsing job, allowing to access Akai sound images 
(similar to libgig for the Giga and SF2 format). I think we should have those 
modified sources somwhere. There is also the original project on SourceForge, 
however I don't know if my Linux/POSIX patches were ever applied there.

Since the Giga format was much more attractive in 2002, we decided to go that 
route instead and left Akai on the agenda for somewhere in future. However 
nowadays the Akai format is so outdated, that it is probably not worth 
spending time on implementing support for it in LinuxSampler. There are 
nowadays other sampler formats which would be more interesting to be added. 
But hey, there is also still a lot to do regarding SFZ support ...

CU
Christian

[Linuxsampler-devel] first impression and questions

[David J. <da...@ua...>]

I just started looking at the LS sources and am trying to get a sense of the design. 

First of all, congrats, it looks quite clean!

Second, I have a number of naive questions; please indulge me…   

I gather there is, for each engine, an audio thread, a disk thread, and an instrument loader thread.  Is that right?  I'm wondering if it's been considered to allow multiple parallel voices to be computed in separate threads to take advantage of machines with many cores? Or is the disk-reading speed the limiting factor? (probably depends somewhat on the disk?)

Is there one engine per audio device? Or can multiple engines talk to the same device? (Can more than one engine be active at a time?)

It looks like the code defines gigasampler format in terms of DLS...true?  If so, was this originally a DLS sampler?  Is giga format a superset of DLS? 

I didn't see the SFZ source, is that available separately?  Also, the web page lists the Akai engine as "not started yet" in the "LS development road map."  Does that mean it's not available at all at this point?


Thanks very much,

David
http://www.jaffe.com

[Linuxsampler-devel] dealing with EG envelopes

[Raphaël M. <rmo...@gm...>]

hello,

i'm trying to figure out how egN_xxx envelopes do work.

So far i've been able to apply a volume envelope of one second with
two points using
eg8_time0=0 eg8_level0=1 //first point of envelope
eg8_time1=1 eg8_level1=0 //second point of envelope
eg8_volume=0 //apply envelope to region volume

Now what i want to do is :
1) have a moving release point
i'm sure i can use the egN_timeX_onccY opcode to move the second
point, but i've not figured out how "modulated byt the CC" is
affecting the given value.
For example here I define a value of 1, how is this number being
modulated by the midi CC range of 0>127 ??

2) the region to end (completely stop playing) at the end of the envelope.
a volume envelope is just volume, so to have the region to end, i
should use the egN_sustain i think.
So I tried adding eg8_sustain=1 to define the second point as release
point, but the region is not ending after the one second duration
defined, only the volume is (i'm not detailing the complete
environment sorry, but i want to focus on the envelope methods)
Do i need some other opcode for the region to end at the end of the envelope ?

Thanks for advice,
Raphaël

[Linuxsampler-devel] Crash in liblinuxsampler-3.dll (Windows port)

[Jaime T <eno...@gm...>]

Hi everyone. I'm trying to get linuxsampler running on my Windows XP
(32-bit) box. The install seems to run OK and I can start the LS
stand-alone backend, and communicate with it using putty in raw mode.

LIST AVAILABLE_AUDIO_OUTPUT_DRIVERS
returns:
ASIO

but when I run:
CREATE AUDIO_OUTPUT_DEVICE ASIO
the backend crashes.

According to the console output, the version of LinuxSampler is
1.0.0.svn23 (which I installed using
http://download.linuxsampler.org/packages/win32/snapshots/linuxsampler_20130916_setup.exe).
As per the documentation, I'm using ASIO4ALL version 2.7, and I've
checked that ASIO4ALL works ok by using ASIOSigGen (and everything
there is ok). When I pass "CREATE AUDIO_OUTPUT_DEVICE ASIO" to the LS
server, I get a small window which says "linuxsampler.exe has
encoutered a problem and needs to close. We are sorry for the
inconvenience." When I click on "To see what data this error report
contains, click here", the next window shows:

AppName: linuxsampler.exe
AppVer: 0.0.0.0
ModName: liblinuxsampler-3.dll
ModVer: 0.0.0.0
Offset: 001f7504

I've also just tried running:

GET AUDIO_OUTPUT_DRIVER INFO ASIO

and that results in the same kind of crash.

Does anyone know what I can do to help debug this? With kind regards,

Jaime

Re: [Linuxsampler-devel] Build fails for LinuxSampler on Ubuntu Studio 10.04

[Christian S. <sch...@li...>]

On Monday 09 September 2013 19:57:37 David Bolton wrote:
> However, I get the following error trying to build linuxsampler (by running
> dpkg-buildpackage -rfakeroot -b in the linuxsampler directory). I'm using
> the latest SVN sources.
> 
> <http://bb.linuxsampler.org/viewtopic.php?uid=424&f=6&t=768&start=0&sid=a67
> 9d7b633839fb0d79979038e10435f#>InstrumentResourceManager.cpp:903:9: error:
> 'class gig::File' has no member named 'GetFileName'
> For the full log see http://pastebin.com/JBDC2UkB

You are building against an ancient version of libgig. First build *and* 
install the latest version of libgig from SVN, then build the sampler. Also 
make sure you don't have another manually compiled libgig version under 
/usr/local

More here:

	http://linuxsampler.org/debian.html

CU
Christian

[Linuxsampler-devel] Build fails for LinuxSampler on Ubuntu Studio 10.04

[David B. <dav...@gm...>]

Since there aren't any packages of LinuxSampler for recent versions of
Ubuntu, I've been trying to build LS for over a month.

However, I get the following error trying to build linuxsampler (by running
dpkg-buildpackage -rfakeroot -b in the linuxsampler directory). I'm using
the latest SVN sources.

<http://bb.linuxsampler.org/viewtopic.php?uid=424&f=6&t=768&start=0&sid=a679d7b633839fb0d79979038e10435f#>InstrumentResourceManager.cpp:903:9:
error: 'class gig::File' has no member named 'GetFileName'
For the full log see http://pastebin.com/JBDC2UkB

For what it is worth I was able to build and install the libgig packages.

I'm looking for a usable synthesizer for playing MIDI files in Ardour. The
Calf FluidSynth plugin is fine for one or two MIDI tracks but for any more
than that it starts crashing (due to memory overload). I've heard that
LinuxSampler is the only reliable option, but unfortunately I haven't had
any success with it on Ubuntu Studio 10.04.

David

Re: [Linuxsampler-devel] Links at bugs.linuxsampler.org require updating

[Christian S. <sch...@li...>]

On Thursday 11 July 2013 01:20:55 Aviv wrote:
> I'm just letting you know that the links provided at
> bugs.linuxsampler.orgrequire updating. Firefox gives a "This
> Connection is Untrusted" error, due
> to an expired certificate. 

Yes, because our SSL certificates have expired and need to be renewed. You 
just need to accept it as exception in Firefox for now.

> The HTTPS should be removed, it is not
> necessary. I suppose I could simply do it if you provide me with the
> necessary privileges.

And using unencrypted logins instead? I rather bear with doing 2 clicks in the 
web browser to ignore the certificate expiration instead of sending logins in 
plain text.

We currently have to wait for Benno coming back from his holidays, because 
only he can acquire the new SSL certificates. As soon as he'll be back, we 
update the SSL certificates, which is pretty easy and fast. But thanks for 
offering your help!

CU
Christian

[Linuxsampler-devel] Links at bugs.linuxsampler.org require updating

[Aviv <av...@gm...>]

Hi everyone,

I'm just letting you know that the links provided at
bugs.linuxsampler.orgrequire updating. Firefox gives a "This
Connection is Untrusted" error, due
to an expired certificate. The HTTPS should be removed, it is not
necessary. I suppose I could simply do it if you provide me with the
necessary privileges.

Re: [Linuxsampler-devel] SFZ2 reference document availability

[S. C. C. <s_c...@ho...>]

Thanks. Even un-updated, it is still helpful.

-~Chris

On 06/19/2013 04:56 AM, Anders Dahnielson wrote:
> Google changed the public link to the nowadays extremely unupdated doc:
>
> https://docs.google.com/document/d/1UxPar5toq2uDrU4Gkf4jOGzV3ic-CAoRPo0cWE6xino/pub
>
>
> 2013/6/15 S. Christian Collins <s_c...@ho...
> <mailto:s_c...@ho...>>
>
>     The SFZ2 reference document
>     <https://docs.google.com/Doc?docid=0AVrDa5LNWylnZGZ6ejk4eHRfNDVjbmsyd3Zmag>
>     that is linked on the LinuxSampler documentation page
>     <http://www.linuxsampler.org/documentation.html> appears to
>     require permission for viewing. I remember viewing this document
>     in the past. Is there any reason why this information is no longer
>     public?
>
>     -~Chris
>
>     ------------------------------------------------------------------------------
>     This SF.net email is sponsored by Windows:
>
>     Build for Windows Store.
>
>     http://p.sf.net/sfu/windows-dev2dev
>     _______________________________________________
>     Linuxsampler-devel mailing list
>     Lin...@li...
>     <mailto:Lin...@li...>
>     https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
>
>
>
> -- 
> *Anders Dahnielson*
> <an...@da... <mailto:an...@da...>>

Re: [Linuxsampler-devel] SFZ2 reference document availability

[Anders D. <an...@da...>]

Google changed the public link to the nowadays extremely unupdated doc:

https://docs.google.com/document/d/1UxPar5toq2uDrU4Gkf4jOGzV3ic-CAoRPo0cWE6xino/pub


2013/6/15 S. Christian Collins <s_c...@ho...>

>  The SFZ2 reference document<https://docs.google.com/Doc?docid=0AVrDa5LNWylnZGZ6ejk4eHRfNDVjbmsyd3Zmag>that is linked on the LinuxSampler
> documentation page <http://www.linuxsampler.org/documentation.html>appears to require permission for viewing. I remember viewing this document
> in the past. Is there any reason why this information is no longer public?
>
> -~Chris
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
>


-- 
*Anders Dahnielson*
<an...@da...>

[Linuxsampler-devel] SFZ2 reference document availability

[S. C. C. <s_c...@ho...>]

The SFZ2 reference document
<https://docs.google.com/Doc?docid=0AVrDa5LNWylnZGZ6ejk4eHRfNDVjbmsyd3Zmag>
that is linked on the LinuxSampler documentation page
<http://www.linuxsampler.org/documentation.html> appears to require
permission for viewing. I remember viewing this document in the past. Is
there any reason why this information is no longer public?

-~Chris

Re: [Linuxsampler-devel] compiling nki.c with zlib 1.2.5

[Nick H. <nic...@gm...>]

thanks everyone (Christian, Frank)


2013/5/31 Christian Schoenebeck <sch...@li...>

> On Friday 31 May 2013 13:24:32 Nick Humphrey wrote:
> > what am i doing wrong?
> >
> > cc -c nki.c
>
> -c creates an object file, which is not an executable, but rather an
> intermediary object, which has to be linked to a final executable.
>
> By leaving off "-c" the compiler will create an executable binary instead.
> However in this particular case of nkitool, you also need to link zlib to
> the
> binary ("-lz" usually).
>
> Please note that the current version of nkitool only works for Kontakt
> version
> < 4.2.2, since the nki file format changed. More on:
>
>         http://www.linuxsampler.org/nkitool/
>
> CU
> Christian
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>



-- 
Check out my music and let me know if you like any of it:
https://soundcloud.com/nickleus

Re: [Linuxsampler-devel] compiling nki.c with zlib 1.2.5

[Christian S. <sch...@li...>]

On Friday 31 May 2013 13:24:32 Nick Humphrey wrote:
> what am i doing wrong?
> 
> cc -c nki.c

-c creates an object file, which is not an executable, but rather an 
intermediary object, which has to be linked to a final executable.

By leaving off "-c" the compiler will create an executable binary instead. 
However in this particular case of nkitool, you also need to link zlib to the 
binary ("-lz" usually).

Please note that the current version of nkitool only works for Kontakt version 
< 4.2.2, since the nki file format changed. More on:

	http://www.linuxsampler.org/nkitool/

CU
Christian