Re: [Linuxsampler-devel] LinuxSampler control protocol (initial draft)

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

Christian Schoenebeck wrote:
>
> Here is the promised initial draft for the LinuxSampler control protocol:
>
> 	http://www.linuxsampler.org/api/draft-linuxsampler-protocol-00.pdf
> 	http://www.linuxsampler.org/api/draft-linuxsampler-protocol-00.rtf
>
> I expect you to post your suggestions for improvements / corrections for
> the protocol. Sorry that I've not created a plain text version yet.
>

ACK, read and assimilated :)

My early comment would go on future extensibility. Thus the general
command syntax should be rather be a litle more consistent, e.g.

   GET ENGINE {INFO|<engine-param-name>} <engine-name>
   SET ENGINE <engine-param-name> <engine-name> <engine-param-value> ...

   GET CHANNEL {INFO|<channel-param-name>} <channel-number>
   SET CHANNEL <channel-param-name> <channel-number> <channel-param-value>
...

Some engine or channel parameters might be read-only (GET), others
read-write (GET|SET). The INFO instruction would return the CRLF separated
list of read-only parameters, either for the given ENGINE or CHANNEL
respectively.

Note that on GET CHANNEL commands the <channel-number> is specified
_before_ the <channel-param-value>, which leaves open the possibility to
an array or ordered series of parameter values (look above at the intended
ellipsis notation).

IMHO this leads to a more uniform and structured syntax that leaves open
every other parameter one will come about in a near future--quite
unavoidable isn't it? :)

Accordingly, some notification events would take some general format:

   CHANGE ENGINE {INFO|<engine-param-name>} <engine-name>
   CHANGE CHANNEL {INFO|<channel-param-name>} <channel-number>

I hope you get the picture.

That was my EUR0.02 :)

CU-l8er
-- 
rncbc aka Rui Nuno Capela
rn...@rn...