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)