Menu
▾
▴
linuxsampler-devel
|
From: Vladimir S. <ha...@so...> - 2004-06-17 05:11:37
|
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 |
|
From: Simon J. <sje...@bl...> - 2004-06-18 20:37:25
|
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)
|
|
From: Vladimir S. <ha...@so...> - 2004-06-18 21:35:41
|
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
|
|
From: Vladimir S. <ha...@so...> - 2004-06-19 04:02:00
|
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. |
|
From: Simon J. <sje...@bl...> - 2004-06-19 10:07:10
|
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) |
|
From: Vladimir S. <ha...@so...> - 2004-06-19 18:48:13
|
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) |
|
From: Simon J. <sje...@bl...> - 2004-06-19 21:12:35
|
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)
|
|
From: Vladimir S. <ha...@so...> - 2004-06-20 16:22:54
|
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
>
>
|
|
From: Rui N. C. <rn...@rn...> - 2004-06-23 19:15:12
|
Hi all,
I've just committed my latest patch:
linuxsampler 0.2.x:
* SET CHANNEL AUDIO_OUTPUT_TYPE <chan> <driver> command is back!
creates an audio output device instance of the given driver type
('Jack' or 'Alsa') with default parameters if none exists,
otherwise it just picks the first available device and assign
it to the intended sampler channel.
* The AudioOutputDevice class get's a new pure virtual method,
Driver(), which is implemented on both of the existing inherited
classes, AudioOutputDeviceAlsa and AudioOutputDeviceJack, with
the sole purpose to return the driver type name as a String
('Alsa' and 'Jack', respectively).
* The quoting on the filename argument for the LOAD INSTRUMENT
command has been made optional; you can have both ways, with
single quotes or none, keeping compability with older LSCP
specification.
* An additional sanity check is made on LOAD INSTRUMENT, whether
the sampler channel has an audio output device assigned, thus
preventing the server from crashing on instrument file load.
* The GET AUDIO_OUTPUT_DEVICE INFO now includes the missing
'driver' item, as predicted by the draft protocol document.
The draft-protocol document bumped to v.11, and is already uploaded and
available on the linuxsampler.org website.
Enjoy.
--
rncbc aka Rui Nuno Capela
rn...@rn...
|
|
From: Rui N. C. <rn...@rn...> - 2004-06-24 18:56:36
|
Hi everyone, It's getting hot, qsampler 0.0.2.92: * Mon-modal intrument file loading and status experimental support. liblscp 0.1.9.101: * Major change to client event protocol interface on attempt to comply with latest draft-protocol v.11. * New function entries added: lscp_load_instrument_non_modal(), lscp_set_channel_audio_device() and lscp_set_channel_midi_device(). Please note that you *must* checkout and install this latest liblscp before you can build and run the corresponding qsampler installment. Previous qsampler releases are still OK. Hopefully ;) Bye. -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Mark K. <mk...@co...> - 2004-06-24 20:33:07
|
Rui Nuno Capela wrote: > Hi everyone, > > It's getting hot, > > > qsampler 0.0.2.92: > > * Mon-modal intrument file loading and status experimental support. > > > liblscp 0.1.9.101: > > * Major change to client event protocol interface on attempt > to comply with latest draft-protocol v.11. > > * New function entries added: lscp_load_instrument_non_modal(), > lscp_set_channel_audio_device() and lscp_set_channel_midi_device(). > > > Please note that you *must* checkout and install this latest liblscp > before you can build and run the corresponding qsampler installment. > > Previous qsampler releases are still OK. Hopefully ;) > > Bye. Cool. Thanks. A small bug report from the previous version from your page. On my system if I don't have the Jack server running but within QSampler I ask for Jack support, when I say apply QS completely goes away. I'm sure I shouldn't ask for Jack when Jack isn't running, but it would be nice if the whole app didn't disappear. I'm running QJC and Rosegarden when this happens in case it's not immediately duplicatable. cheers, Mark |
|
From: Rui N. C. <rn...@rn...> - 2004-06-26 17:47:28
|
Oops, qsampler 0.0.2.94: * Save session filename quotes missing on LOAD INSTRUMENT NON_MODAL. Enjoy, -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Rui N. C. <rn...@rn...> - 2004-06-29 21:19:28
|
As predicted for today, linuxsampler 0.2.x: * Unconsolidaded MIDI input related channel commands are back: SET CHANNEL MIDI_INPUT_DEVICE <chan> <midi-device> SET CHANNEL MIDI_INPUT_PORT <chan> <midi-port> SET CHANNEL MIDI_INPUT_CHANNEL <chan> <midi-chan> * Still useful for compability with legacy clients, an almost deprecated command gets re-implemented: SET CHANNEL MIDI_INPUT_TYPE <chan> <midi-driver> * Optional parameter list on MIDI input device creation fixed, but not quite fully effective yet: CREATE MIDI_INPUT_DEVICE <midi-driver> [<key>=<val>...] As is getting usual, my efforts are mainly in maintaining good ol'compability with existing client legacy interfaces. If the name of qsampler is coming to your mind, you're a genius ;) Bye. -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Mark K. <mk...@co...> - 2004-06-29 21:41:47
|
Rui Nuno Capela wrote: > As predicted for today, > > linuxsampler 0.2.x: > > * Unconsolidaded MIDI input related channel commands are back: > SET CHANNEL MIDI_INPUT_DEVICE <chan> <midi-device> > SET CHANNEL MIDI_INPUT_PORT <chan> <midi-port> > SET CHANNEL MIDI_INPUT_CHANNEL <chan> <midi-chan> > > * Still useful for compability with legacy clients, an almost > deprecated command gets re-implemented: > SET CHANNEL MIDI_INPUT_TYPE <chan> <midi-driver> > > * Optional parameter list on MIDI input device creation fixed, > but not quite fully effective yet: > CREATE MIDI_INPUT_DEVICE <midi-driver> [<key>=<val>...] > > As is getting usual, my efforts are mainly in maintaining good > ol'compability with existing client legacy interfaces. If the name of > qsampler is coming to your mind, you're a genius ;) > > Bye. Thanks! (And good luck to Portugal in the next round!) - Mark |
|
From: Vladimir S. <ha...@so...> - 2004-06-30 03:36:02
|
Hi Rui, It looks like the problem you described with CREATE MIDI_INPUT DEVICE not taking any parameters is twofold. First issue is not C++, it's just that i forgot to include that syntax in lscp.y :) I can't check it in right now because i'm still cleaning up something in the same file for multiple connections . . . as soon as i'm done with that i'll check this fix in. Maybe even tonight. But . . . that would be too easy :) I've also found something about parameters that i dislike. It's generic issue with all parameters, not midi related. Basically, they have parameterized and a default constructor that calls InitDefault to set the value. It is expected that the underlying things will be done to match the default setting of a parameter. for example, when you create MIDI_INPUT_DEVICE parameter active is defaulted to true. InitDefault() will set the parameter value and Sampler.cpp will then make the device to listen, so it matches the default. Problem is, if i create MIDI_INPUT_DEVICE and specify that i want active to be false, parameter is set to false but Sampler.cpp is not going to care so it will still make the device listen. If the default were set to false and Sampler.cpp was changed not to listen, then the opposite will not work because OnSetValue() is only called when the value is changed, not when the constructor is ran. Unfortunately we've got pure virtuals and virtuals around and those make it impossible for us to do certain things in the constructor. So, for example, when MIDI_INPUT_DEVICE is created it is creating it's parameters as part of it's constructor (currently). At this time we MUST NOT call things like CreateMidiPort or what not. So we can't really set most parameters to anything other than defaults during device creation time. I'm thinking that we'll have to make changes to devicefactory so that Create calls default constructor and then calls some other method that will set the parameters _after_ the constructors are all done. I'm thinking devices will have only one constructor and after calling it factory will interate thru all parameters and set them one by one. That will make sure that OnSetValue is called and the backend stuff is in the right state. Does that sound good to everyone? If so, I'm going to think about it a little bit and rework this stuff a little bit this coming (long) weekend. Regards, Vladimir. Rui Nuno Capela wrote: >As predicted for today, > >linuxsampler 0.2.x: > >* Unconsolidaded MIDI input related channel commands are back: > SET CHANNEL MIDI_INPUT_DEVICE <chan> <midi-device> > SET CHANNEL MIDI_INPUT_PORT <chan> <midi-port> > SET CHANNEL MIDI_INPUT_CHANNEL <chan> <midi-chan> > >* Still useful for compability with legacy clients, an almost > deprecated command gets re-implemented: > SET CHANNEL MIDI_INPUT_TYPE <chan> <midi-driver> > >* Optional parameter list on MIDI input device creation fixed, > but not quite fully effective yet: > CREATE MIDI_INPUT_DEVICE <midi-driver> [<key>=<val>...] > >As is getting usual, my efforts are mainly in maintaining good >ol'compability with existing client legacy interfaces. If the name of >qsampler is coming to your mind, you're a genius ;) > >Bye. > > |
|
From: Rui N. C. <rn...@rn...> - 2004-06-30 07:48:52
|
Vladimir, > > It looks like the problem you described with CREATE MIDI_INPUT DEVICE > not taking any parameters is twofold. First issue is not C++, it's just > that i forgot to include that syntax in lscp.y :) > It /was/ twofold. The missing syntax was in deed noticed and restored. As of yesterday's, it's already commited. Now it's a purely C++ problem. > > So we can't really set most parameters to anything other than defaults > during device creation time. > Hmm. Regarding the MIDI inpuit ports parameter, I did also tried fixing the default to 1 (one) instead of 0 (zero) -- something done on MidiInputDevice::ParameterPorts::DefaultAsInt(). However, even then, the alsa_seq port don't get actually created, that is, OnSetValue() does not get ever called. Another thing, probably unrelated, is that OnSetValue() only gets called when we set the parameter value as a string, with SetValue(String val) but not with SetValue(int i). Is this intentional? > > I'm thinking that we'll have to make changes to devicefactory so that > Create calls default constructor and then calls some other method that > will set the parameters _after_ the constructors are all done. > I'm thinking devices will have only one constructor and after calling it > factory will interate thru all parameters and set them one by one. That > will make sure that OnSetValue is called and the backend stuff is in the > right state. > I'm pretty convinced it's all due to that constructor vs. virtual methods you're arguing. Go for it! :) Cheers. -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Christian S. <sch...@so...> - 2004-06-30 09:26:15
|
Es geschah am Mittwoch, 30. Juni 2004 09:48 als Rui Nuno Capela schrieb: > Another thing, probably unrelated, is that OnSetValue() only gets called > when we set the parameter value as a string, with SetValue(String val) but > not with SetValue(int i). Is this intentional? Originally, my intention was that the parser just supplies a string for a parameter value, so the parser does not have to know what type the respective parameter is (bool, int, string,...), so it would always call SetValue(String s) which has to be implemented by all Parameter classes and they implement the conversion from string to their own type (e.g string -> int) and then they call OnSetValue(<their_type> val) to let the device driver react on parameter value changes. CU Christian |
|
From: Vladimir S. <ha...@so...> - 2004-06-30 12:32:32
|
Hi Rui, Christian, >>Another thing, probably unrelated, is that OnSetValue() only gets called >>when we set the parameter value as a string, with SetValue(String val) but >>not with SetValue(int i). Is this intentional? >> >> > >Originally, my intention was that the parser just supplies a string for a >parameter value, so the parser does not have to know what type the respective >parameter is (bool, int, string,...), so it would always call >SetValue(String s) which has to be implemented by all Parameter classes and >they implement the conversion from string to their own type >(e.g string -> int) and then they call OnSetValue(<their_type> val) to let the >device driver react on parameter value changes. > > > I think that's cool. We just need a place to initialize parameters and that place should not be in the constructor. Are you OK with me putting it into the factory::create then? Regards, Vladimir. PS: Multiconnection single threaded LSCPServer seems to be working OK (for me). I'm thinking about clearning it up a bit and checking it in some time this week. While i'm at it i'll also add notification support. My current thinking is that perhaps singlethreaded way of doing things is sufficient for control. Notifications will be delivered in "real time" under control of whoever is generating them or (if required) by a separate thread that is responsible for sending notifications. Right now i'm reading a command (line) and dispatching it into the parser, then reading another one, dispatching, etc, etc. Sequentially. Chances are we are not going to be blocked on read in the middle of the command/line. I could add support for that also but that will make the code a bit less clear. |
|
From: Vladimir S. <ha...@so...> - 2004-07-03 20:53:59
|
Hi All, I've checked some stuff in a few minutes ago. Changes include: multiple connection support and event subsctiption support. I left the tokenizer/parser largely intact for now. LSCPServer remains singlethreaded and i think it will be sufficient for what we use it for. The only issue is that execution of a command could take a long time (for example, loading an instrument) but i think we have already established that the client will not like that and we will have things of that nature done in the background anyway. As far as events go i've added the infrastructure but i have not made all the changes to the code everywhere to actually start sending events (yet). I've provided a quick sample on how this could be done by sending a MISCELLANEOUS (debugging) event when a new client connection is established and when an existing connection is terminated. This is just an example for how to use those "guts" and we should be able to add actual event sending very easily. I've spent most of the energy in trying to not block any thread that is originating a notification even LSCPServer thread is busy. I've added Trylock() support to Mutex class to be able to do that. If we need to in the future we'll be able to create new event types in real time. I've left some hooks for that in case we need to do that. Please check it out and let me know where the bugs are. I haven't done much testing on it yet, but i've got a long weekend ahead so i hope i'll do some later (after i make check more stuff in). My plans for this weekend are: 1) Refactor the factories :) a little bit to avoid issues with constructors and parameters (as discussed previously) 2) Look at the audio device/audio channel stuff. (card parameters, mixing channels, etc) 3) Maybe look at converting the MacOS MIDI drivers. 4) Testing, playing with the GUI, updating the spec (if there is enough time). Let me know what you think. Plans will be altered depending on feedback received. Regards, Vladimir. |
|
From: Vladimir S. <ha...@so...> - 2004-07-06 04:03:40
|
Hi Everybody, Weekend was way too short. I've checked in some infrastructure changes. This is basically to address the issues we've discussed previously about creating devices with parameters. I've applied a bit more patterns in a few places . . . created new factory that is responsible for creating parameters. Device factory now creates parameters first and then creates a device. Once device is up and running parameters are attached to it. Device parameters are now registered (just like drivers) so that device driver doesn't need to deal with parameters at all(like supplying available parameters, parsing them on device creation, etc). It can just read them when it wants to, always assuming that they are there. So basically stuff like: CREATE MIDI_INPUT_DEVICE Alsa ports=10 works OK now. (that includes the active/inactive state too). Generally speaking, a design (especially when patterns are involved) is not created in a single step but rather gets massaged in over some time. This design is not perfect yet, but i hope it is a step in the right direction. If something doesn't make sense please drop me a line maybe i missed something or didn't think of some features that we'll need later. If you have questions on how something works don't hesitate to write also. Any feedback will be appreciated. Constructive or not :) I still haven't had any time to fix the MacOS MIDI stuff. or to do testing, or updating the spec. Hopefully next weekend. Next weekend is the last weekend for me in a while . . . after that i'll be travelling for abount a month with little or no access to the net :( Regards, Vladimir. |
|
From: Vladimir S. <ha...@so...> - 2004-07-01 02:26:45
|
Guys, Found a funny problem by typo :) GET AVAILABLE_AUDIO_OUTPUT_DRIVERS Alsa,Jack GET AUDIO_OUTPUT_DRIVER INFO Al ERR:0:There is no audio output driver 'Al'. GET AVAILABLE_AUDIO_OUTPUT_DRIVERS Al,Alsa,Jack Guess why? Basically stl map's accessor operator can't be used on a map unless we are sure that what we are looking for is already there, otherwise it will add it to the map! For example: std::map <String, int> test; test["test1"] = 1; (at this point there is one element in the map. we can iterate the map and iter->first will be "test1" and iter->second will be 1). if (test["test2"]) smth(); smth() will not execute of course. But now if we iterate thru the map we'll find that there is a SECOND entry with iter->first == "test2" and iter->second == 0. So if you don't mind i'll modify some factory code to use count() to make sure entries exist instead of using accessor operator. Regards, Vladimir. PS: Benno, did you say you were going to install some bugtracking software? |
|
From: Christian S. <chr...@ep...> - 2004-07-01 08:26:20
|
Es geschah am Donnerstag, 1. Juli 2004 04:26 als Vladimir Senkov schrieb: > Guess why? > Basically stl map's accessor operator can't be used on a map unless we > are sure that what we are looking for is already there, otherwise it > will add it to the map! Sure, you always have to use find() to check if a key exists in a STL map. > PS: Benno, did you say you were going to install some bugtracking software? AFAIK he cannot install a bugtracker on the www server. He only mentioned that mysql and php is available. Anyway, we should agree about one system before installing one. As already said; I can install a bugtracking system when my exams are over. These are the ones I would suggest: * bugzilla * mantis * gnats The advantage of gnats is AFAIK that you cannot only access it via webinterface, but also per email and AFAIK with Tcl GUI frontend and command line tools, but I have not seen it in action yet. CU Christian |
|
From: Rui N. C. <rn...@rn...> - 2004-07-02 11:25:35
Attachments:
libgig-0.7.1.patch.gz
|
Hi Christian,
While trying to use libgig to traverse the actual instrument names of a
.gig file, which will be quite handy feature for qsampler, I've made some
janitor changes mainly regarding the packaging of libgig.
For example, I've added a .spec and .pc file, for RPM generation and
pkg-config stuff respectively. I've also changed some bits and bolts on
the autocrap/libfool stuff. Nothing much, but quite enough to render some
regular RPMs (libgig and libgig-devel) for my platforms of choice (SUSE
9.1, Mdk 10.0 and FC1 PlanetCCRMA). As usual, you can check those out
from:
http://www.rncbc.org/ls
I know that some of you are Debian folks, so these changes won't affect
you much. Nevertheless I'd like for you to try this out too, at least the
tarball :)
Please note that the C++ source code wasn't touched in any way. On
attachment you may find a complete diff-patch of the proposed changes.
The bottom line goes like this: I'm proposing a version bumping to 0.7.1
and asking if it would be a Good Thing to commit all this to
cvs.linuxsampler.org, as I think it's the central repository of libgig.
Is it alright?
Hope to hear from you soon.
Bye now.
--
rncbc aka Rui Nuno Capela
rn...@rn... |
|
From: Rui N. C. <rn...@rn...> - 2004-07-02 15:33:02
|
Hi, Maybe this seems an heresy, but I've just tried to build libgig on win32. After faking some missing header files, line "unistd.h" and "stdint.h", the build goes fine and fails only on gigextract.exe due to missing dependencies like audiofile. Resulting gigdump.exe, dlsdump.exe and rifftree.exe seems to work just fine. On attachment you may find the fake headers and a Borland C++ 5 (free) makefile. Just sharing my worries :) Bye now. -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Christian S. <chr...@ep...> - 2004-07-02 15:15:38
|
Es geschah am Freitag, 2. Juli 2004 11:30 als Rui Nuno Capela schrieb: > Please note that the C++ source code wasn't touched in any way. On > attachment you may find a complete diff-patch of the proposed changes. Looks fine, except: >>diff -duPr libgig-0.7.0/libgig.spec.in libgig-0.7.1/libgig.spec.in [snip] >+Copyright: LGPL That's GPL, not LGPL at the moment. [snip] >+URL: http://www.linuxsampler.org/ That should be http://stud.fh-heilbronn.de/~cschoene/projects/libgig/ for the moment, I will move the site to http://www.linuxsampler.org/ though when I have time (in a couple of weeks). > diff -duPr libgig-0.7.0/src/Makefile.am libgig-0.7.1/src/Makefile.am > --- libgig-0.7.0/src/Makefile.am 2004-05-03 15:16:58.000000000 +0100 > +++ libgig-0.7.1/src/Makefile.am 2004-07-01 10:19:08.000000000 +0100 > @@ -1,11 +1,11 @@ > -# set the include path found by configure > -INCLUDES= $(all_includes) > - > # to prevent compile errors on some systems > AM_CXXFLAGS = -pedantic > > -pkglib_LTLIBRARIES = libgig.la > -libgig_la_SOURCES = RIFF.cpp RIFF.h DLS.cpp DLS.h gig.cpp gig.h > +libgigincludedir = $(includedir) > +libgiginclude_HEADERS = RIFF.h DLS.h gig.h > + > +lib_LTLIBRARIES = libgig.la Is there a reason to replace pkglib_LTLIBRARIES by lib_LTLIBRARIES? CU Christian |
Thanks for helping keep SourceForge clean.
X