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

Re: [Linuxsampler-devel] script support

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

On Thursday 22 May 2014 16:52:03 David Olofson wrote:
> Compatibility would of course be very nice in this case. Not really
> familiar with the Kontakt scripting language, so I can't tell how much
> work it would be to write a parser for it - 

There are various kick start introductions for the "KSP" (Kontakt Script 
Processor) script language. I.e.:

http://www.askaudiomag.com/articles/introduction-to-scripting-in-kontakt-
part-1

Also a lot of videos out there. You basically just use one of the defined 
event callback functions for two main purposes:
1) reacting on and processing MIDI events and
2) adding custom GUI controls (dials, input fields, labels, buttons) and write 
event handlers for their UI widget events.

For now I am mostly interested to implement aspect 1) (MIDI processing).

One thing I find suboptimal with KSP is that it is very focused on using 
function calls all over the place. For example if you want to trigger some 
note when a key is released, you would write something like:

on release
  declare $n := 42
  play_note($n, 127, 0, 0)
end

So as a user you need to remember the sequence of function arguments for 
play_note() (or you need to lookup in the manual each time). Using a rather 
more object oriented approach like:

on release
  Note $n
  $n.note := '42
  $n.velocity := 127
  //optional:
  //n.offset := 0
  //n.duration := 0
  $n.trigger()
end

would probably be more intuitive and easier to remember. Modifying incoming 
MIDI events is also a bit odd, with KSP it is like this:

on note
  if ($EVENT_VELOCITY > 100)
    ignore_event($EVENT)
  else
    change_note($EVENT, $EVENT_NOTE + 12)
    change_velo($EVENT, $EVENT_VELOCITY / 2)
  end if
end

which IMO I would found more intuitive like:

on note
  if ($NOTE.velocity > 100)
    $NOTE.ignore()
  else
    $NOTE.note += 12
    $NOTE.velocity /= 2
  end if
end

There are 3 different scopes for variables in KSP by the way. You declare 
global variable in the "init" callback:

on init
  declare $myGlobalVariable := 10
  declare %someGlobalArray[5] = ( 2, 3, 5, 7, 11 )
end

You can then access those global variables from any other callback function. 
Whereas if you declare a variable in some other callback like:

on note
  declare $i := 0
end

Then this variable by default is rather something like a static variable, 
bound in the namespace of that "on note" function, *but* shared by all 
callbacks that process that particular callback function! So you might 
interfere with other instances running this callback "at the same time". Even 
though KSP only has one thread, there is a wait() function which pushes the 
respective function execution on a wait queue, thus rendering a scenario that 
you can compare causally to the effect as if multiple instances of the same 
callback function were executing in parallel.

That's why KSP has a third variable scope as well:

on note
  declare polyphonic $i := 0
end

In this case such a "polyphonic" variable is not shared, it is bound to the 
event which triggered the callback function. So no other instance of the same  
callback can modify variable $i in between, preventing you from any trouble. 
However from memory management point of view this case is a bit problematic. 
Because you have no information at parse time how many instances of the 
callback might be triggered in parallel. I am not sure what the best solution 
would be to implement this case (from memory management POV). Do you have a 
solid idea?

> but that's basically how
> to go about it; write an alternative compiler that issues bytecode for
> an existing VM. A VM like this is basically just a high level virtual
> CPU, and not really tied to any specific language.

Probably, but in fact I would like to avoid opening the door for numerous 
flavors of high level script languages used in the sampler right now. Because 
it might create confusion among users when learning scripting with the sampler 
and/or by reading scripts of other people, if everybody is using a different 
language on top that is. So I would prefer to pick one single language flavor 
that should remain alone in this flavor (for quite some time at least).

> EEL exists mostly because I couldn't find anything like it. I looked
> into subverting Lua to suit my needs (replacing the GC, most
> critically), but the Lua community showed virtually no interest in it
> (not really needed, even for <100 Hz game scripting), so I would have
> been completely on my own with it - and I'd rather be in that
> situation with code that I know inside out.

Yes, I saw you went a bit deeper with EEL than what we probably need to 
achieve right now. From what you saw above, the typical use case for the 
script language in a sampler is event handling once in a while. Not at high 
frequencies. You are even defining tight DSP stuff with EEL if I saw it 
correctly. That's already beyond the scope what we need right now.

> For something really simple, you could look at the Audiality 2
> scripting engine (not physically related to EEL), but that's a small,
> domain specific language that's somewhat tied to the design of the
> audio engine. Apart from being massively microthreaded with message
> passing, it's a really small and simple language.

Why is it called "Extensible" by the way? What is the particular extensible 
aspect of EEL?

> > [...Bison and stuff...]
> 
> Not sure about parser and lexer generators, really... These tools only
> solve a small, simple part of the problem - and they're not even
> particularly good at dealing with some types of languages. I prefer
> just coding it all in plain C. Fewer tools to depend on, which is
> particularly nice when porting and cross-compiling! :-)

Well, I have a favor for compiler-compiler. You work with them at a more 
intuitive and compact level, they keep you safe from typical manual parser 
programming mistakes and can safe you a lot of time and stress for languages 
which grow in time.

> > Do you think that is necessary for the use case in the sampler?
> 
> Not strictly, but even disregarding raw speed, interpreting a proper
> scripting language from source in a realtime safe manner is going to
> be hairy. The normal, easy way of coding a parser involves deeply
> recursive code, associative arrays and other nasty things that are
> hard to do right in a realtime system.

Yeah, I already dropped the idea about interpreting script source in real-
time. We need some intermediary layer anyway. So we would not safe efforts by 
parsing on each event in real-time.

CU
Christian

Re: [Linuxsampler-devel] script support

[David O. <da...@ol...>]

On Wed, May 21, 2014 at 4:43 PM, Christian Schoenebeck
<sch...@li...> wrote:
> On Wednesday 21 May 2014 15:05:53 David Olofson wrote:
>> Well, having written two scripting engines for realtime applications,
>> one of which evolved as part of an audio engine:
>>
>> http://eelang.org
>> http://audiality.org
[...]
>
> Yes, we talked about this issue years ago, since you already had that in
> place. Using your EEL as basis for a script language might be an interesting
> option.
>
> So far I considered taking Kontakt's script language as basis for the actual
> language (with minor adjustments/extensions here and there that might be
> necessary for the GIG format for example). Which would bring the advantage
> that users could recycle their scripts from Kontakt instruments. Kontakt's
> script language also seems to have an overall reasonable set of
> functionalities that could be sufficient even for very sophisticated purposes.
> That would mean however that a lot of stuff would need to be adjusted in EEL.

Compatibility would of course be very nice in this case. Not really
familiar with the Kontakt scripting language, so I can't tell how much
work it would be to write a parser for it - but that's basically how
to go about it; write an alternative compiler that issues bytecode for
an existing VM. A VM like this is basically just a high level virtual
CPU, and not really tied to any specific language.


> Or does anybody have another good suggestion for an existing script language
> that might be used as basis for such a language for the sampler except of
> Kontakt's one?

EEL exists mostly because I couldn't find anything like it. I looked
into subverting Lua to suit my needs (replacing the GC, most
critically), but the Lua community showed virtually no interest in it
(not really needed, even for <100 Hz game scripting), so I would have
been completely on my own with it - and I'd rather be in that
situation with code that I know inside out.

For something really simple, you could look at the Audiality 2
scripting engine (not physically related to EEL), but that's a small,
domain specific language that's somewhat tied to the design of the
audio engine. Apart from being massively microthreaded with message
passing, it's a really small and simple language.


> [...Bison and stuff...]

Not sure about parser and lexer generators, really... These tools only
solve a small, simple part of the problem - and they're not even
particularly good at dealing with some types of languages. I prefer
just coding it all in plain C. Fewer tools to depend on, which is
particularly nice when porting and cross-compiling! :-)


> If I got it correctly, in EEL you are using bytecode and an intermediate
> translation layer.

Sort of... EEL compiles to bytecode, which runs on a custom VM - just
like Lua. The compiler is included with the VM.

The EEL VM can be compiled with a traditional switch() dispatcher, or
computed gotos (switch() results in ~99% mispredictions on most CPUs),
but there's no JIT or native compiler - yet. (I'm looking into using
LLVM to generate native code, asm.js and whatnot, both "live" and
build time.)


> Do you think that is necessary for the use case in the sampler?

Not strictly, but even disregarding raw speed, interpreting a proper
scripting language from source in a realtime safe manner is going to
be hairy. The normal, easy way of coding a parser involves deeply
recursive code, associative arrays and other nasty things that are
hard to do right in a realtime system.


-- 
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.--- Games, examples, libraries, scripting, sound, music, graphics ---.
|   http://consulting.olofson.net          http://olofsonarcade.com   |
'---------------------------------------------------------------------'

Re: [Linuxsampler-devel] script support

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

Hello,
I would love to have a scripting engine on LS !
Recently i've been working hard to create a SFZ drum preset for live use,
and the hihat escpecially cannot be done as i want without scripting.
So i need to use either mididings or puredata to trigger special events
like "pedal is going down" or "pedal is going up" and do tricky sfz layouts
to achieve realistic player's sensation.
Having an embedded scripting in LS would be of great help here, and also
help in realtime treatment of these events.
I have no preference for a language, but definately interested !
Raphaël
Le 21 mai 2014 14:27, "Christian Schoenebeck" <sch...@li...>
a écrit :

> Hi list!
>
> I am currently thinking about whether it would make sense to add real-time
> scripting support to LS. Something like Kontakt already provides. A set of
> event handlers you can write and commands you can trigger by function
> calls. I
> would like to use it as extension to the GIG engine, but it could
> theoretically also be used for the other engines (SFZ and SF2).
>
> In the gig format there are so called "MIDI rules". But as far as I can see
> it, they are very limited.
>
> Example: I currently have a string ensemble instrument where I would like
> to
> have staccato sounds automatically being triggered if aftertouch passed a
> certain level. That way I can i.e. play and hold string chords with both
> hands, and by increasing pressure on the keys once in a while I can trigger
> other sounds again and again without having to release any key.
>
> Sounds like a job for the so called "control trigger MIDI rule". But in the
> way it was implemented GigaStudio 4 there are four restrictions that
> prevent
> me doing so:
>
> 1. Those "control trigger midi rules" only support CCs, not aftertouch.
> 2. As far as I can see it there is a maximum of 32 triggers, thus I could
> use
>    those staccato sounds only on a key range of a bit more than 2 octaves.
> 3. Those trigger rules have no concept for distinguishing whether the sound
>    was triggered by a MIDI rule or normally/directly by the musician. So
> all I
>    could do is triggering another string ensemble note, but not a staccato
>    note with such MIDI rules. There is the so called "smart MIDI"
> dimensions,
>    but as far as I can see it, it is restricted to other MIDI rules like
>    legato, but not supposed to be used for the trigger MIDI rule.
> 4. As far as I can see it, you can only use one MIDI rule type per
> instrument.
>    So if you are using this "controller trigger MIDI rule" then you are not
>    supposed to use i.e. the "legato MIDI rule".
>
> Obviously those restrictions could be hacked by adding LinuxSampler's own
> minor custom extensions on GigaStudios original MIDI rules concept. But
> does
> it make sense? I mean one would probably reach another restriction with
> those
> MIDI rules soon and various use cases that would not be covered by them,
> and
> we would be back at point one.
>
> Thoughts?
>
> CU
> Christian
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] script support

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

On Wednesday 21 May 2014 15:05:53 David Olofson wrote:
> Well, having written two scripting engines for realtime applications,
> one of which evolved as part of an audio engine:
> 
> http://eelang.org
> http://audiality.org

Yes, we talked about this issue years ago, since you already had that in 
place. Using your EEL as basis for a script language might be an interesting 
option.

So far I considered taking Kontakt's script language as basis for the actual 
language (with minor adjustments/extensions here and there that might be 
necessary for the GIG format for example). Which would bring the advantage 
that users could recycle their scripts from Kontakt instruments. Kontakt's 
script language also seems to have an overall reasonable set of 
functionalities that could be sufficient even for very sophisticated purposes. 
That would mean however that a lot of stuff would need to be adjusted in EEL.

Or does anybody have another good suggestion for an existing script language 
that might be used as basis for such a language for the sampler except of 
Kontakt's one?

So before you wrote your Email today, I was considering using 1) Bison as 
compiler compiler (for automatically translating the script language grammar 
definition into parser tables, which is done only when the sampler source code 
is compiled) and 2) using a custom parser skeleton C++ code (instead of 
Bison's default skeleton parser) which processes the Bison generated parser 
tables and would take care about real-time safe memory management etc. That 
might be faster to achieve than adjusting EEL, no? Do you see some drawback of 
this approach?

If I got it correctly, in EEL you are using bytecode and an intermediate 
translation layer. Do you think that is necessary for the use case in the 
sampler? That would be an important issue to decide. The current use cases 
that come to my mind right now, are just rather simple scripts that are 
executed when a MIDI event arrives. I obviously haven't tested nor benchmarked 
it, but it could be possible that parsing a script on demand (without an 
intermediate layer), right on such events, could even be sufficient without 
encountering overall performance impacts. And in the instrument files it would 
probably even make sense to just store the scripts in the script language's 
source code form (instead of bytecode), in order to avoid problems with script 
engine backend changes as far as possible.

> A traditional modular, or worse, hardwired design tends to call for
> countless features - and you still keep running into things that are
> awkward or impossible to do without adding even more features. I think
> that's a dead end with the kind of complexity and dynamics we want
> from synths and audio engines these days. IMHO, hardwired features are
> for performance or convenience - not core functionality.

Exactly.

> The downside? Well, a scripting language isn't the best user interface
> for non-programmers. One way to deal with that might be to think of
> the scripting as an intermediate level, where scripted instruments and
> the like come with GUIs, so ordinary users can just load them and use
> them as you would with a more traditional solution.

Right, but on the other hand, scripting comes into game only where rather 
complex features need to be created for the respective instrument. Trying to 
implement such rather complex tasks with a very ergonomic UI is extremely hard 
to achieve or almost impossible. As you said, trying to hardwire that (like 
Tascam tried in GSt4 to avoid scripting) easily brings you to restrictions. So 
I think if an already existing script language is taken as basis (i.e. 
Kontakt's one), plus a decent script editor in the instrument editor with 
syntax highlight and auto completion suggestion and builtin documentation, 
that might be a good basis for sophisticated instrument designers.

CU
Christian

Re: [Linuxsampler-devel] script support

[David O. <da...@ol...>]

On Wed, May 21, 2014 at 1:16 PM, Christian Schoenebeck
<sch...@li...> wrote:
[...]
> Obviously those restrictions could be hacked by adding LinuxSampler's own
> minor custom extensions on GigaStudios original MIDI rules concept. But does
> it make sense? I mean one would probably reach another restriction with those
> MIDI rules soon and various use cases that would not be covered by them, and
> we would be back at point one.
>
> Thoughts?

Well, having written two scripting engines for realtime applications,
one of which evolved as part of an audio engine:

http://eelang.org
http://audiality.org

I would say it's an incredibly flexible and powerful solution,
generally speaking. Actually, the main reason why I went down that
route in the first place with Audiality 2 was that I wanted a *really*
small and simple engine that could still do something useful. (At 2000
LOC, it was already capable of all-synthetic sound effects and music.
It's a bit larger now, but the scripting language is friendlier, and
there is modular synthesis, filters, effects etc...)

A traditional modular, or worse, hardwired design tends to call for
countless features - and you still keep running into things that are
awkward or impossible to do without adding even more features. I think
that's a dead end with the kind of complexity and dynamics we want
from synths and audio engines these days. IMHO, hardwired features are
for performance or convenience - not core functionality.

The downside? Well, a scripting language isn't the best user interface
for non-programmers. One way to deal with that might be to think of
the scripting as an intermediate level, where scripted instruments and
the like come with GUIs, so ordinary users can just load them and use
them as you would with a more traditional solution.


-- 
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.--- Games, examples, libraries, scripting, sound, music, graphics ---.
|   http://consulting.olofson.net          http://olofsonarcade.com   |
'---------------------------------------------------------------------'

[Linuxsampler-devel] script support

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

Hi list!

I am currently thinking about whether it would make sense to add real-time 
scripting support to LS. Something like Kontakt already provides. A set of 
event handlers you can write and commands you can trigger by function calls. I 
would like to use it as extension to the GIG engine, but it could 
theoretically also be used for the other engines (SFZ and SF2).

In the gig format there are so called "MIDI rules". But as far as I can see 
it, they are very limited.

Example: I currently have a string ensemble instrument where I would like to 
have staccato sounds automatically being triggered if aftertouch passed a 
certain level. That way I can i.e. play and hold string chords with both 
hands, and by increasing pressure on the keys once in a while I can trigger 
other sounds again and again without having to release any key.

Sounds like a job for the so called "control trigger MIDI rule". But in the 
way it was implemented GigaStudio 4 there are four restrictions that prevent 
me doing so:

1. Those "control trigger midi rules" only support CCs, not aftertouch.
2. As far as I can see it there is a maximum of 32 triggers, thus I could use 
   those staccato sounds only on a key range of a bit more than 2 octaves.
3. Those trigger rules have no concept for distinguishing whether the sound 
   was triggered by a MIDI rule or normally/directly by the musician. So all I 
   could do is triggering another string ensemble note, but not a staccato 
   note with such MIDI rules. There is the so called "smart MIDI" dimensions, 
   but as far as I can see it, it is restricted to other MIDI rules like 
   legato, but not supposed to be used for the trigger MIDI rule.
4. As far as I can see it, you can only use one MIDI rule type per instrument. 
   So if you are using this "controller trigger MIDI rule" then you are not 
   supposed to use i.e. the "legato MIDI rule".

Obviously those restrictions could be hacked by adding LinuxSampler's own 
minor custom extensions on GigaStudios original MIDI rules concept. But does 
it make sense? I mean one would probably reach another restriction with those 
MIDI rules soon and various use cases that would not be covered by them, and 
we would be back at point one.

Thoughts?

CU
Christian

Re: [Linuxsampler-devel] lscp loader

[Stjepan H. <zva...@gm...>]

Thanks for caring..I appriciate it..
On Apr 25, 2014 6:29 PM, "Nicola Pandini" <nic...@gm...> wrote:

> I tried with debug-level=2 several times, but the problem didn't occurs.
> To make it occurs, I had to compile linuxsampler with the following
> options:
> ./configure --enable-debug-level=2 --enable-refill-streams=2
> --enable-stream-size=320000 --enable-preload-samples=65536
> --enable-max-voices=200 --enable-max-streams=220
> I found these options here: http://www.linuxsampler.org/debian.html
> The differences between the two versions are:
> # Preload Samples: 32768 - (the latter version has 65536)
> # Streams to be refilled per Disk Thread Cycle: 4 - (the latter version
> has 2)
> # Default Maximum Disk Streams: 90 - (the latter version has 220)
> # Default Maximum Voices: 64 - (the latter version has 200)
>
> I attached a .tar.gz that contains the lscp file, and three different logs
> where you can see that the loading stops before the end.
>
>
> Il 13/04/2014 13:55, Christian Schoenebeck ha scritto:
>
>> On Sunday 13 April 2014 14:38:17 Stjepan Horvat wrote:
>>
>>> is there a way to see what did sampler recive before it has send its data
>>> for loading....?
>>>
>> Sure! Recompile the server with increased debug level:
>>
>>         ./configure --enable-debug-level=2
>>         make
>>
>> Debug level 2 like suggested, should be enough for this. Then run the
>> sampler
>> (no need to install it):
>>
>>         src/linuxsampler
>>
>> Then it should show a debug message for every LSCP command recognized by
>> the
>> LSCP server (see src/network/lscpserver.cpp).
>>
>> In the sampler's source code you see debug messages are placed like this:
>>
>>         dmsg(2,("This is some value to debug: %d\n", value));
>>
>> The number in front indicates the minimum debug level for the debug
>> message to
>> be printed to the console.
>>
>> CU
>> Christian
>>
>> ------------------------------------------------------------
>> ------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees
>> _______________________________________________
>> Linuxsampler-devel mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>>
>
>
> --
> Nicola
>
>
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
>

Re: [Linuxsampler-devel] lscp loader

[Nicola P. <nic...@gm...>]

I tried with debug-level=2 several times, but the problem didn't occurs.
To make it occurs, I had to compile linuxsampler with the following options:
./configure --enable-debug-level=2 --enable-refill-streams=2 
--enable-stream-size=320000 --enable-preload-samples=65536 
--enable-max-voices=200 --enable-max-streams=220
I found these options here: http://www.linuxsampler.org/debian.html
The differences between the two versions are:
# Preload Samples: 32768 - (the latter version has 65536)
# Streams to be refilled per Disk Thread Cycle: 4 - (the latter version 
has 2)
# Default Maximum Disk Streams: 90 - (the latter version has 220)
# Default Maximum Voices: 64 - (the latter version has 200)

I attached a .tar.gz that contains the lscp file, and three different 
logs where you can see that the loading stops before the end.


Il 13/04/2014 13:55, Christian Schoenebeck ha scritto:
> On Sunday 13 April 2014 14:38:17 Stjepan Horvat wrote:
>> is there a way to see what did sampler recive before it has send its data
>> for loading....?
> Sure! Recompile the server with increased debug level:
>
> 	./configure --enable-debug-level=2
> 	make
>
> Debug level 2 like suggested, should be enough for this. Then run the sampler
> (no need to install it):
>
> 	src/linuxsampler
>
> Then it should show a debug message for every LSCP command recognized by the
> LSCP server (see src/network/lscpserver.cpp).
>
> In the sampler's source code you see debug messages are placed like this:
>
> 	dmsg(2,("This is some value to debug: %d\n", value));
>
> The number in front indicates the minimum debug level for the debug message to
> be printed to the console.
>
> CU
> Christian
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel


-- 
Nicola

Re: [Linuxsampler-devel] lscp loader

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

On Sunday 13 April 2014 22:04:36 Nicola Pandini wrote:
> I forgot to mention that:
> - I successfully load the .lscp if I open it with QSampler and Fantasia.

Those have a "natural" delay between sending the LSCP commands, since QSampler 
and Fantasia are also executing their UI code in between.

> - I also successfully load the .lscp with netcat if I set netcat -i 1
> (-i 1 means that netcat waits 1 second between each line of text, but
> unfortunately you can't tell netcat to wait less than 1 second, so it
> will take too much time to finish).

And which type of LSCP commands fail actually? A simple

	cat whatever.lscp | netcat localhost 8888

"should" always work without problems. If not, then it is most probably a bug 
in the sampler, which should be fixed. My guess is that it might be something 
about MIDI instruments.

CU
Christian

Re: [Linuxsampler-devel] lscp loader

[Nicola P. <nic...@gm...>]

I forgot to mention that:
- I successfully load the .lscp if I open it with QSampler and Fantasia.
- I also successfully load the .lscp with netcat if I set netcat -i 1 
(-i 1 means that netcat waits 1 second between each line of text, but 
unfortunately you can't tell netcat to wait less than 1 second, so it 
will take too much time to finish).

Il 13/04/2014 04:02, Nicola Pandini ha scritto:
> Hi,
> I have problems with netcat of a big lscp file (~250 lines).
> Sometimes happens that the loading stops before the end. It seems that
> netcat is too fast.
> So I wrote this bash script that introduces some latency between every
> line that is sent to LS:
>
> #!/bin/sh
> while read line
> do
>       if [ "$( echo "${line}" | head -c 1)" != "#" ]
>       then
>           echo "${line}" | netcat -q 0.01 localhost 8888 &
>           sleep 0.1
>       fi
> done < $1
>
>


-- 
Nicola

Re: [Linuxsampler-devel] lscp loader

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

On Sunday 13 April 2014 14:38:17 Stjepan Horvat wrote:
> is there a way to see what did sampler recive before it has send its data
> for loading....?

Sure! Recompile the server with increased debug level:

	./configure --enable-debug-level=2
	make

Debug level 2 like suggested, should be enough for this. Then run the sampler 
(no need to install it):

	src/linuxsampler

Then it should show a debug message for every LSCP command recognized by the 
LSCP server (see src/network/lscpserver.cpp).

In the sampler's source code you see debug messages are placed like this:

	dmsg(2,("This is some value to debug: %d\n", value));

The number in front indicates the minimum debug level for the debug message to 
be printed to the console.

CU
Christian

Re: [Linuxsampler-devel] lscp loader

[Stjepan H. <zva...@gm...>]

is there a way to see what did sampler recive before it has send its data
for loading....?
On Apr 13, 2014 2:04 PM, "Christian Schoenebeck" <
sch...@li...> wrote:

> On Sunday 13 April 2014 13:51:02 Stjepan Horvat wrote:
> > no..it just doesnt complete the config loading..its like if it never
> comes
> > to the server..
>
> It's very unlikely that this misbehavior could be a bug in netcat, bash or
> the
> TCP/IP stack of your OS. It rather sounds like a bug in the sampler's
> internal
> instrument manager or the LSCP server. There are various individual tasks
> inside the sampler for which separate threads are spawned. And if there is
> some kind of bug regarding the synchronization between those threads (of
> the
> sampler) it can lead to such a misbehavior. So debugging this issue on
> sampler
> side would be preferable, to get some informations what's going on when
> this
> misbehavior occurs.
>
> CU
> Christian
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] lscp loader

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

On Sunday 13 April 2014 13:51:02 Stjepan Horvat wrote:
> no..it just doesnt complete the config loading..its like if it never comes
> to the server..

It's very unlikely that this misbehavior could be a bug in netcat, bash or the 
TCP/IP stack of your OS. It rather sounds like a bug in the sampler's internal 
instrument manager or the LSCP server. There are various individual tasks 
inside the sampler for which separate threads are spawned. And if there is 
some kind of bug regarding the synchronization between those threads (of the 
sampler) it can lead to such a misbehavior. So debugging this issue on sampler 
side would be preferable, to get some informations what's going on when this 
misbehavior occurs.

CU
Christian

Re: [Linuxsampler-devel] lscp loader

[Stjepan H. <zva...@gm...>]

no..it just doesnt complete the config loading..its like if it never comes
to the server..
On Apr 13, 2014 1:49 PM, "Christian Schoenebeck" <
sch...@li...> wrote:

> On Sunday 13 April 2014 07:13:07 Stjepan Horvat wrote:
> > i have tried all kinds of netcats and combinations of invoking the config
> > file but non is 100% relieble when i try to load it using bash script or
> > systemd at startup..for example i have 27 channels and 27 instruments..it
> > stops at 24 or 26..
>
> You mean the LSCP server freezes?
>
> CU
> Christian
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] lscp loader

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

On Sunday 13 April 2014 07:13:07 Stjepan Horvat wrote:
> i have tried all kinds of netcats and combinations of invoking the config
> file but non is 100% relieble when i try to load it using bash script or
> systemd at startup..for example i have 27 channels and 27 instruments..it
> stops at 24 or 26..

You mean the LSCP server freezes?

CU
Christian

Re: [Linuxsampler-devel] lscp loader

[Stjepan H. <zva...@gm...>]

i have tried all kinds of netcats and combinations of invoking the config
file but non is 100% relieble when i try to load it using bash script or
systemd at startup..for example i have 27 channels and 27 instruments..it
stops at 24 or 26..

[Linuxsampler-devel] lscp loader

[Nicola P. <nic...@gm...>]

Hi,
I have problems with netcat of a big lscp file (~250 lines).
Sometimes happens that the loading stops before the end. It seems that 
netcat is too fast.
So I wrote this bash script that introduces some latency between every 
line that is sent to LS:

#!/bin/sh
while read line
do
     if [ "$( echo "${line}" | head -c 1)" != "#" ]
     then
         echo "${line}" | netcat -q 0.01 localhost 8888 &
         sleep 0.1
     fi
done < $1


-- 
Nicola
http://nicolapandini.damai.it

Re: [Linuxsampler-devel] missing file in svn repo

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

> That's an auto generated source file. That's why it was never on SVN. It
> should be automatically generated by
> scripts/generate_lscp_shell_reference.pl
> from the input file Documentation/lscp.xml. You can simply type
>
> 	make parser
>
> to re-generate it explicitly. However it would be interesting to know why it
>
> did not generate it automatically there. Have you probably changed your
> system's local time? The Makefile system is usually comparing modification
> times of files to decide whether something needs to be rebuilt.

running it manually gives a simple reason :
[seijitsu@astrux scripts]$ perl generate_lscp_shell_reference.pl
Can't locate XML/Parser.pm in @INC (you may need to install the
XML::Parser module) (@INC contains: /usr/lib/perl5/site_perl
/usr/share/perl5/site_perl /usr/lib/perl5/vendor_perl
/usr/share/perl5/vendor_perl /usr/lib/perl5/core_perl
/usr/share/perl5/core_perl .) at generate_lscp_shell_reference.pl line
15.
BEGIN failed--compilation aborted at generate_lscp_shell_reference.pl line 15.

this is coderent with a recent message in the AUR :
https://aur.archlinux.org/packages/linuxsampler-svn/ where a
dependency for perl-xml-parser has been added.
But when compiling from source without this requirement, the script
probably fails and the file is not generated.

I now realize that i could have used the linuxsampler-svn from AUR
repository to automatically deal with the dependencies, but on another
hand maybe the make process could catch the error from the perl script
?

Re: [Linuxsampler-devel] missing file in svn repo

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

On Wednesday 09 April 2014 10:15:28 Raphaël Mouneyres wrote:
> tried to compile today with a fresh svn checkout, and the make process
> fails for linuxsampler with "lscp_shell_reference.cpp: No such file or
> directory"
> Browsing the svn repository online shows that the file doesn't exists
> anymore in src/network. Maybe it has been removed by error ?

That's an auto generated source file. That's why it was never on SVN. It 
should be automatically generated by scripts/generate_lscp_shell_reference.pl
from the input file Documentation/lscp.xml. You can simply type

	make parser

to re-generate it explicitly. However it would be interesting to know why it 
did not generate it automatically there. Have you probably changed your 
system's local time? The Makefile system is usually comparing modification 
times of files to decide whether something needs to be rebuilt.

CU
Christian

[Linuxsampler-devel] missing file in svn repo

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

Hello,

tried to compile today with a fresh svn checkout, and the make process
fails for linuxsampler with "lscp_shell_reference.cpp: No such file or
directory"
Browsing the svn repository online shows that the file doesn't exists
anymore in src/network. Maybe it has been removed by error ?

I had a recent backup of the source tree with the file in it, so i
managed to go on with the compilation process.

Raphaël

[Linuxsampler-devel] EG envelopes

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

hello,

to continue my discussion from last october... http://linuxaudio.org/mailarchive/lau/2013/11/3/202707

I've managed to use the envelope generator to achieve a good hihat pedal feeling, still not finished though.
This is what i have for a group :
<group>
key=41
loop_mode=one_shot
eg8_time0=0 eg8_level0=1 
eg8_time1=0.1 eg8_time1_oncc4=2 eg8_level1=0
eg8_volume=0

I have a question about how linuxsampler deal with the envelopes, especially with the  egN_timeX_onccY opcode :
It looks like the envelope generator is determined with the last CCY value just before the note_on message.
Then changing the CCY's value won't change the opcode value, it has be fixed when the sample was triggered.
So in my case with that opcode, the length of the volume envelope is determined when the sample is triggered.

I would like to be able to modify this envelope length even after the sample has been triggered, is there a way to do that ?

Raphaël

Re: [Linuxsampler-devel] LSCP shell

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

> On Friday 21 March 2014 14:07:23 you wrote:
>> thanks for the updated infos.
>> In the future, would you post a quick changelog to the list when the
>> svn is updated, or is there another way to be automatically informed
>> when something new has been submited to the repository ?
> 
> Hmm... not sure about that. The jack-devel mailing list recently forwards all 
> commit logs of JACK1 automatically to that mailing list. And I find it very 
> annoying. So from that experience I rather don't want to forward commit change 
> logs automatically to this list.
> 
> We might establish a separate email list dedicated for commit logs and/or RSS 
> feed, automatic Twitter tweets ...

you're right, separating to another medium may be the best option.
a RSS feed is easy to add to most email programs without spamming the main inbox.

Re: [Linuxsampler-devel] LSCP shell

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

On Friday 21 March 2014 14:07:23 you wrote:
> thanks for the updated infos.
> In the future, would you post a quick changelog to the list when the
> svn is updated, or is there another way to be automatically informed
> when something new has been submited to the repository ?

Hmm... not sure about that. The jack-devel mailing list recently forwards all 
commit logs of JACK1 automatically to that mailing list. And I find it very 
annoying. So from that experience I rather don't want to forward commit change 
logs automatically to this list.

We might establish a separate email list dedicated for commit logs and/or RSS 
feed, automatic Twitter tweets ...

CU
Christian

Re: [Linuxsampler-devel] LSCP shell

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

> I made some progress, my planned basic features are roughly done, but I had so
> far no time to finish it up. There are still some minor issues to be solved.
> But right now I have no time for spare time projects.

sure, i let you do it at your speed as i can not contribute to the
code, but only to give some user feedback

> Moving the cursor position with left/right key is actually implemented in
> latest SVN version. Are you using the latest one (1.0.0.svn37)?
once again, no, i hadn't updated, i'm not checking the repository that often.


> I implemented that somewhat different than other shells do: there is no need
> for double tab. The next token(s) are automatically shown next to your command
> line in different color, showing you immediately all possibilities you have

that is a good implementation !

thanks for the updated infos.
In the future, would you post a quick changelog to the list when the
svn is updated, or is there another way to be automatically informed
when something new has been submited to the repository ?

Raphaël

Re: [Linuxsampler-devel] LSCP shell

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

On Friday 21 March 2014 10:52:41 Raphaël Mouneyres wrote:
> hello,
> 
> i've been using the LSCP shell yesterday, and it has been of a great
> help, especially the command history.

The LSCP shell is still work in progress.

I made some progress, my planned basic features are roughly done, but I had so 
far no time to finish it up. There are still some minor issues to be solved. 
But right now I have no time for spare time projects.

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

Moving the cursor position with left/right key is actually implemented in 
latest SVN version. Are you using the latest one (1.0.0.svn37)?

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

I implemented that somewhat different than other shells do: there is no need 
for double tab. The next token(s) are automatically shown next to your command 
line in different color, showing you immediately all possibilities you have 
while typing, without requiring you to trigger any special key (see attached 
screen shot). It not only lists you keywords, but also so called "non 
terminals" like "number", "digit" which may be required to for the current 
command line position, for example for "GET CHANNEL INFO <number>".

Plus in latest SVN version, the relevant LSCP reference document section is 
automatically displayed below the command line, as soon as it is obvious which 
LSCP command you mean. It shows you the general syntax of the LSCP command you 
are currently typing, plus detailed descriptions about that specific LSCP 
command. However the following issues have yet to be solved for this 
particular feature:

	1. The document section is not displayed 100% correctly. For example 
	   sometimes there is no gap between two words, and some HTML encoding of 
	   the source document (lscp.xml) is not yet transformed into normal 
	   ASCII text.

	2. There is a bug, that sometimes causes the encoded document info sent 
	   by the LSCP server to be displayed by the LSCP shell directly on 
	   screen, as it was a regular response to a command the user types.

	3. The document section shall actually only be displayed partly, for 
	   example it should not cover more than 25% of the current terminal 
	   height or something, if it would cover more it should be cutted and
	   instead be scrollable with some keys, i.e. page up and page down keys. 
	   However I am not yet sure about the keys, because a Mac for example 
	   does not have page up/down keys. Preferably keys shall be defined that 
	   exist on all major systems.

CU
Christian