Re: [Linuxsampler-devel] Sampler engine / GUI communication

[Steve H. <S.W...@ec...>]

On Wed, Nov 06, 2002 at 02:08:07PM +0100, Benno Senoner wrote:
> Regarding the sampler->GUI protocol I think is is wise to use a
> TCP socket for this since
> it saves you from the hassles of handling lost packets and since on a
> LAN TCP transmission errors
>  show up very rarely, I think the speed that can be achieved (for
> GUI purposes) is more than
> adequate and most of times the round-trip latency will be below 1msec.

I agree. I also dont think it is neccesary or desirable to define the
on-the-wire protocl to the action level. Some sampler engines will have
things we havn't though of, some will implement things in incompatoible
ways. I think its enough to say, it will be TCP (or UDP) and maybe define
a service discovery mechanism.

Re. the IP MIDI thing, whats wrong with the RTP MIDI standard, that's
currently in the pre-RFC stage? RTP seems more sensible that multitransmit
UPD to me.

> Regarding using CV I am not 100% sure about that, sure it simplifies
> things a bit but I think
> that in some cases we loose efficiency and flexibility.

How so? We would gain flexibility, and the efficiency issue is not that
simple.

Using event based systems its very hard to express arbitrary modulations.
NB I'm only advocating CV for the processing part of the signal path, the
sample based signal generation, obviously needs to be event based.

I seriously doubt there are any sample engines out there that are event
based internally (for the post processing part), it would make your life
very hard.

In any case, if we use sub engines for each sample format, its up to each
sub engine how its implemented internally.

- Steve