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

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

benno wrote:
> As said ASCII is elegant etc but does it pay off to waste
> network and cpu resources (and programming resources because ASCII
> requires parsers) ?
>
> I'd like to hear your opinions about ASCII vs binary from you guys.

IMO assuming the lscp service is implemented on a different thread than
the midi/audio ones, the performance penalty of ASCII vs. binary parsing
is cheap nowadays.

On the client side it is even cheaper, if the command and response strings
are reasonably and elegantly structured, as I think they're coming about.
Of course the binary would be much more CPU and network effective but
regarding general interoperability I certainly prefer the ASCII route :)

As I've said once before, I will/can try to wrap lscp by an higher-level
API which would be asynchronous and event oriented. It will be implemented
as liblscp.so (lscp would stand for LinuxSampler Control Protocol).

Christian Schoenebeck wrote:
>> 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.
>

Glad you liked :)

>
> 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
>

Same with me. Following my rationale, this later command would be better
written generically as :

    GET CHANNEL BUFFER_FILL_STATE {BYTES|PERCENTAGE|BINARY} <sampler-channel>

> 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>
>

Quite reasonable! And on my generic syntax form:

    CHANGE CHANNEL <channel-param-name> <sampler-channel>
[<channel-param-value>]

We're getting there... nirvana :)

>
> 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?

I would suggest that we first specify and implement on ASCII. If someone
would take the task, the binary dialect might be also an alternative (e.g.
via different tcp and udp ports).

Happy new year!
-- 
rncbc aka Rui Nuno Capela
rn...@rn...