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

[Linuxsampler-devel] LSCP shell

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

hello,

i've been using the LSCP shell yesterday, and it has been of a great
help, especially the command history.

I had previously mentioned some enhancements, and i confirm they would
be great to have
>when you're in a command history, you have to use the delete key, you cannot use the left arrow to change some parameter on a long line.
in fact you can use the delete key to go back. But i noticed that the
line is grayed as soon as you go back, and it turns green again only
when you have reached your previous end of line position. Maybe the
line is not re-evaluated when you use the delete key from a previous
command.

>autocompletion on command parameters display a list of available commands/sub-commands on double-tab (depending on what has previously been greened)
as a first shot, you could display the message that is printed when
you enter an incomplete command "....expecting.....should be....."

cheers,

Raphaël

Re: [Linuxsampler-devel] SFZ parse patch

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

On Monday 03 March 2014 08:16:29 Sergey wrote:
> OK, modified it to handle c-style includes. Try to apply the attached diff.

I just applied the patch in modified form. I had a) a concern that 
currentDirectory was not handled correctly (since that member variable is also 
read in push_opcode()) and b) I addressed that #include may be used with 
relative as well as with absolute paths. No idea whether the latter is also 
implemented in Aria this way though.

I hope it is OK this way.

Thanks Sergey!

CU
Christian

Re: [Linuxsampler-devel] disk streaming performance with iso

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

thank you for the answer, i'm surprised that inode could have an
influence but i have to admit i'm not a specialist of filesystems.
For now i'm testing with a stripped down version with wav samples
exported from the iso files. I'll probably move to the iso files
later, so i'll report here wheter it works "okay" or not.
Raphaël

2014-03-04 19:12 UTC+01:00, Christian Schoenebeck
<sch...@li...>:
> On Monday 03 March 2014 20:52:54 raf wrote:
>> would there be a performance issue when using SFZ engine reading WAV fles
>> from a mounted ISO instead of a standard folder structure containing the
>> WAV files ?
>
> Since that implies layering two file systems on each other and accordingly
> requires two file system stacks to be processed on every read() call, this
> definitely means a performance penalty. I never benchmarked it, but my guess
>
> is if the the inode size in both file systems is large enough, then
> performance might be "okay".
>
> CU
> Christian
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries.  Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] disk streaming performance with iso

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

On Monday 03 March 2014 20:52:54 raf wrote:
> would there be a performance issue when using SFZ engine reading WAV fles
> from a mounted ISO instead of a standard folder structure containing the
> WAV files ?

Since that implies layering two file systems on each other and accordingly 
requires two file system stacks to be processed on every read() call, this 
definitely means a performance penalty. I never benchmarked it, but my guess 
is if the the inode size in both file systems is large enough, then 
performance might be "okay".

CU
Christian

[Linuxsampler-devel] disk streaming performance with iso

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

Hello,

would there be a performance issue when using SFZ engine reading WAV fles from a mounted ISO instead of a standard folder structure containing the WAV files ?

Raphaël

Re: [Linuxsampler-devel] SFZ parse patch

[Sergey <tg...@bi...>]

Hi!

OK, modified it to handle c-style includes. Try to apply the attached diff.

---
Sincerely yours,
Sergey

On 03/02/2014 11:41 PM, Andreas Persson wrote:
>
> Even though it isn't listed on their custom opcodes page, Aria seems to
> have an include statement, as one of the instrument in the Free Sounds
> for ARIA pack shows:
>
> //and the files...
> #include "BD.sfz"
> #include "SD.sfz"
> #include "LT.sfz"
>
> So, I agree we can apply the patch, but it would be nice if it used the
> same syntax as the Aria file uses.
>
> /Andreas
>
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
>

Re: [Linuxsampler-devel] SFZ parse patch

[Andreas P. <and...@br...>]

Christian Schoenebeck wrote On 2014-02-28 15:44:
> On Friday 28 February 2014 13:09:39 Sergey wrote:
>> I've searched available SFZ specs and there is no official include
>> operator. So yes, it is my suggestion.
> 
> In general I think that extension makes sense, so I am not opposed to apply it 
> to the sampler. I just wonder whether a special prefix shall be used, 
> indicating a custom extension, to avoid a potential clash with an "official" 
> SFZ include statement that might be introduced in future.
> 
> What do our SFZ experts say? Andreas? Anders? Grigor?

Even though it isn't listed on their custom opcodes page, Aria seems to
have an include statement, as one of the instrument in the Free Sounds
for ARIA pack shows:

//and the files...
#include "BD.sfz"
#include "SD.sfz"
#include "LT.sfz"

So, I agree we can apply the patch, but it would be nice if it used the
same syntax as the Aria file uses.

/Andreas

Re: [Linuxsampler-devel] SFZ parse patch

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

On Friday 28 February 2014 13:09:39 Sergey wrote:
> I've searched available SFZ specs and there is no official include
> operator. So yes, it is my suggestion.

In general I think that extension makes sense, so I am not opposed to apply it 
to the sampler. I just wonder whether a special prefix shall be used, 
indicating a custom extension, to avoid a potential clash with an "official" 
SFZ include statement that might be introduced in future.

What do our SFZ experts say? Andreas? Anders? Grigor?

CU
Christian

Re: [Linuxsampler-devel] SFZ parse patch

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

On Friday 28 February 2014 08:46:45 Sergey wrote:
> With a patch, everything is simplified to the following:
> === master.sfz ===
> .include key-up-layer.sfz
> .include key-down-layer.sfz
> .include pedal-up-down.sfz
> .include release-layer.sfz
> === end of master.sfz==

Is that ".include" statement your own suggestion or is it used by any existing 
SFZ capable software already?

CU
Christian

[Linuxsampler-devel] SFZ parse patch

[Sergey <tg...@bi...>]

Hi!

I've just implemented a trivial SFZ parser patch to allow composite SFZ 
files. The rationale behind it is that after converting musical 
instrument from KONTAKT format I often have multiple SFZ files (main 
instrument, pedal up-down sounds, release sounds, etc). Loading each SFZ 
in a dedicated channel sometimes break things (release layer not playing 
most notable). So there was a need to assemble layers back into one long 
SFZ.

With a patch, everything is simplified to the following:
=== master.sfz ===
.include key-up-layer.sfz
.include key-down-layer.sfz
.include pedal-up-down.sfz
.include release-layer.sfz
=== end of master.sfz==

The patch is really trivial - most of the File(...) constructor body 
moved out to separate method parseFile(...) which is called recursively 
on encounter of ".include" if the beginning of a file line.

Do you think it is useful to have this functionality in a trunk of 
linuxsampler, or I'd better keep that as a local patch ?

---
Sincerely yours,
Sergey

[Linuxsampler-devel] LinuxSampler license actually forbids ALL use GPL design decisions)

[<lin...@sp...>]

When my brother asked me for help setting up LinuxSampler, I noticed 
that, because of a trick of legalese, the license actually forbids ALL use.

Basically, the problem is as follows:
1. The GPL allows use for any purpose so long as its restrictions are
    met.
2. The GPL explicitly forbids any additional restrictions.
3. As the party bestowing the GPL with its power, you're applying an
    additional restriction.

This means that, in plain English, you're saying "We grant permission to 
use LinuxSampler as long as you can simultaneously obey these two 
directives which directly contradict each other."

(It's the legal equivalent of "The next sentence is true. The previous 
sentence is false.")

This is actually by design. You're not SUPPOSED to be able to use the 
name "GPL" on anything that imposes additional restrictions.

https://www.gnu.org/licenses/gpl-faq.html#NoMilitary

You'd be able to resolve this by removing the relevant portions of the 
GPL... but the GPL itself is licensed to you under terms similar to a 
CC-BY-ND license. You can copy it around but modified versions require 
permission from lic...@gn... and must have their name changed.

https://www.gnu.org/licenses/gpl-faq.html#ModifyGPL




Also, your interpretation of linking libgig with LinuxSampler doesn't 
agree with courts and lawyers who make the actual decisions, so the FAQ 
answer is at odds with legal reality:

It's legal for YOU to compile LinuxSampler against libgig since you own 
both of them, but it's illegal for ME to compile it because:
1. Regardless of the terms for LinuxSampler, you're offering libgig to
    me under a pure GPL license.
2. The GPL forbids linking against anything that can't also be
    distributed under pure GPL terms.

Again, this is by design. It's meant to prevent someone from taking a 
GPL library and incorporating it into something under different terms.

https://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL

(Though the solution here is much simpler. Once you've fixed the 
LinuxSampler license, just say that people can have libgig under their 
choice of the GPL or the LinuxSampler license.)




Finally, while it's not strictly relevant to what I just said, I just 
wanted to point out that the "LinuxSampler is not open source, you are 
evil!" FAQ entry feels a little bit like attacking a straw man.

It's probably correct for anyone who makes an ad hominem attack like 
"you are evil!", but most of the people I've met who care about whether 
something is open source are referring to whether the license is OSI 
certified rather than the more colloquial definition.

...and the OSI will never certify a license with a non-commercial 
restriction because it violates criterion #6 (No Discrimination Against 
Fields of Endeavor) of their definition of open source.

http://opensource.org/docs/osd#fields-of-endeavor




Given how difficult it is to craft just the right legalese without 
paying a lawyer, I'll keep my eyes open for a freely-usable license 
that's sort of like the GPL with a non-commercial restriction, but I 
doubt I'll find one.

(The Creative Commons BY-NC and BY-NC-SA licenses were written by 
professionals and even they are considered rather toxic because of how 
some jurisdictions consider "a blog which makes a few cents off Google 
AdSense" as commercial enough to violate the license.)

Generally, if it's got the concept of source code (unlike Creative 
Commons licenses) and it doesn't meeet the OSI criteria, it's just filed 
under "proprietary" along with EULAs.

(The closest I've seen mention of is the old POV-Ray license and that 
had enough flaws that, in 2007, they were considering a full rewrite if 
their plans to re-licence the existing code to AGPL failed.)

-- 
Stephan Sokolow

Note: My e-mail address IS valid. It's a little trick I use to fool
"smarter" spambots and remind friends and family to use the custom
aliases I gave them.

Re: [Linuxsampler-devel] FEATURE REQUEST: LSCP midi translator

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

On Monday 10 February 2014 14:34:23 Christian Schoenebeck wrote:
> On Monday 10 February 2014 15:15:23 you wrote:
> > What i want to use LSCP for is to mute and unmute a single sampler
> > channel by a program change..
> > 
> > How program changes works:
> > *192* 2 - change the program (sound) on MIDI channel 1 to program #2
> > and
> > *192* 1 - change the program (sound) on MIDI channel 1 to program #1
> > 
> > So what i wanted to do is the folowing:
> > 
> > when i recive
> > "192 2" : "SET CHANNEL MUTE 0 1"
> > "192 1" : "SET CHANNEL MUTE 0 0"
> > 
> > do you know if there is a better way (with higher priority to do so)..
> 
> Sounds a bit odd. Can you elaborate the intended use case for this? So far,
> if I got it correctly, you simply want to switch MIDI input from one
> sampler part to another sampler part. If so, why don't you do "REMOVE
> CHANNEL MIDI_INPUT", "ADD CHANNEL MIDI_INPUT"?

And also note: you can define a "load strategy" for sounds. So you can i.e.
keep certain sounds always cached, even if not used by any sampler part ATM,
which allows you to do program changes on a sampler part immediately, without
having to wait for load gaps. Have a look at this section:

http://www.linuxsampler.org/api/draft-linuxsampler-protocol.html#MIDI%20Instrument%20Mapping

My guess is that this is what you actually intended to approach.

CU
Christian

Re: [Linuxsampler-devel] FEATURE REQUEST: LSCP midi translator

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

What i want to use LSCP for is to mute and unmute a single sampler channel
by a program change..

How program changes works:
*192* 2 - change the program (sound) on MIDI channel 1 to program #2
and
*192* 1 - change the program (sound) on MIDI channel 1 to program #1

So what i wanted to do is the folowing:

when i recive
"192 2" : "SET CHANNEL MUTE 0 1"
"192 1" : "SET CHANNEL MUTE 0 0"

do you know if there is a better way (with higher priority to do so)..

Re: [Linuxsampler-devel] FEATURE REQUEST: LSCP midi translator

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

On Monday 10 February 2014 11:15:48 Stjepan Horvat wrote:
> Hey guys..
> how complicated it would be to write a program that would recives midi
> messages (convert them dependent on the config) and send LSCP commands..
> 
> the config would look like:
> 
> "Byte 0 = 193, Byte 1 = 1" : "RESET CHANNEL 0"
> "Byte 0 = 145, Byte 1 = 84, Byte 2 = 100" : "SET CHANNEL MUTE 1 1"

You are aware, that the MIDI commands in LSCP are not intended for real-time 
operation, right? The LSCP server is running as single thread with low 
priority. So in practice this means latency and jitter for your MIDI events. 
Those MIDI commands were just added to LSCP for things like virtual MIDI 
keyboards in graphical frontend applications.

CU
Christian

Re: [Linuxsampler-devel] FEATURE REQUEST: LSCP midi translator

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

Thanks Raphael for the script..
What do you think about using socket instead of ' echo "RESET CHANNEL 0" |
nc localhost 8888' command..

http://stackoverflow.com/questions/19819677/python-equivalent-of-netcat

Re: [Linuxsampler-devel] FEATURE REQUEST: LSCP midi translator

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

hello,

mididings would do that easily : http://das.nasophon.de/mididings/

on receive midi message, send shell command : echo "RESET CHANNEL 0" |
nc localhost 8888

a complete script would look like :

import sys
sys.path.append('/usr/bin/mididings')

from mididings import *

run (
        Filter(NOTEON) >> KeySplit({
                60: System(' echo "RESET CHANNEL 0" | nc localhost 8888'),
                61: System(' echo "SET CHANNEL MUTE 1 1" | nc localhost 8888'),
        })
)

and voilà.

Raphaël

2014-02-10 11:15 UTC+01:00, Stjepan Horvat <zva...@gm...>:
> Hey guys..
> how complicated it would be to write a program that would recives midi
> messages (convert them dependent on the config) and send LSCP commands..
>
> the config would look like:
>
> "Byte 0 = 193, Byte 1 = 1" : "RESET CHANNEL 0"
> "Byte 0 = 145, Byte 1 = 84, Byte 2 = 100" : "SET CHANNEL MUTE 1 1"
>

[Linuxsampler-devel] FEATURE REQUEST: LSCP midi translator

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

Hey guys..
how complicated it would be to write a program that would recives midi
messages (convert them dependent on the config) and send LSCP commands..

the config would look like:

"Byte 0 = 193, Byte 1 = 1" : "RESET CHANNEL 0"
"Byte 0 = 145, Byte 1 = 84, Byte 2 = 100" : "SET CHANNEL MUTE 1 1"

Re: [Linuxsampler-devel] LSCP shell

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

On Saturday 08 February 2014 18:46:02 raf wrote:
> some enhancement for the future ?
> after you've gone into command history with the up arrow, you cannot come
> back to a blank line 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. While this would be great, i'm sure it's not compatible with
> how the auto-completion is handled. autocompletion on command parameters
> display a list of available commands/sub-commands on double-tab (depending
> on what has previously been greened)

Sure! That and more is planned. That's just a starting point for the LSCP 
shell for now. Not more, not less.

The trickiest part was dealing with the auto generated Bison tables and the 
LALR(1) algorithm on top of them. But that is done now and I think the other 
shell features can easily be added. Those should neither be difficult nor 
should they take much effort.

But as said, I have to work on other things for a while now.

> a strange thing :
> lscp=# CREATE AUDIO_OUTPUT_DEVICE JACK ACTIVE=TRUE CHANNELS=2
> SAMPLERATE=48000 NAME="linuxsampler"libjackBufferSizeCallback(128) after
> firing up this command, the libjackBufferSizeCallback(128) is added at the
> end.

Since I couldn't reproduce this with the same command, and since I currently 
don't see why this should have been generated by the sampler's LSCP parser, my 
guess is that you compiled either JACK or the sampler with debug messages 
turned on, causing "libjackBufferSizeCallback(128)" to be printed on the 
currently active terminal when the sampler instantiates the JACK driver.

CU
Christian

Re: [Linuxsampler-devel] LSCP shell

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

> On Saturday 08 February 2014 15:23:17 raf wrote:
>> the sampler engine is running ok, but strangely the lscp shell complains
>> that the engine is too old, although they have just been compiled together
>> from the latest svn version...
>> 
>> LinuxSampler 1.0.0.svn23
> 
> That version is from 2013 by the way. Definitely not the latest svn version. 
> Have a look at the SVN log on the linuxsampler.org front page. You see the 
> respective version for each commit there. Latest version is 1.0.0.svn31.

oups, you are absolutely right, the package manager didn't correctly remove the previous version...
So this is all working now !

I apreciate : the colors, return message and error messages, the auto-upper case on commands, command history

some enhancement for the future ?
after you've gone into command history with the up arrow, you cannot come back to a blank line 
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. While this would be great, i'm sure it's not compatible with how the auto-completion is handled.
autocompletion on command parameters
display a list of available commands/sub-commands on double-tab (depending on what has previously been greened)

a strange thing :
lscp=# CREATE AUDIO_OUTPUT_DEVICE JACK ACTIVE=TRUE CHANNELS=2 SAMPLERATE=48000 NAME="linuxsampler"libjackBufferSizeCallback(128)
after firing up this command, the libjackBufferSizeCallback(128) is added at the end.

This lscp shell promises to be very useful, thank you for this great tool !

Raphaël

Re: [Linuxsampler-devel] LSCP shell

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

On Saturday 08 February 2014 15:23:17 raf wrote:
> the sampler engine is running ok, but strangely the lscp shell complains
> that the engine is too old, although they have just been compiled together
> from the latest svn version...
> 
> LinuxSampler 1.0.0.svn23

That version is from 2013 by the way. Definitely not the latest svn version. 
Have a look at the SVN log on the linuxsampler.org front page. You see the 
respective version for each commit there. Latest version is 1.0.0.svn31.

CU
Christian

Re: [Linuxsampler-devel] LSCP shell

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

On Saturday 08 February 2014 15:23:17 you wrote:
> the sampler engine is running ok, but strangely the lscp shell complains
> that the engine is too old, although they have just been compiled together
> from the latest svn version...
> 
> LinuxSampler 1.0.0.svn23
> 
> [seijitsu@astrux ~]$ lscp
> LSCPServer: Client connection established on socket:4.
> Error: sampler too old, it does not support shell instructions
> LSCPServer: Client connection terminated on socket:4.

I am pretty sure you are running another, old version of LinuxSampler then. 
Try starting the sampler directly from the source build dir like this:

	src/linuxsampler

and accordingly the shell directly from the source dir:

	src/shell/lscp

That should do it. If that worked fine without that "too old" error, then you 
probably still had an old version of LinuxSampler installed somewhere, i.e. 
under /usr/local or you simply did not install the new version at all after 
compiling or did not restart linuxsampler after compiling and installing.

CU
Christian

Re: [Linuxsampler-devel] LSCP shell

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

Excellent, compiles fine without errors (some warnings about deprecated midi functions)

the sampler engine is running ok, but strangely the lscp shell complains that the engine is too old, although they have just been compiled together from the latest svn version...

LinuxSampler 1.0.0.svn23

[seijitsu@astrux ~]$ lscp
LSCPServer: Client connection established on socket:4.
Error: sampler too old, it does not support shell instructions
LSCPServer: Client connection terminated on socket:4.

Raphaël 

Le 8 févr. 2014 à 01:05, Christian Schoenebeck a écrit :

> On Friday 07 February 2014 17:19:07 Christian Schoenebeck wrote:
>>> my version was 3.0.1, I updated to
>>> [seijitsu@astrux linuxsampler-svn]$ bison -V
>>> bison (GNU Bison) 3.0.2
>>> Written by Robert Corbett and Richard Stallman.
>>> 
>>> but still got the same error.
>> 
>> Yeah, I just tested it with Bison 3.0.2 and figured that those two C arrays
>> are not automatically generated by Bison 3.x by default anymore.
> [snip]
>> I'll try to find out how
>> to convince Bison 3 to generate the two missing C arrays.
> 
> Fixed in latest SVN version. Should compile without errors now.
> 
> CU
> Christian
> 

Re: [Linuxsampler-devel] LSCP shell

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

On Friday 07 February 2014 17:19:07 Christian Schoenebeck wrote:
> > my version was 3.0.1, I updated to
> > [seijitsu@astrux linuxsampler-svn]$ bison -V
> > bison (GNU Bison) 3.0.2
> > Written by Robert Corbett and Richard Stallman.
> > 
> > but still got the same error.
> 
> Yeah, I just tested it with Bison 3.0.2 and figured that those two C arrays
> are not automatically generated by Bison 3.x by default anymore.
[snip]
> I'll try to find out how
> to convince Bison 3 to generate the two missing C arrays.

Fixed in latest SVN version. Should compile without errors now.

CU
Christian

Re: [Linuxsampler-devel] LSCP shell

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

On Sat, February 8, 2014 3:07 am, Christian Schoenebeck wrote:
> 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.
>

Yep, working now.  Thanks.



--
Patrick Shirkey
Boost Hardware Ltd

Re: [Linuxsampler-devel] LSCP shell

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

On Friday 07 February 2014 00:25:35 raf wrote:
> i don't know anything about bison... i wouldn't be of any help to track
> down the problem.
> 
> my version was 3.0.1, I updated to
> [seijitsu@astrux linuxsampler-svn]$ bison -V
> bison (GNU Bison) 3.0.2
> Written by Robert Corbett and Richard Stallman.
> 
> but still got the same error.

Yeah, I just tested it with Bison 3.0.2 and figured that those two C arrays 
are not automatically generated by Bison 3.x by default anymore.

> looking more into the configure output I can see this message with some
> warnings related to bison :
> 
> Searching for a parser generator...OK (/usr/bin/bison -y)
> Generating LSCP parser...
> lscp.y: warning: 1801 shift/reduce conflicts [-Wconflicts-sr]
> lscp.y: warning: 1045 reduce/reduce conflicts [-Wconflicts-rr]
> lscp.y: warning: 1801 shift/reduce conflicts [-Wconflicts-sr]
> lscp.y: warning: 1045 reduce/reduce conflicts [-Wconflicts-rr]
> Done

Not related to this problem. It just reminds us that there are a lot of 
ambiguities in our LSCP grammar definition. In practice does not cause any 
problem for us though.

> then later on, not blocking :
> checking for ARTS artsc - version >= 0.9.5... no
> *** The artsc-config script installed by ARTS could not be found
> *** If ARTS was installed in PREFIX, make sure PREFIX/bin is in
> *** your path, or set the ARTS_CONFIG environment variable to the
> *** full path to artsc-config.

Not related to this problem. ARTS does not exist on modern systems anymore.

> what bison version do you have ? 

I just tested with Bison 2.x in the last few days.

> can a 64bits system make a difference ?

No, 32 bit or 64 bit does not make a difference. I'll try to find out how to 
convince Bison 3 to generate the two missing C arrays.

CU
Christian