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

Re: [Linuxsampler-devel] Default Audio/MIDI devices

[Vladimir S. <ha...@so...>]

Hi Rui,

I had something similar with lex/flex. You might want to update flex 
package.
Also, do a "whereis lex" and make sure it indeed links to flex and not 
some older outdated executable. I think i had that issue on my machine.

I'm not sure why you want to bring SET CHANNEL AUDIO_OUTPUT_TYPE back. I 
think we shuold just implement  SET CHANNEL AUDIO_OUTPUT_DEVICE command.

Let me know if you have any flex/bison issues i think i should be able 
to help you out now that i'm myself a little more flex/bison aware 
(thanks to Simon).

Regards,
Vladimir.

Rui Nuno Capela wrote:

>Hi,
>
>Now that the CREATE AUDIO_OUTPUT_DEVICE is supposedly working with default
>parameters, as of Vladimir's latest CVS commit, isn't it worthy to put
>back in operation the so-called deprecated SET CHANNEL AUDIO_OUTPUT_TYPE
>command?
>
>I mean, for instance, that these old SET CHANNEL AUDIO_OUTPUT_TYPE command
>would map to the corresponding CREATE AUDIO_OUTPUT_DEVICE command, just
>taking the defaults.
>
>Most probably, a special server state check should be taken on whether the
>device isn't already created by a previous request, if duplicate default
>device instances are to be avoided, either of ALSA or JACK types. Note
>that JACK and ALSA are all-upper-case tokens as was before.
>
>The same would be applicable to SET CHANNEL MIDI_INPUT_TYPE and CREATE
>MIDI_INPUT_DEVICE commands.
>
>Most important, this suggestion would make older LSCP scripts, and
>qsampler for that matter, forward compatible with the new server engine
>protocol, so prevent the already released code from choking with the
>latest server development path.
>
>As usual, I can set my efforts on patching linuxsampler for you to try
>out. However, I'm affraid this has implications on changing the parser
>grammar/lexical source files (src/network/{lscp.y, lscp.l}) for which I've
>been a complete failure on how to put them to regenerate a proper parser.
>
>I though it would be sufficient to issue `make parser` under src/network,
>but that's been failing on my face. Either my flex/bison installation is
>bad or it is *me* that is doing it miserably wrong.
>
>e.g. my flex doesn't recognize those --fast and --8bit command line
>options, only -f and -8 respectively; then it also fails with:
>"lscp.l", 33: unrecognized %option: reentrant
>
>Currently using flex-2.5.4a and bison-1.875 (Mdk 10.0 Official).
>
>Maybe someone could help me out, before I do some terrible mistake ;)
>
>Any flex/bison gurus out there? Simon? ;)
>
>Cheers.
>  
>

Re: [Linuxsampler-devel] [linuxsampler] Latest CVS Commit

[Rui N. C. <rn...@rn...>]

Hi Simon,

>
>>[...] What about that all-upper-case restriction for command keywords?
>> And the parameter key names _must_ be capitalized or sort of.
>>
> My suggestion was that "key names _must_ not match keywords" be the only
> rule - its sufficient - and that key names be mixed case by convention,
> rather than by law.
> That would allow for the occasional upper-case name where it made sense,
> eg for acronyms (still use ALSA rather than Alsa).
>

Agreed.


> The keywords are all upper case because... thats just the way they are.
> Its not a rule exactly (or IMHO shouldn't be) its simply the convention
> that was chosen/adopted.
>
> (FWIW I don't particularly like the upper case keywords because
> 1) its less readable,
> 2) its less typeable,
> 3) there's no need to shout, and
> 4) it isn't 1976 any more.
> But its not my place to rework the protocol according to my personal
> tastes/prejudices, especially when I lurked my way through the first
> eight drafts and am not involved in the software at either end of the
> link. So I'm just offering what help I can to make the parser work at
> all).
>
>>Isn't it too restrictive? I'd rather have LSCP case insensitive al
>> together.
>>
> There's not much advantage in making the protocol case insensitive. Its
> not like the software at either end is going to forget to press the
> shift key.
> More likely it would fail to match an oddly cased key name because
> someone forgot ToUpper().
> OK, some people might need to type LSCP by hand, but with a consistent
> set of conventions it shouldn't be too hard for them to get it right.
>
> The disadvantages of case insensitivity are
> 1) extra work in the lexical analyser and
> 2) extra opportunity for name/keyword clashes: It would no longer be
> possible to use the key name "Channel" because it would now clash with
> the keyword "CHANNEL".
>

I surely understand about increased complexity for the lexical analyzer,
but my complaints, or so to speak, were exactly about this clashing issue.

Beware, ignorant's questions follows :)

How can it be that a parser/syntax design is such that it can't resolve
around distinguishing a keyword from a parameter key name? In my humble
POV the position within the phrase would suffice to that.

Is it a lex/yacc limitation or what, that a keyword is always taken
literally, prioritary and unconditianally independant from where it occurs
whithin a parsed sentence?

Anyway, I can live with it. I only wish to know better.

Finally, please forgive my not-so-good english, eheh, I hope you're not
using a lex/yacc combination to read this :)

Cheers.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

[Linuxsampler-devel] Default Audio/MIDI devices

[Rui N. C. <rn...@rn...>]

Hi,

Now that the CREATE AUDIO_OUTPUT_DEVICE is supposedly working with default
parameters, as of Vladimir's latest CVS commit, isn't it worthy to put
back in operation the so-called deprecated SET CHANNEL AUDIO_OUTPUT_TYPE
command?

I mean, for instance, that these old SET CHANNEL AUDIO_OUTPUT_TYPE command
would map to the corresponding CREATE AUDIO_OUTPUT_DEVICE command, just
taking the defaults.

Most probably, a special server state check should be taken on whether the
device isn't already created by a previous request, if duplicate default
device instances are to be avoided, either of ALSA or JACK types. Note
that JACK and ALSA are all-upper-case tokens as was before.

The same would be applicable to SET CHANNEL MIDI_INPUT_TYPE and CREATE
MIDI_INPUT_DEVICE commands.

Most important, this suggestion would make older LSCP scripts, and
qsampler for that matter, forward compatible with the new server engine
protocol, so prevent the already released code from choking with the
latest server development path.

As usual, I can set my efforts on patching linuxsampler for you to try
out. However, I'm affraid this has implications on changing the parser
grammar/lexical source files (src/network/{lscp.y, lscp.l}) for which I've
been a complete failure on how to put them to regenerate a proper parser.

I though it would be sufficient to issue `make parser` under src/network,
but that's been failing on my face. Either my flex/bison installation is
bad or it is *me* that is doing it miserably wrong.

e.g. my flex doesn't recognize those --fast and --8bit command line
options, only -f and -8 respectively; then it also fails with:
"lscp.l", 33: unrecognized %option: reentrant

Currently using flex-2.5.4a and bison-1.875 (Mdk 10.0 Official).

Maybe someone could help me out, before I do some terrible mistake ;)

Any flex/bison gurus out there? Simon? ;)

Cheers.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] [linuxsampler] Latest CVS Commit

[Simon J. <sje...@bl...>]

Rui Nuno Capela wrote:

>[...] What about that all-upper-case restriction for command keywords? And the
>parameter key names _must_ be capitalized or sort of.
>
My suggestion was that "key names _must_ not match keywords" be the only 
rule -
its sufficient - and that key names be mixed case by convention, rather 
than by law.
That would allow for the occasional upper-case name where it made sense, 
eg for
acronyms (still use ALSA rather than Alsa).

The keywords are all upper case because... thats just the way they are. 
Its not a rule
exactly (or IMHO shouldn't be) its simply the convention that was 
chosen/adopted.

(FWIW I don't particularly like the upper case keywords because
1) its less readable,
2) its less typeable,
3) there's no need to shout, and
4) it isn't 1976 any more.
But its not my place to rework the protocol according to my personal 
tastes/prejudices,
especially when I lurked my way through the first eight drafts and am 
not involved in
the software at either end of the link. So I'm just offering what help I 
can to make the
parser work at all).

>Isn't it too restrictive? I'd rather have LSCP case insensitive al together.
>
There's not much advantage in making the protocol case insensitive. Its 
not like
the software at either end is going to forget to press the shift key. 
More likely it
would fail to match an oddly cased key name because someone forgot 
ToUpper().
OK, some people might need to type LSCP by hand, but with a consistent 
set of
conventions it shouldn't be too hard for them to get it right.

The disadvantages of case insensitivity are
1) extra work in the lexical analyser and
2) extra opportunity for name/keyword clashes: It would no longer be 
possible to
use the key name "Channel" because it would now clash with the keyword 
"CHANNEL".

>Again, putting my logs into the fire ;)
>  
>
Me too. And its not even my fire.

Simon Jenkins
(Bristol, UK).

Re: [Linuxsampler-devel] [linuxsampler] Latest CVS Commit

[Rui N. C. <rn...@rn...>]

Hi Simon,
>
>>However I personally find this new quoting requirement rather strange.
>>Forgive my lex/yacc ignorance, but is it really unavoidable? Is it really
>>impossible having a syntax where a token is distinguishable from a
>>arbitrary literal value? Is it a lex/yacc fundamental limitation or what?
>>I'd rather have quotes optional, and only required where strictly
>>necessary, like e.g. in comma-separated list items.
>>
> I'm not sure the quoting was actually /unavoidable/. I suggested a couple
> of ways the parser might have been fixed without introducing quotes but
> they were difficult and/or inefficient and i'm not 100% sure they would
> have worked.
>
> The argument for the introduction of quotes is:
>
> Its easier and more efficient to tokenise the protocol and then parse the
> token-stream than it is to parse the protocol directly one character at
> a time. Thats why lex and yacc exist as two separate tools.
>
> To tokenise the protocol its parts must be /lexically/ (as opposed to
> syntactically) distinguishable from each other.
>
> The protocol carries arbitrary, user-entered strings, eg channel names,
> which can only be lexically distinguished if they are delimited in some
> way.
>
> Hence the quotes.
>
> Note that it is ONLY the values of string parameters which have the
> quotes now. Setting a channel name looks like this:
>
> SET AUDIO_OUTPUT_CHANNEL PARAMETER 0 0 Name ="Monitor Left"
>
> but setting a numerical parameter is still:
>
> SET AUDIO_OUTPUT_CHANNEL PARAMETER 0 0 Whatever=2.27
>
> Note also: The lexical analyser needs the quotes to see the strings...
> but it "eats" the quotes as soon as it has seen them. It gives the
> parser a string without quotes, and thats what the parser gives the
> server.
>
> Its the packaging that has been changed, not the contents.
>

All right. The way it is, and as you've clarified above, it's in fact my
personal preference, so we're all happy now.

But (there's always a but :) maybe it isn't all about the quoting. What
about that all-upper-case restriction for command keywords? And the
parameter key names _must_ be capitalized or sort of.

Isn't it too restrictive? I'd rather have LSCP case insensitive al together.

Again, putting my logs into the fire ;)
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] Latest CVS Commit

[Vladimir S. <ha...@so...>]

Hi All,

Finally with some fixes and hacks CREATE AUDIO_OUTPUT_DEVICE is looking 
better.
Background seems to be working ok too. (if not for that other crash i 
was mentioning before having to do with the fact that we can't set the 
audio output type yet).
A lot of stuff still doesn't work. That includes destroying 
audio_output_devices, working with midi devices, mapping audio output 
devices to channels, detecting card specific parameter defaults and 
ranges etc, etc.
I'm going to try to fix some of those issues next weekend. Time is tight 
so bear with me.

Cheers,
Vladimir.

Fwd: Re: [Linuxsampler-devel] [linuxsampler] Latest CVS Commit

[Simon J. <sje...@bl...>]

Rui Nuno Capela wrote:

>However I personally find this new quoting requirement rather strange.
>Forgive my lex/yacc ignorance, but is it really unavoidable? Is it really
>impossible having a syntax where a token is distinguishable from a
>arbitrary literal value? Is it a lex/yacc fundamental limitation or what? 
>I'd rather have quotes optional, and only required where strictly
>necessary, like e.g. in comma-separated list items.
>

I'm not sure the quoting was actually /unavoidable/. I suggested a couple of
ways the parser might have been fixed without introducing quotes but they
were difficult and/or inefficient and i'm not 100% sure they would have
worked.

The argument for the introduction of quotes is:

Its easier and more efficient to tokenise the protocol and then parse the
token-stream than it is to parse the protocol directly one character at
a time. Thats why lex and yacc exist as two separate tools.

To tokenise the protocol its parts must be /lexically/ (as opposed to
syntactically) distinguishable from each other.

The protocol carries arbitrary, user-entered strings, eg channel names,
which can only be lexically distinguished if they are delimited in some
way.

Hence the quotes.

Note that it is ONLY the values of string parameters which have the
quotes now. Setting a channel name looks like this:

SET AUDIO_OUTPUT_CHANNEL PARAMETER 0 0 Name="Monitor Left"

but setting a numerical parameter is still:

SET AUDIO_OUTPUT_CHANNEL PARAMETER 0 0 Whatever=2.27

Note also: The lexical analyser needs the quotes to see the strings,
but it "eats" the quotes as soon as it has seen them. It gives the
parser a string without quotes, and thats what the parser gives the
server.

Its the packaging that has been changed, not the contents.

Simon Jenkins
(Bristol, UK)

Re: [Linuxsampler-devel] [linuxsampler] Latest CVS Commit

[Vladimir S. <ha...@so...>]

Hi Rui,

Thanks!
I'll put that code to work asap (after i fix CREATE AUDIO_OUTPUT_DEVICE).
I should have no problems now with the parser now after all that help 
from Simon.

Regards,
Vladimir

Rui Nuno Capela wrote:

>Hi,
>
>linuxsampler 0.2.x:
>
>* Changed LSCPServer::LoadInstrument() signature, which adds a new
>  boolean argument (bool bBackground) where the loading mode maybe
>  selected, whether modal (the default), or modeless (in background).
>
>This means that the LOAD INSTRUMENT command is back to the old modal
>behavior, and the new LOAD_BACKGROUND INSTRUMENT just waits to be
>implemented. These will be the intended mappings:
>
>  LOAD INSTRUMENT <file> <index> <channel>
>     -> LoadInstrument(file, index, channel, false);
>
>  LOAD_BACKGROUND INSTRUMENT <file> <index> <channel>
>     -> LoadInstrument(file, index, channel, true);
>
>So, I'll ask the you lex/yacc gurus to put it to work asap :)
>
>OTOH, this post of mine didn't get to the list, AFAICT, so I'll repeat it
>here...
>
>Hi Vladimir,
>Christian,
>Simon,
>everybody
>
>About the LOAD INSTRUMENT command, I've been doing simple implementation
>changes (see attached patch). However I've stumbled on the
>(f)lex/yacc/bison mysteries.
>
>The fault is that my flex and bison installed packages probably aren't up
>to par--they fail miserably while doing `make parser` under src/network.
>I've give up for now.
>
>My patch does try to implement the background mode for the LOAD
>INSTRUMENT. However, I've bee trying to implement the following syntax:
>
>    LOAD INSTRUMENT <filename> <index> <channel> BACKGROUND
>
>where I've introduced the BACKGROUND token to flag the modeless option.
>I've noticed that Vladimir suggested a new LOAD_BACKGROUND verb instead of
>an optional trailing particle like me. Of course, I prefer mine, but our
>dictator must be heard ;)
>
>Either way, the main change, which I think is about to stay, goes in 
>lscpserver.h/cpp, where I added a new boolean argument to
>LSCPServer::LoadInstrument method (bool bBackground), where one opts for
>the precise loading mode (default is false, that is modal).
>
>Please try the patch and please help me on putting that damned flex/bison
>stuff to work.
>
>About the new quoting requirements, I'm all for it. Incidentally I was
>predicting that myself, the bare proof is that liblscp implementation is
>already prepared on parsing quoted responses. It even does not matter if
>are single (') our double (").
>
>However I personally find this new quoting requirement rather strange.
>Forgive my lex/yacc ignorance, but is it really unavoidable? Is it really
>impossible having a syntax where a token is distinguishable from a
>arbitrary literal value? Is it a lex/yacc fundamental limitation or what? 
>I'd rather have quotes optional, and only required where strictly
>necessary, like e.g. in comma-separated list items.
>
>Bye now.
>  
>
>------------------------------------------------------------------------
>
>diff -duPNr linuxsampler-0.2-cvs20040619a/src/network/lscpserver.cpp linuxsampler-0.2-cvs20040619b/src/network/lscpserver.cpp
>--- linuxsampler-0.2-cvs20040619a/src/network/lscpserver.cpp	2004-06-19 20:16:49.000000000 +0100
>+++ linuxsampler-0.2-cvs20040619b/src/network/lscpserver.cpp	2004-06-19 23:17:54.332470712 +0100
>@@ -132,7 +132,7 @@
> /**
>  * Will be called by the parser to load an instrument.
>  */
>-String LSCPServer::LoadInstrument(String Filename, uint uiInstrument, uint uiSamplerChannel) {
>+String LSCPServer::LoadInstrument(String Filename, uint uiInstrument, uint uiSamplerChannel, bool bBackground) {
>     dmsg(2,("LSCPServer: LoadInstrument(Filename=%s,Instrument=%d,SamplerChannel=%d)\n", Filename.c_str(), uiInstrument, uiSamplerChannel));
>     LSCPResultSet result;
>     try {
>@@ -140,8 +140,11 @@
>         if (!pSamplerChannel) throw LinuxSamplerException("Index out of bounds");
>         Engine* pEngine = pSamplerChannel->GetEngine();
>         if (!pEngine) throw LinuxSamplerException("No engine loaded on channel");
>-        LSCPLoadInstrument *pLoadInstrument = new LSCPLoadInstrument(pEngine, Filename.c_str(), uiInstrument);
>-        pLoadInstrument->StartThread();
>+        if (bBackground) {
>+            LSCPLoadInstrument *pLoadInstrument = new LSCPLoadInstrument(pEngine, Filename.c_str(), uiInstrument);
>+            pLoadInstrument->StartThread();
>+        }
>+        else pEngine->LoadInstrument(Filename.c_str(), uiInstrument);
>     }
>     catch (LinuxSamplerException e) {
>          result.Error(e);
>diff -duPNr linuxsampler-0.2-cvs20040619a/src/network/lscpserver.h linuxsampler-0.2-cvs20040619b/src/network/lscpserver.h
>--- linuxsampler-0.2-cvs20040619a/src/network/lscpserver.h	2004-06-19 20:16:49.000000000 +0100
>+++ linuxsampler-0.2-cvs20040619b/src/network/lscpserver.h	2004-06-19 23:17:54.332470712 +0100
>@@ -59,7 +59,7 @@
>         // Methods called by the parser
>         String CreateAudioOutputDevice(String Driver, std::map<String,String> Parameters);
>         String DestroyAudioOutputDevice(uint DeviceIndex);
>-        String LoadInstrument(String Filename, uint uiInstrument, uint uiSamplerChannel);
>+        String LoadInstrument(String Filename, uint uiInstrument, uint uiSamplerChannel, bool bBackground = false);
>         String LoadEngine(String EngineName, uint uiSamplerChannel);
>         String GetChannels();
>         String AddChannel();
>diff -duPNr linuxsampler-0.2-cvs20040619a/src/network/lscp.y linuxsampler-0.2-cvs20040619b/src/network/lscp.y
>--- linuxsampler-0.2-cvs20040619a/src/network/lscp.y	2004-06-14 20:33:15.000000000 +0100
>+++ linuxsampler-0.2-cvs20040619b/src/network/lscp.y	2004-06-19 23:17:54.332470712 +0100
>@@ -59,6 +59,7 @@
> %token INSTRUMENT ENGINE
> %token AUDIO_OUTPUT_CHANNEL AUDIO_OUTPUT_CHANNEL_PARAMETER AUDIO_OUTPUT_DEVICE AUDIO_OUTPUT_DEVICES AUDIO_OUTPUT_DEVICE_PARAMETER AUDIO_OUTPUT_DRIVER AUDIO_OUTPUT_DRIVER_PARAMETER MIDI_INPUT_PORT MIDI_INPUT_CHANNEL MIDI_INPUT_TYPE VOLUME
> %token BYTES PERCENTAGE
>+%token BACKGROUND
> 
> %type <Dotnum> volume
> %type <Number> sampler_channel instrument_index udp_port audio_output_channel midi_input_channel
>@@ -156,7 +157,8 @@
> list_instruction      :  AUDIO_OUTPUT_DEVICES  { $$ = LSCPSERVER->GetAudioOutputDevices(); }
>                       ;
> 
>-load_instr_args       :  filename SP instrument_index SP sampler_channel  { $$ = LSCPSERVER->LoadInstrument($1, $3, $5); }
>+load_instr_args       :  filename SP instrument_index SP sampler_channel  { $$ = LSCPSERVER->LoadInstrument($1, $3, $5, false); }
>+                      |  filename SP instrument_index SP sampler_channel SP BACKGROUND  { $$ = LSCPSERVER->LoadInstrument($1, $3, $5, true); }
>                       ;
> 
> load_engine_args      :  engine_name SP sampler_channel  { $$ = LSCPSERVER->LoadEngine($1, $3); }
>

[Linuxsampler-devel] [linuxsampler] Latest CVS Commit

[Rui N. C. <rn...@rn...>]

Hi,

linuxsampler 0.2.x:

* Changed LSCPServer::LoadInstrument() signature, which adds a new
  boolean argument (bool bBackground) where the loading mode maybe
  selected, whether modal (the default), or modeless (in background).

This means that the LOAD INSTRUMENT command is back to the old modal
behavior, and the new LOAD_BACKGROUND INSTRUMENT just waits to be
implemented. These will be the intended mappings:

  LOAD INSTRUMENT <file> <index> <channel>
     -> LoadInstrument(file, index, channel, false);

  LOAD_BACKGROUND INSTRUMENT <file> <index> <channel>
     -> LoadInstrument(file, index, channel, true);

So, I'll ask the you lex/yacc gurus to put it to work asap :)

OTOH, this post of mine didn't get to the list, AFAICT, so I'll repeat it
here...

Hi Vladimir,
Christian,
Simon,
everybody

About the LOAD INSTRUMENT command, I've been doing simple implementation
changes (see attached patch). However I've stumbled on the
(f)lex/yacc/bison mysteries.

The fault is that my flex and bison installed packages probably aren't up
to par--they fail miserably while doing `make parser` under src/network.
I've give up for now.

My patch does try to implement the background mode for the LOAD
INSTRUMENT. However, I've bee trying to implement the following syntax:

    LOAD INSTRUMENT <filename> <index> <channel> BACKGROUND

where I've introduced the BACKGROUND token to flag the modeless option.
I've noticed that Vladimir suggested a new LOAD_BACKGROUND verb instead of
an optional trailing particle like me. Of course, I prefer mine, but our
dictator must be heard ;)

Either way, the main change, which I think is about to stay, goes in 
lscpserver.h/cpp, where I added a new boolean argument to
LSCPServer::LoadInstrument method (bool bBackground), where one opts for
the precise loading mode (default is false, that is modal).

Please try the patch and please help me on putting that damned flex/bison
stuff to work.

About the new quoting requirements, I'm all for it. Incidentally I was
predicting that myself, the bare proof is that liblscp implementation is
already prepared on parsing quoted responses. It even does not matter if
are single (') our double (").

However I personally find this new quoting requirement rather strange.
Forgive my lex/yacc ignorance, but is it really unavoidable? Is it really
impossible having a syntax where a token is distinguishable from a
arbitrary literal value? Is it a lex/yacc fundamental limitation or what? 
I'd rather have quotes optional, and only required where strictly
necessary, like e.g. in comma-separated list items.

Bye now.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] Latest CVS commit

[Vladimir S. <ha...@so...>]

Hi All,

Thanks Simon! I've tried to achieve the desired effect with minimum 
changes to the code. I've used your string parser. Things look a bit 
better. I think for now i'll leave tokeniser/parser alone (i think it 
more or less does what needs to be done at this point) and try to fix 
some of the other issues.

I've updated the spec again in the events section to simplify things a 
bit (credit goes to Rui, he had the right idea there a while ago, i just 
didn't pay attention :)

I've checked in some stuff:

* Updated parser to comply with the spec
* Updated audio driver stuff to comply with the spec
* Reimplemented subscribe/unsubscribe in the parser to match the spec
* Corrected an important typo in optional.h

At this point there are still a lot of things not working (like audio 
device creation :)
But i'm hoping to get some of that fixed tonight.
I've done very little testing so far, but will do more.
This seems to work now:

GET AVAILABLE_AUDIO_OUTPUT_DRIVERS
GET AUDIO_OUTPUT_DRIVER INFO Alsa
GET AUDIO_OUTPUT_DRIVER INFO Jack
GET AUDIO_OUTPUT_DRIVER_PARAMETER INFO Alsa active
GET AUDIO_OUTPUT_DRIVER_PARAMETER INFO Alsa card
GET AUDIO_OUTPUT_DRIVER_PARAMETER INFO Alsa channels
GET AUDIO_OUTPUT_DRIVER_PARAMETER INFO Alsa fragments
GET AUDIO_OUTPUT_DRIVER_PARAMETER INFO Alsa fragmentsize
GET AUDIO_OUTPUT_DRIVER_PARAMETER INFO Alsa samplerate
GET AUDIO_OUTPUT_DRIVER_PARAMETER INFO Jack active
GET AUDIO_OUTPUT_DRIVER_PARAMETER INFO Jack channels
GET AUDIO_OUTPUT_DRIVER_PARAMETER INFO Jack samplerate

Regards,
Vladimir.

Simon Jenkins wrote:

> Vladimir ~
>
> I've knocked together some test files, attached.
>
> The lexical analyser handles strings (double-quoted, but that could be 
> changed) including C-style
> escapes (\n, \t etc) and names, ie unquoted strings of the form 
> [A-Za-z_][A-Za-z0-9_]*.
> It doesn't know that "names MUST not be all upper case", but it 
> doesn't have to... thats a rule
> for developers to follow, and if they break it then things might not 
> work. It also handles the
> whitespace and comments, so the parser doesn't have to.
>
> The parser can understand a few of the lscp commands, including the
> CREATE AUDIO_OUTPUT_DEVICE command with multiple key/value parameters 
> which is
> the one I was a bit worried about. When it understands a command it 
> calls a fake LSCPSERVER
> which prints out the calls and the parameters it gets.
>
> to build the test:
> 1) Put the attached files in a directory
> 2) type "make"
>
> to run the test:
> 1) type "./test"
> 2) type any one of the six lscp commands that the test parser so far 
> understands
> 3) hit return
> 4) goto 2)
>
> eg you type...
> CREATE AUDIO_OUTPUT_DEVICE Test Hair="Red" Eyes="Blue" Age=23
>
> and you should see...
>
> CreateAudioOutputDevice() called.
>    Name: Test
>    Param: Hair = "Red"
>    Param: Eyes = "Blue"
>    Param: Age = 23
> AnswerClient() called with string "Response".
>
> Its a bit messy in places, but it handles what needed to be handled. 
> You can
> take whatever you find useful from it and ignore the rest.
>
> Simon Jenkins
> (Bristol, UK)
>
>------------------------------------------------------------------------
>
>/***************************************************************************
> *                                                                         *
> *   LinuxSampler - modular, streaming capable sampler                     *
> *                                                                         *
> *   Copyright (C) 2003, 2004 by Benno Senoner and Christian Schoenebeck   *
> *                                                                         *
> *   This program is free software; you can redistribute it and/or modify  *
> *   it under the terms of the GNU General Public License as published by  *
> *   the Free Software Foundation; either version 2 of the License, or     *
> *   (at your option) any later version.                                   *
> *                                                                         *
> *   This program is distributed in the hope that it will be useful,       *
> *   but WITHOUT ANY WARRANTY; without even the implied warranty of        *
> *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the         *
> *   GNU General Public License for more details.                          *
> *                                                                         *
> *   You should have received a copy of the GNU General Public License     *
> *   along with this program; if not, write to the Free Software           *
> *   Foundation, Inc., 59 Temple Place, Suite 330, Boston,                 *
> *   MA  02111-1307  USA                                                   *
> ***************************************************************************/
>
>%{
>#include <string>
>#include <map>
>#include "lscptest.h"
>#include "y.tab.h"
>%}
>
>%x INSTRING
>
>exponent	[Ee]"-"?[0-9]+
>floatvalue	[0-9]+"."[0-9]+{exponent}?
>intvalue	[0-9]+
>name		[A-Za-z_][[A-Za-z0-9_]*
>
>%%
>
>"\r"									{} // ignore CR
>[ \t]+									{} // ignore whitespace
>"#"[^\n]*$ 								{} // ignore comment
>
>"\n"									{ return EOL; } // LF is end of line
>
>"ADD"                                   { return ADD; }
>"GET"                                   { return GET; }
>"CREATE"                                { return CREATE; }
>"DESTROY"                               { return DESTROY; }
>"LIST"                                  { return LIST; }
>"LOAD"                                  { return LOAD; }
>"REMOVE"                                { return REMOVE; }
>"SET"                                   { return SET; }
>"SUBSCRIBE"                             { return SUBSCRIBE; }
>"UNSUBSCRIBE"                           { return UNSUBSCRIBE; }
>"CHANNEL"                               { return CHANNEL; }
>"NOTIFICATION"                          { return NOTIFICATION; }
>"AVAILABLE_ENGINES"                     { return AVAILABLE_ENGINES; }
>"AVAILABLE_AUDIO_OUTPUT_DRIVERS"        { return AVAILABLE_AUDIO_OUTPUT_DRIVERS; }
>"CHANNELS"                              { return CHANNELS; }
>"INFO"                                  { return INFO; }
>"BUFFER_FILL"                           { return BUFFER_FILL; }
>"STREAM_COUNT"                          { return STREAM_COUNT; }
>"VOICE_COUNT"                           { return VOICE_COUNT; }
>"INSTRUMENT"                            { return INSTRUMENT; }
>"ENGINE"                                { return ENGINE; }
>"AUDIO_OUTPUT_DEVICE"                   { return AUDIO_OUTPUT_DEVICE; }
>"AUDIO_OUTPUT_DEVICES"                  { return AUDIO_OUTPUT_DEVICES; }
>"AUDIO_OUTPUT_DEVICE_PARAMETER"         { return AUDIO_OUTPUT_DEVICE_PARAMETER; }
>"AUDIO_OUTPUT_DRIVER"                   { return AUDIO_OUTPUT_DRIVER; }
>"AUDIO_OUTPUT_DRIVER_PARAMETER"         { return AUDIO_OUTPUT_DRIVER_PARAMETER; }
>"AUDIO_OUTPUT_CHANNEL"                  { return AUDIO_OUTPUT_CHANNEL; }
>"AUDIO_OUTPUT_CHANNEL_PARAMETER"        { return AUDIO_OUTPUT_CHANNEL_PARAMETER; }
>"MIDI_INPUT_PORT"                       { return MIDI_INPUT_PORT; }
>"MIDI_INPUT_CHANNEL"                    { return MIDI_INPUT_CHANNEL; }
>"MIDI_INPUT_TYPE"                       { return MIDI_INPUT_TYPE; }
>"VOLUME"                                { return VOLUME; }
>"BYTES"                                 { return BYTES; }
>"PERCENTAGE"                            { return PERCENTAGE; }
>"RESET"                                 { return RESET; }
>"QUIT"                                  { return QUIT; }
>{name}									{ yylval.String = new std::string(yytext); return NAME; }
>
>"="                                     { return '='; }
>
>{intvalue}								{ yylval.Int = atoi(yytext); return INTVAL; }
>{floatvalue}							{ yylval.Float = strtod(yytext, 0); return FLOATVAL; }
>
>"\""									{ yylval.String = new std::string;  BEGIN(INSTRING); }
><INSTRING>[^\"\\]+						{ *(yylval.String) += yytext; }
><INSTRING>"\\n"							{ *(yylval.String) += '\n'; }
><INSTRING>"\\r"							{ *(yylval.String) += '\r'; }
><INSTRING>"\\t"							{ *(yylval.String) += '\t'; }
><INSTRING>"\\\\"						{ *(yylval.String) += '\\'; }
><INSTRING>"\\\""						{ *(yylval.String) += '\"'; }
><INSTRING>"\\"[^nrt\"\\]				{ *(yylval.String) += yytext; }
><INSTRING>"\""							{ BEGIN(INITIAL); return STRINGVAL; }
>
>%%
>  
>
>------------------------------------------------------------------------
>
>/***************************************************************************
> *                                                                         *
> *   LinuxSampler - modular, streaming capable sampler                     *
> *                                                                         *
> *   Copyright (C) 2003, 2004 by Benno Senoner and Christian Schoenebeck   *
> *                                                                         *
> *   This program is free software; you can redistribute it and/or modify  *
> *   it under the terms of the GNU General Public License as published by  *
> *   the Free Software Foundation; either version 2 of the License, or     *
> *   (at your option) any later version.                                   *
> *                                                                         *
> *   This program is distributed in the hope that it will be useful,       *
> *   but WITHOUT ANY WARRANTY; without even the implied warranty of        *
> *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the         *
> *   GNU General Public License for more details.                          *
> *                                                                         *
> *   You should have received a copy of the GNU General Public License     *
> *   along with this program; if not, write to the Free Software           *
> *   Foundation, Inc., 59 Temple Place, Suite 330, Boston,                 *
> *   MA  02111-1307  USA                                                   *
> ***************************************************************************/
>%start startsymbol
>
>%{
>#include <stdio.h>
>#include <string>
>#include <map>
>#include <iostream>
>#include "lscptest.h"
>%}
>
>%union
>{
>	int	 Int;
>	float Float;
>	std::string *String;
>	CKeyedValue *KeyedValue;
>    tValueMap *ValueMap;
>}
>
>%token ADD GET CREATE DESTROY LIST LOAD REMOVE
>%token SET SUBSCRIBE UNSUBSCRIBE CHANNEL NOTIFICATION
>%token AVAILABLE_ENGINES AVAILABLE_AUDIO_OUTPUT_DRIVERS CHANNELS
>%token INFO BUFFER_FILL STREAM_COUNT VOICE_COUNT INSTRUMENT
>%token ENGINE AUDIO_OUTPUT_DEVICE AUDIO_OUTPUT_DEVICES
>%token AUDIO_OUTPUT_DEVICE_PARAMETER AUDIO_OUTPUT_DRIVER
>%token AUDIO_OUTPUT_DRIVER_PARAMETER AUDIO_OUTPUT_CHANNEL
>%token AUDIO_OUTPUT_CHANNEL_PARAMETER MIDI_INPUT_PORT
>%token MIDI_INPUT_CHANNEL MIDI_INPUT_TYPE VOLUME BYTES
>%token PERCENTAGE RESET QUIT
>%token EOL
>
>%token <Int> INTVAL
>%token <Float> FLOATVAL
>%token <String> STRINGVAL
>%token <String> NAME
>
>%type <Int> input
>%type <String> command
>%type <KeyedValue> keyed_value
>%type <ValueMap> value_map
>
>%{
>
>int yyerror(char *string) {
>	cout << std::string(string) << '\n';
>}
>
>int yyparse(void);
>int yylex(void);  
>int yywrap() {
>	return 1;
>}
>	
>TestServer *LSCPSERVER;
>
>int main( int argc, char **argv )
>{
>	LSCPSERVER = new TestServer;
>	yyparse();
>}
>
>%}
>
>%%
>
>startsymbol : input { printf("done.\n", $1); };
>
>input	 	: /* empty */		{ }
>			| input EOL			{ std::cout << "Empty line ignored\n"; }
>			| input command EOL	{ LSCPSERVER->AnswerClient($2); };
>
>command		: ADD CHANNEL 													{ $$ = LSCPSERVER->AddChannel(); }
>			| GET AVAILABLE_ENGINES     									{ $$ = LSCPSERVER->GetAvailableEngines(); }
>			| GET AVAILABLE_AUDIO_OUTPUT_DRIVERS    						{ $$ = LSCPSERVER->GetAvailableAudioOutputDrivers(); }
>            | GET AUDIO_OUTPUT_DRIVER INFO NAME								{ $$ = LSCPSERVER->GetAudioOutputDriverInfo($4); }
>			| GET AUDIO_OUTPUT_DRIVER_PARAMETER INFO NAME NAME				{ $$ = LSCPSERVER->GetAudioOutputDriverParameterInfo($4, $5); };
>			| CREATE AUDIO_OUTPUT_DEVICE NAME value_map						{ $$ = LSCPSERVER->CreateAudioOutputDevice($3,$4); }   ;
>						
>keyed_value : STRINGVAL { $$ = new CKeyedValue($1); }
>			| INTVAL { cout << "int value!\n"; $$ = new CKeyedValue(99); }
>			| FLOATVAL { $$ = new CKeyedValue($1); };
>
>value_map	: /* empty */						{ $$ = new tValueMap; }
>			| value_map NAME '=' keyed_value	{ $$ = $1; (*$1)[*$2] = $4; delete $2; };
>
>%%
>
>  
>
>------------------------------------------------------------------------
>
>
>enum eKeyedValueType { IsString, IsInt, IsFloat };
>
>struct CKeyedValue
>{
>	CKeyedValue( std::string *S ) : m_Type(IsString) { m_Value.String = S; }
>	CKeyedValue( int I ) 		  : m_Type(IsInt) 	 { m_Value.Int = I; }
>	CKeyedValue( float F ) 		  : m_Type(IsFloat)  { m_Value.Float = F; }
>	
>	union {
>		std::string 	*String;
>		int				Int;
>		float			Float;
>	} m_Value;
>
>	eKeyedValueType m_Type;
>};
>
>typedef std::map<std::string, CKeyedValue *> tValueMap;
>
>class TestServer
>{
>public:
>
>	void AnswerClient( std::string *S ) {
>		std::cout << "AnswerClient() called with string \"" << *S << "\".\n";
>		delete S;
>	}
>	
>	std::string *AddChannel( void ) {
>		std::cout << "AddChannel() called.\n";
>		return new std::string( "response" );
>	}
>
>	std::string *GetAvailableEngines( void ) {
>		std::cout << "GetAvailableEngines() called. \n";
>		return new std::string( "response" );
>	}
>	
>	std::string *GetAvailableAudioOutputDrivers( void ) {
>		std::cout << "GetAvailableAudioOutputDrivers() called. \n";
>		return new std::string( "response" );
>	}
>	
>	std::string *GetAudioOutputDriverInfo( std::string *S ) {
>		std::cout << "GetAudioOutputDriverInfo() called with string \"" << *S << "\".\n";
>		delete S;
>		return new std::string( "response" );
>	}
>
>	std::string *GetAudioOutputDriverParameterInfo( std::string *A, std::string *B ) {
>		std::cout << "GetAudioOutputDriverParameterInfo() called with strings: \n"
>				  << "\t\"" << *A << "\"\n"
>				  << "\t\"" << *B << "\"\n";
>		delete A;
>		delete B;
>		return new std::string( "response" );
>	}
>
>	std::string *CreateAudioOutputDevice( std::string *S, tValueMap *M ) {
>
>		std::cout << "CreateAudioOutputDevice() called.\n"
>				<< "\tName: " << *S << "\n";
>				
>		tValueMap::iterator i;
>		
>		for( i = M->begin(); i != M->end(); i++ ) {
>			cout << "\tParam: " << i->first << " = ";
>			
>			switch( i->second->m_Type ) {
>				case IsString: cout << "\"" << *(i->second->m_Value.String) << "\""; break;
>				case IsInt: cout << i->second->m_Value.Int; break;
>				case IsFloat: cout << i->second->m_Value.Float; break;
>			}
>			cout << "\n";
>		}
>		
>		return new std::string( "response" );
>	}
>};
>  
>
>------------------------------------------------------------------------
>
>CPPFLAGS = -o1
>
>all: test
>
>test: y.tab.c lex.yy.c lscptest.h
>	g++ lex.yy.c y.tab.c $(CPPFLAGS) -lm -ll -lstdc++ -o test
>
>lex.yy.c: lscptest.l y.tab.c lscptest.h
>	flex lscptest.l
>
>y.tab.c: lscptest.y lscptest.h
>	yacc -d lscptest.y
>  
>

Re: [Linuxsampler-devel] [linuxsampler, liblscp] Latest CVS commit.

[Vladimir S. <ha...@so...>]

Rui,
Everybody,

I've just uploaded an updated version of the spec.

Changes:

* Address the tokenizer/parser issues with solutions discussed here 
previously: wrap strings with quotes, changing engine/driver/parameter 
names to avoid conflicts with tokens.
* Added a short section on what requests look like (similar to the 
result section that i've added before)
* Added LOAD_BACKGROUND command. I figured the same thing might one day 
happen to engine loading, that's why i picked this option.
* Added INSTRUMENT_STATUS field.
* took out some things that are not going to be used anymore.
* some minor typo fixes/rewording/etc

As usual, your feedback will be much appreciated . . .

Regards,
Vladimir.

Rui Nuno Capela wrote:

>Hi,
>
>As I promised,
>
>
>linuxsampler 0.2..:
>
>* Load Instrument patch applied; this patch makes the
>  LOAD INSTRUMENT command to return immediately,
>  almost/always with an "OK" response, while spawning
>  the proper instrument file loading in the background.
>
>* New INSTRUMENT_STATUS field on GET CHANNEL INFO result
>  set; the instrument status value holds the load progress
>  percentage if positive, otherwise a negative value is
>  evidence of a load exception error.
>
>* VERSION is now set to 0.2.
>
>
>liblscp 0.1.9.100:
>
>* Overall mutexing of client command calls;
>  preparation of forthcoming v.09 LSCP document draft.
>
>
>Cheers.
>  
>

Re: [Linuxsampler-devel] Latest CVS commit

[Simon J. <sje...@bl...>]

Vladimir ~

I've knocked together some test files, attached.

The lexical analyser handles strings (double-quoted, but that could be 
changed) including C-style
escapes (\n, \t etc) and names, ie unquoted strings of the form 
[A-Za-z_][A-Za-z0-9_]*.
It doesn't know that "names MUST not be all upper case", but it doesn't 
have to... thats a rule
for developers to follow, and if they break it then things might not 
work. It also handles the
whitespace and comments, so the parser doesn't have to.

The parser can understand a few of the lscp commands, including the
CREATE AUDIO_OUTPUT_DEVICE command with multiple key/value parameters 
which is
the one I was a bit worried about. When it understands a command it 
calls a fake LSCPSERVER
which prints out the calls and the parameters it gets.

to build the test:
1) Put the attached files in a directory
2) type "make"

to run the test:
1) type "./test"
2) type any one of the six lscp commands that the test parser so far 
understands
3) hit return
4) goto 2)

eg you type...
CREATE AUDIO_OUTPUT_DEVICE Test Hair="Red" Eyes="Blue" Age=23

and you should see...

CreateAudioOutputDevice() called.
    Name: Test
    Param: Hair = "Red"
    Param: Eyes = "Blue"
    Param: Age = 23
AnswerClient() called with string "Response".

Its a bit messy in places, but it handles what needed to be handled. You can
take whatever you find useful from it and ignore the rest.

Simon Jenkins
(Bristol, UK)

Re: [Linuxsampler-devel] Latest CVS commit

[Vladimir S. <ha...@so...>]

Hello Simon,

Thanks again for your input!
Even though at the moment parameter names are added by ls developers i 
think restriction is required.
There may be multiple developers and we've already made mistakes there 
so i am sure this will happen again :)
Plus eventually ls might grow and drivers will be written by totally 
different folks. We already have multiplatform support . . . drivers are 
platform dependent have different parameters, etc, etc. Different 
developers tend to work on different platforms and tend to never talk to 
each other :)

So, I'm suggesting:
1) Filenames and other "user" strings MUST be wrapped in quotes. That 
includes all string parameter values examples include: CARD='0,0', 
ALSA_SEQ_BINDINGS='64:0'. This will have to be changed on both server 
and client.
2) All driver names, engine names, parameter names and any other names 
that are discovered by the client at runtime MUST NOT be completely 
uppercase. Since the client MUST discover parameters at real time using 
LSCP and MUST use parameter names AS-IS (in other words, client MUST NOT 
do tolower() or toupper() on those names or otherwise convert the 
capitalization/spelling of those names or otherwise modify those names) 
we are not really creating any new client requirements here.
3) All tokens MUST be completely uppercase. (and again MUST be treated 
on the client as case sensitive anyways, so no client changes here).

The only question i have about 1) is single quotes or double quotes. We 
are already using single quotes in the spec so i guess i'll go for that 
unless told otherwise.

Another question that i raised earlier in some discussions either on or 
off the list is about the "SET" command.
Today we allow two options:
"SET MIDI_INPUT_PORT PARAMETER 0 0 ALSA_SEQ_BINDINGS 64:0"
and
"SET MIDI_INPUT_PORT PARAMETER 0 0 ALSA_SEQ_BINDINGS=64:0"
I'd like to strike the first variant out and leave the second variant 
only (with EQ between parameter name and value).
If we take 1,2,3 points above into consideration this will become:
"SET MIDI_INPUT_PORT PARAMETER 0 0 alsa_seq_bindings='64:0'"

So unless anyone objects i'll go ahead . . .

Cheers! :)
Vladimir.

>> I have a few proposals for the tokenizer/parser issue.
>> First i'd like to wrap the filename in doublequotes. I have my mind 
>> set on that and i think it's the right thing to do so stop me now or 
>> i'll check that in.
>> Second i'm trying to figure out what to do about driver parameters.
>> Two ideas here:
>> 1) wrap them (for the lack of a better idea, again in doublequotes). 
>> This is OK, but  what about value pairs? Should i wrap the whole 
>> thing or  individual pair or individual names? for example:
>> GET AUDIO_OUTPUT_DRIVER INFO "ALSA"
>> GET AUDIO_OUTPUT_DRIVER_PARAMETER INFO "ALSA" "CARD"
>> CREATE AUDIO_OUTPUT_DEVICE "ALSA" "CARD='0,0' FRAGMENTS=3"
>> or
>> CREATE AUDIO_OUTPUT_DEVICE "ALSA" "CARD='0,0'" "FRAGMENTS=3"
>> or
>> CREATE AUDIO_OUTPUT_DEVICE "ALSA" "CARD"='0,0' "FRAGMENTS"=3
>
>
> I'd suggest
> CREATE AUDIO_OUTPUT_DEVICE "ALSA" Card="0,0" Fragments=3
> or
> CREATE AUDIO_OUTPUT_DEVICE ALSA Card="0,0" Fragments=3
> depending on whether we think "ALSA" is a name or a string in this 
> context. (Its not a key name or
> a string value so i haven't thought about it yet).
>
>> 2) make some rule that will help us to make sure that they don't 
>> match any tokens. I don't want to just tell people "make sure they 
>> are different" because that is not going to happen. Those things are 
>> at runtime, our spec is going to keep changing for a little while . . 
>> . So, the idea is to perhaps make a rule that all string parameters 
>> and string values MUST be lowercase and all tokens MUST be uppercase.
>> Or maybe parameters and values don't have to all be lowercase, but 
>> MUST at least have one lowercase character in them :) 
>
>
> For the key names, the rule  [A-Z_][A-Za-z0-9_]* /* MUST not match a 
> keyword */ is sufficient to
> fix the lexer/parser. Key names are chosen by linuxsampler coders ( 
> <--- is this /always/ true? ) so its
> a reasonable and enforceable rule. OTOH adopting the convention that 
> key names are mixed or lower
> case wouldn't hurt either, so i showed "Card" and "Fragments" in mixed 
> case in my example above.
>
> The same rule would work for strings too, but its not reasonable or 
> enforceable. We want  strings
> like "Monitor Left" and "0,0" which contain whitespace and 
> punctuation, and cannot prevent a user
> from trying to name a channel "CHANNEL" or "8" or "CHANNEL 8", nor 
> would we want to. So
> string values should be in quotes.
>
> Simon Jenkins
> (Bristol, UK)

Re: [Linuxsampler-devel] [linuxsampler, liblscp] Latest CVS commit.

[Christian S. <chr...@ep...>]

Hi!

Sorry for the late response, but the default behavior of the LOAD INSTRUMENT 
should stay modal. Escpecially in regards to LSCP scripts or simple 
frontends. So better add an optional argument to the command instead, e.g. 
NON_MODAL or LOAD_BACKGROUND or something. So

	LOAD INSTRUMENT 0 0 some.gig

would be the modal behavior and return only when the complete instrument was 
loaded and something like:

	LOAD INSTRUMENT NON_MODAL 0 0 some.gig

would immediately return. Agreed?

CU
Christian

Es geschah am Freitag, 18. Juni 2004 16:35 als Rui Nuno Capela schrieb:
> Hi,
>
> As I promised,
>
>
> linuxsampler 0.2..:
>
> * Load Instrument patch applied; this patch makes the
>   LOAD INSTRUMENT command to return immediately,
>   almost/always with an "OK" response, while spawning
>   the proper instrument file loading in the background.
>
> * New INSTRUMENT_STATUS field on GET CHANNEL INFO result
>   set; the instrument status value holds the load progress
>   percentage if positive, otherwise a negative value is
>   evidence of a load exception error.
>
> * VERSION is now set to 0.2.
>
>
> liblscp 0.1.9.100:
>
> * Overall mutexing of client command calls;
>   preparation of forthcoming v.09 LSCP document draft.
>
>
> Cheers.

Re: [Linuxsampler-devel] Latest CVS commit

[Simon J. <sje...@bl...>]

Vladimir Senkov wrote:

> Hi All,
>
> I have a few proposals for the tokenizer/parser issue.
> First i'd like to wrap the filename in doublequotes. I have my mind 
> set on that and i think it's the right thing to do so stop me now or 
> i'll check that in.
> Second i'm trying to figure out what to do about driver parameters.
> Two ideas here:
> 1) wrap them (for the lack of a better idea, again in doublequotes). 
> This is OK, but  what about value pairs? Should i wrap the whole thing 
> or  individual pair or individual names? for example:
> GET AUDIO_OUTPUT_DRIVER INFO "ALSA"
> GET AUDIO_OUTPUT_DRIVER_PARAMETER INFO "ALSA" "CARD"
> CREATE AUDIO_OUTPUT_DEVICE "ALSA" "CARD='0,0' FRAGMENTS=3"
> or
> CREATE AUDIO_OUTPUT_DEVICE "ALSA" "CARD='0,0'" "FRAGMENTS=3"
> or
> CREATE AUDIO_OUTPUT_DEVICE "ALSA" "CARD"='0,0' "FRAGMENTS"=3

I'd suggest
CREATE AUDIO_OUTPUT_DEVICE "ALSA" Card="0,0" Fragments=3
or
CREATE AUDIO_OUTPUT_DEVICE ALSA Card="0,0" Fragments=3
depending on whether we think "ALSA" is a name or a string in this 
context. (Its not a key name or
a string value so i haven't thought about it yet).

> 2) make some rule that will help us to make sure that they don't match 
> any tokens. I don't want to just tell people "make sure they are 
> different" because that is not going to happen. Those things are at 
> runtime, our spec is going to keep changing for a little while . . . 
> So, the idea is to perhaps make a rule that all string parameters and 
> string values MUST be lowercase and all tokens MUST be uppercase.
> Or maybe parameters and values don't have to all be lowercase, but 
> MUST at least have one lowercase character in them :) 

For the key names, the rule  [A-Z_][A-Za-z0-9_]* /* MUST not match a 
keyword */ is sufficient to
fix the lexer/parser. Key names are chosen by linuxsampler coders ( <--- 
is this /always/ true? ) so its
a reasonable and enforceable rule. OTOH adopting the convention that key 
names are mixed or lower
case wouldn't hurt either, so i showed "Card" and "Fragments" in mixed 
case in my example above.

The same rule would work for strings too, but its not reasonable or 
enforceable. We want  strings
like "Monitor Left" and "0,0" which contain whitespace and punctuation, 
and cannot prevent a user
from trying to name a channel "CHANNEL" or "8" or "CHANNEL 8", nor would 
we want to. So
string values should be in quotes.

Simon Jenkins
(Bristol, UK)

Re: [Linuxsampler-devel] [linuxsampler, liblscp] Latest CVS commit.

[Vladimir S. <ha...@so...>]

BTW loading instruments will not work right now LS because there was a 
crash there for a while when trying to load an instrument before audio 
output type is set. now that there is no command to set the audio output 
you just can't load any instruments :)
So i can't play around with that before we fix either the crash or the 
rest of the stuff :)

Regards,
Vladimir.

Rui Nuno Capela wrote:

>Hi,
>
>As I promised,
>
>
>linuxsampler 0.2..:
>
>* Load Instrument patch applied; this patch makes the
>  LOAD INSTRUMENT command to return immediately,
>  almost/always with an "OK" response, while spawning
>  the proper instrument file loading in the background.
>
>* New INSTRUMENT_STATUS field on GET CHANNEL INFO result
>  set; the instrument status value holds the load progress
>  percentage if positive, otherwise a negative value is
>  evidence of a load exception error.
>
>* VERSION is now set to 0.2.
>
>
>liblscp 0.1.9.100:
>
>* Overall mutexing of client command calls;
>  preparation of forthcoming v.09 LSCP document draft.
>
>
>Cheers.
>  
>

Re: [Linuxsampler-devel] Latest CVS commit

[Vladimir S. <ha...@so...>]

Hi All,

I have a few proposals for the tokenizer/parser issue.
First i'd like to wrap the filename in doublequotes. I have my mind set 
on that and i think it's the right thing to do so stop me now or i'll 
check that in.
Second i'm trying to figure out what to do about driver parameters.
Two ideas here:
1) wrap them (for the lack of a better idea, again in doublequotes). 
This is OK, but  what about value pairs? Should i wrap the whole thing 
or  individual pair or individual names? for example:
GET AUDIO_OUTPUT_DRIVER INFO "ALSA"
GET AUDIO_OUTPUT_DRIVER_PARAMETER INFO "ALSA" "CARD"
CREATE AUDIO_OUTPUT_DEVICE "ALSA" "CARD='0,0' FRAGMENTS=3"
or
CREATE AUDIO_OUTPUT_DEVICE "ALSA" "CARD='0,0'" "FRAGMENTS=3"
or
CREATE AUDIO_OUTPUT_DEVICE "ALSA" "CARD"='0,0' "FRAGMENTS"=3

2) make some rule that will help us to make sure that they don't match 
any tokens. I don't want to just tell people "make sure they are 
different" because that is not going to happen. Those things are at 
runtime, our spec is going to keep changing for a little while . . . So, 
the idea is to perhaps make a rule that all string parameters and string 
values MUST be lowercase and all tokens MUST be uppercase.
Or maybe parameters and values don't have to all be lowercase, but MUST 
at least have one lowercase character in them :)

3) use approach number 2 for parameter names but wrap string values 
because these may be punched in by the user in the GUI and a user may 
have a faulty keyboard with caps lock on :)

I kind of like 3 better, but i can't really explain why, just a feeling 
:) like i said before i'm not in any way a flex/bison guru, in fact this 
is probably the first time i'm dealing with it from this angle, so like 
dr evil said . . . please throw me a freakin' bone over here :) Point me 
to the right path, help me to avoid some of the mistakes that you made 
when you were younger :)
Just like you did before. I may not even require such great level of 
detail if you don't have time.
I'll appreciate it very much and try to check this in, give it some 
testing and fix other issues as much as i can this coming weekend. My 
goal is to get us back to the same level of functionality (at least) 
where we were before the last rewrite asap.

Regards,
Vladimir.

Re: [Linuxsampler-devel] Latest CVS commit

[Vladimir S. <ha...@so...>]

Hello Simon,

Thanks for providing such a good summary . . . I was about to start my 
weekend by doing some reading but now i can just focus on solving the 
problem, so thanks for saving me lots of time.
As you have guessed already the problems i'm having right now are with 
the PARAMETER=VALUE pairs that are driver specific and are learned by 
the client at runtime.
So if anything in those parameters (parameter names for example) is has 
a substring in it that happens to match a keyword (such as "CHANNEL" for 
example) then we are in trouble :(
Also, theoretically it's possible to run into this with filenames, etc.
I'll probably have to wrap filenames in quotes and wrap parameter=value 
pairs into something as well . . .

Cheers :)
Vladimir.

Simon Jenkins wrote:

>  Vladimir Senkov wrote:
>
>> Hi All,
>>
>> Having some issues with the parser. Apparently if we tell it that 
>> something should be a string it still recognizes tokens if they 
>> appear in that string and produces a syntax error :)
>> I'm no flex/bison guru, but i think i'll have to become one soon 
>> unless someone wants to point out to me what we are doing wrong there 
>> . . .
>
>
> IANAG but:
>
> The lex-generated tokeniser tokenises the input stream before the 
> bison-generated
> parser parses the tokenised result. Its too late telling bison that a 
> string followed by
> a character is a string when the tokeniser consumes any sub-strings 
> that match
> protocol keywords without the parser ever seeing the characters they 
> contained.
>
> You could (but almost certainly shouldn't :) ) try to solve it by 
> abandoning the
> tokeniser and doing all the keyword recognition in the parser, eg
>
>    add_keyword   :  'A' 'D' 'D' {};                        // <--- 
> don't actually try this
>    create_keyword   :  'C' 'R' 'E' 'A' 'T' 'E' {};    // <--- don't 
> actually try this
>
> etc etc.
>
> I say you shouldn't do this because I don't think it will ever work 
> properly. The
> grammar is already ambiguous where strings are concerned and this can 
> only
> make things worse.
>
> Another thing you could - but shouldn't - try would be to detokenise 
> keywords
> in the parser whenever they show up in the wrong place (assuming the 
> parser
> could ever work out where the wrong place was):
>
>    detok_key   : ADD { $$="ADD"; }
>                        | CREATE { $$="CREATE"; }
>                        | etc etc
>
>    string    : CHAR { std::string s; s = $1; $$ = s; }
>                | string CHAR { $$ = $1 + $2; }
>                | string detok_key { $$ = $1 + $2; }; // <------ LOL :)
>
> IMHO strings should be recognised in the tokeniser not the parser. To 
> do this
> the protocol would need to be changed slightly so anything that is an 
> arbitrary
> string (eg filenames, the values of string parameters) is /lexically/ 
> identifiable
> as a string. So put them in quotes or something, for example:
>
> SET AUDIO_OUTPUT_CHANNEL PARAMETER 0 0 NAME "monitor left"
> rather than
> SET AUDIO_OUTPUT_CHANNEL PARAMETER 0 0 NAME monitor left
>
> Now, according to the current grammar the keys in key/value pairs are 
> strings
> as well. (Ambiguous! does the above mean set "NAME" to be "monitor 
> left" or
> does it mean set "NAME monitor" to be "left"? Yes, we all know the 
> answer...
> but it isn 't contained in the grammar). This could be solved by 
> putting the keys
> in quotes as well but it might be better to restrict allowable key 
> names so they're
> not arbitrary strings any more, eg
>
> // (lex:)
> name [A-Za-z_] [A-Za-z0-9_]*
>
> and to forbid any key to match any protocol keyword.
>
> Simon Jenkins
> (Bristol, UK)
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] Latest CVS commit

[Simon J. <sje...@bl...>]

  Vladimir Senkov wrote:

> Hi All,
>
> Having some issues with the parser. Apparently if we tell it that 
> something should be a string it still recognizes tokens if they appear 
> in that string and produces a syntax error :)
> I'm no flex/bison guru, but i think i'll have to become one soon 
> unless someone wants to point out to me what we are doing wrong there 
> . . .

IANAG but:

The lex-generated tokeniser tokenises the input stream before the 
bison-generated
parser parses the tokenised result. Its too late telling bison that a 
string followed by
a character is a string when the tokeniser consumes any sub-strings that 
match
protocol keywords without the parser ever seeing the characters they 
contained.

You could (but almost certainly shouldn't :) ) try to solve it by 
abandoning the
tokeniser and doing all the keyword recognition in the parser, eg

    add_keyword   :  'A' 'D' 'D' {};                        // <--- 
don't actually try this
    create_keyword   :  'C' 'R' 'E' 'A' 'T' 'E' {};    // <--- don't 
actually try this

etc etc.

I say you shouldn't do this because I don't think it will ever work 
properly. The
grammar is already ambiguous where strings are concerned and this can only
make things worse.

Another thing you could - but shouldn't - try would be to detokenise 
keywords
in the parser whenever they show up in the wrong place (assuming the parser
could ever work out where the wrong place was):

    detok_key   : ADD { $$="ADD"; }
                        | CREATE { $$="CREATE"; }
                        | etc etc

    string    : CHAR { std::string s; s = $1; $$ = s; }
                | string CHAR { $$ = $1 + $2; }
                | string detok_key { $$ = $1 + $2; }; // <------ LOL :)

IMHO strings should be recognised in the tokeniser not the parser. To do 
this
the protocol would need to be changed slightly so anything that is an 
arbitrary
string (eg filenames, the values of string parameters) is /lexically/ 
identifiable
as a string. So put them in quotes or something, for example:

SET AUDIO_OUTPUT_CHANNEL PARAMETER 0 0 NAME "monitor left"
rather than
SET AUDIO_OUTPUT_CHANNEL PARAMETER 0 0 NAME monitor left

Now, according to the current grammar the keys in key/value pairs are 
strings
as well. (Ambiguous! does the above mean set "NAME" to be "monitor left" or
does it mean set "NAME monitor" to be "left"? Yes, we all know the answer...
but it isn 't contained in the grammar). This could be solved by putting 
the keys
in quotes as well but it might be better to restrict allowable key names 
so they're
not arbitrary strings any more, eg

// (lex:)
name [A-Za-z_] [A-Za-z0-9_]*

and to forbid any key to match any protocol keyword.

Simon Jenkins
(Bristol, UK)

[Linuxsampler-devel] [linuxsampler, liblscp] Latest CVS commit.

[Rui N. C. <rn...@rn...>]

Hi,

As I promised,


linuxsampler 0.2..:

* Load Instrument patch applied; this patch makes the
  LOAD INSTRUMENT command to return immediately,
  almost/always with an "OK" response, while spawning
  the proper instrument file loading in the background.

* New INSTRUMENT_STATUS field on GET CHANNEL INFO result
  set; the instrument status value holds the load progress
  percentage if positive, otherwise a negative value is
  evidence of a load exception error.

* VERSION is now set to 0.2.


liblscp 0.1.9.100:

* Overall mutexing of client command calls;
  preparation of forthcoming v.09 LSCP document draft.


Cheers.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] Load Instrument patch (2)

[Rui N. C. <rn...@rn...>]

hi benno,

> yeah I tried to apply your patch to the current CVS but hunks got
> rejected,
> I'll try again with this patch.

The former only applies to previous and nice working linuxsampler
snapshot, as you find on ls.org downloads section. This later applies to
CVS HEAD as of yesterday, at least.

> I did not try it yet but I took a peek at the patch and since you
> don't seem to do anything particularily hackish (which could upset
>  our dictator, aka cuse) :) I'd say if noone complains within 24h or so
>  just go ahead and commit it.

Depending on your notion of what's a hack, the patch introduces a new
class LSCPLoadInstrument, inherited from Thread, which the only purpose is
to spawn Engine::LoadInstrument() in background. No black hat hacker magic
;)

One thing I dislike is that self-delete on LSCPLoadInstrument::Main() last
line, but I think it seems safe for now.


> PS: regarding qsampler, liblscp  since I want to keep /usr/local clean
> I want to put qsampler and liblscp into my own dirs but the problem is
> when compiling qsampler you have to hack the configure script and/or
> the .pro file so that it detects the presence of liblscp and then sets
> the paths for -I and -L when compiling.
> Would it be possible to add a configure option to qsampler so that
> you can specify --liblscp-dir=/tmp/mydir or something like that ?
> It's not strictly needed but would make it a bit easier to keep
> liblscp/qsampler in different dirs eg, giving the possibility to the
> user to keep multiple version and compare them against each other for
> debugging purposes etc.
>

You can use --prefix=/whatever, but for all ABI purposes at hand wouldn't
it suffice to set LD_LIBRARY_PATH to where is that your bleeding edge
liblscp.so? Incidentally this is my preferred method for debugging, YMMV.

Nevertheless, a note has been taken for that --with-liblscp=dir configure
option.

But remember that I'm just a noob and also a complete autofool moron ;)
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] Load Instrument patch (2)

[<be...@ga...>]

Hi,
yeah I tried to apply your patch to the current CVS but hunks got rejected,
I'll try again with this patch.
I did not try it yet but I took a peek at the patch and since you
don't seem to do anything particularily hackish (which could upset
 our dictator, aka cuse) :) I'd say if noone complains within 24h or so
 just go ahead and commit it.

PS: regarding qsampler, liblscp  since I want to keep /usr/local clean
I want to put qsampler and liblscp into my own dirs but the problem is
when compiling qsampler you have to hack the configure script and/or
the .pro file so that it detects the presence of liblscp and then sets 
the paths for -I and -L when compiling.
Would it be possible to add a configure option to qsampler so that
you can specify --liblscp-dir=/tmp/mydir or something like that ?
It's not strictly needed but would make it a bit easier to keep
liblscp/qsampler in different dirs eg, giving the possibility to the user
to keep multiple version and compare them against each other for debugging
purposes etc.

cheers,
Benno
http://www.linuxsampler.org


Scrive Rui Nuno Capela <rn...@rn...>:

> Hi,
> 
> Second round. In the attachment there's a cleaned up version for LOAD
> INSTRUMENT / GET CHANNEL INFO commands diff-patch, which is supposed to be
> applicable to current linuxsampler CVS HEAD (patch -p1).
> 
> If nothing stands against, I'll may commit it soon, while testing the
> latest bleeding-edge server code and updating the LSCP document-draft.
> 
> >
> > Specifically, this patch makes the LOAD INSTRUMENT command to return
> > immediately, almost/always with an "OK" response, while spawning the
> > proper instrument file loading in the background.
> >
> > The new INSTRUMENT_STATUS item from GET CHANNEL INFO inquiry command is
> > where one checks for a successfull load. The instrument status value holds
> > the load progress percentage if positive, currently only "0" and "100" ;)
> > Otherwise, in case of a load exception error, the instrument status
> > variable will hold a negative value.
> >
> > As proposed, the instrument file load is considered successful and
> > complete when and only when INSTRUMENT_STATUS holds a "100" value.
> >
> >>   If all this is OK, I can make the changes myself to the draft
> >> document. Yet again, it will bump to v.09. The summary preview of
> >> changes are:
> >>
> >>   4.4.1 LOAD INSTRUMENT slight semantics change;
> >>   4.4.9 GET CHANNEL INFO response new status field, INSTRUMENT_STATUS;
> >>   6.6 INSTRUMENT_LOADING event type simply vanishes away.
> >>
> >
> > Just hoping this patch gets tested and reviewed, and ultimately found
> > applicable, I'll start making the document changes in no time.
> >
> 
> BTW, the current CVS HEAD linuxsampler server it's pretty unstable
> nowadays, as I find it segfaulting on any ocasion I try to load an
> instrument file. These crashes are highly reproducable, whether this patch
> is applied or not. So don't start flaming about that :)
> 
> Likewise, qsampler is being always brought to the floor, being quite
> unusable at this moment with the latest server CVS. Despite server's
> crashing quite deterministicaly, these client issues are being taken care
> on the liblscp side, so soon this may improve a liltle.
> 
> Hope to hear your comments. Is everybody left on exams ? ;)
> 
> Take care.
> --
> rncbc aka Rui Nuno Capela
> rn...@rn...
> 




-------------------------------------------------
This mail sent through http://www.gardena.net

[Linuxsampler-devel] Load Instrument patch (2)

[Rui N. C. <rn...@rn...>]

Hi,

Second round. In the attachment there's a cleaned up version for LOAD
INSTRUMENT / GET CHANNEL INFO commands diff-patch, which is supposed to be
applicable to current linuxsampler CVS HEAD (patch -p1).

If nothing stands against, I'll may commit it soon, while testing the
latest bleeding-edge server code and updating the LSCP document-draft.

>
> Specifically, this patch makes the LOAD INSTRUMENT command to return
> immediately, almost/always with an "OK" response, while spawning the
> proper instrument file loading in the background.
>
> The new INSTRUMENT_STATUS item from GET CHANNEL INFO inquiry command is
> where one checks for a successfull load. The instrument status value holds
> the load progress percentage if positive, currently only "0" and "100" ;)
> Otherwise, in case of a load exception error, the instrument status
> variable will hold a negative value.
>
> As proposed, the instrument file load is considered successful and
> complete when and only when INSTRUMENT_STATUS holds a "100" value.
>
>>   If all this is OK, I can make the changes myself to the draft
>> document. Yet again, it will bump to v.09. The summary preview of
>> changes are:
>>
>>   4.4.1 LOAD INSTRUMENT slight semantics change;
>>   4.4.9 GET CHANNEL INFO response new status field, INSTRUMENT_STATUS;
>>   6.6 INSTRUMENT_LOADING event type simply vanishes away.
>>
>
> Just hoping this patch gets tested and reviewed, and ultimately found
> applicable, I'll start making the document changes in no time.
>

BTW, the current CVS HEAD linuxsampler server it's pretty unstable
nowadays, as I find it segfaulting on any ocasion I try to load an
instrument file. These crashes are highly reproducable, whether this patch
is applied or not. So don't start flaming about that :)

Likewise, qsampler is being always brought to the floor, being quite
unusable at this moment with the latest server CVS. Despite server's
crashing quite deterministicaly, these client issues are being taken care
on the liblscp side, so soon this may improve a liltle.

Hope to hear your comments. Is everybody left on exams ? ;)

Take care.
--
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] Latest CVS commit

[Vladimir S. <ha...@so...>]

Hi All,

Having some issues with the parser. Apparently if we tell it that 
something should be a string it still recognizes tokens if they appear 
in that string and produces a syntax error :)
I'm no flex/bison guru, but i think i'll have to become one soon unless 
someone wants to point out to me what we are doing wrong there . . .
Lots of things broken . . . There will probably be no progress until 
this coming weekend.

Regards,
Vladimir.


Vladimir Senkov wrote:

> Hi All,
>
> As Christian pointed out, things may be unstable for the time being.
> Indeed they are. In particular, base classes from driver direcrory are 
> calling pure virtuals implemented in a derived classes (in audiodriver 
> directory).
> I need to find an elegant way to get around this without breaking too 
> much of the beauty that Christian architected. If any of you already 
> have this fixed or are planning to jump on it please let me know to 
> avoid duplicatoin. In the mean time, i'll put that on my TODO list. I 
> should be able to get to this on the weekend.
> Nothing to worry about, just small issues here and there . . . good 
> news is that there is whole bunch of new code and functionality there. 
> I'm impressed! I think this is a giant step forward and with steps 
> like that we'll see things improve very soon.
>
> Regards,
> Vladimir.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

[Linuxsampler-devel] LSCP draft document in groff format?

[Christian S. <chr...@ep...>]

Hi!

I suggest to use another format for the network protocol document. 
Unfortunately I did not find a way to create a good plain text version with 
OO. Then it also makes sense to put the file into CVS. Should we use groff? 
That is probably the most common tool for creating RFCs under Unix. There are 
of course other tools as well, so tell what you'd prefer.

CU
Christian