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

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

Es geschah am Mittwoch, 31. Dezember 2003 13:19 als Rui Nuno Capela schrieb:
> 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>

Yes, that would be acceptable, at least from my side.


Es geschah am Mittwoch, 31. Dezember 2003 12:22 als be...@ga... schrieb:
> As said ASCII is elegant etc but does it pay off to waste
> network and cpu resources (and programming resources because ASCII requires
>  parsers) ?

The command grammar defined in the initial draft is so far simply of Chomsky 
type 3, means it can simply be resolved from left to right. That's really, 
really simple and the parser would thus be very simple to implement and 
efficient. Ok, not as efficient as a binary protocol solution of course.

> For example client B could change parameters in linux sampler eg,
>  reverb amounts, FX send levels continuously while client A (a GUI)
>  display the faders which should be moving constantly.
> With ASCII we send a lot of data around need to parse it in to LS engine
> and then parse back in client A etc.
>
> I'd like to hear your opinions about ASCII vs binary from you guys.

I definitely vote at least for ASCII commands. I want to be able to even 
telnet the LinuxSampler box in case. But we could add commands where 
LinuxSampler will response with a binary answer if the frontend prefers this, 
e.g.:

	GET CHANNEL BUFFER FILL_STATE_BINARY

so the client doesn't has to parse a response ASCII string and will just get 
(as you suggested) a binary array representation.

Regarding the events e.g. for sliders. this is not that stressful. In case 
e.g. a effect setting has been changed by a MIDI slider for example, the 
engine will just send a small UDP event packet and we could even add the new 
value with this event packet:

	CHANGE CHANNEL EFFECT_DEPTH <sampler-channel> <new-value>

The client doesn't have to send a command to get this information it will 
automatically be informed by the engine and on the other side, LinuxSampler 
doesn't have to parse such a "request-for-update" ASCII command.

Again, we can go a parallel way (ASCII an binary), but at least I also like to 
be able to send plain ASCII commands.

Other opinions?

CU
Christian