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

[David O. <da...@ol...>]

On Wednesday 31 December 2003 20.49, Christian Schoenebeck wrote:
[...]
> Again, we can go a parallel way (ASCII an binary), but at least I
> also like to be able to send plain ASCII commands.

How about introducing two layers; pre and post lexer?

That is, if you want more efficient parsing, at the expense of a=20
slightly more complicated interface, use tokens and binary values=20
instead of string identifiers and decimal numbers.

We could have a per-connection switch for both directions, one switch=20
for each direction, or even per-command "signal bytes" (maybe in the=20
128..255 range) to select ASCII or binary requests and replies on a=20
per-command basis. I think the first option makes most sense (a=20
single switch per connection), but it might turn out handy to be able=20
to mix ASCII and binary commands.

The parsing of a protocol like the proposed one can be made very=20
efficient (a few levels of nested switch()es or similar tree=20
structure), so I don't think a "pure" binary protocol would be much=20
faster. It's the lexing that burns cycles, especially if there are=20
many and/or user defined "keywords" that require symbol table lookups=20
for tokenization. Decimal ASCII parsing is also pretty expensive, at=20
least on weaker CPUs with slow divisions. I haven't looked hard into=20
optimizing that kind of stuff, but I'm quite sure binary doubles and=20
even MIDI style variable length integers or similar is faster than=20
decimal ASCII.


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---