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

[Benno S. <be...@ga...>]

(discussion about DMIDI and GUI/Sampler communication)

Hi Phil,
I took a brief look at DMIDI and it looks interesting.
Of course it would be very handy to add DMIDI support to LinuxSampler.
Immagine several rackmount PCs running the sampler connected to a
100Mbit LAN
 which allows you to drive the sampler even via a Windows/Mac client
(Cubase,Logic) with
 with a DMIDI output driver.

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.

For real time messages like MIDI  UDP is of course much better but I'd
like it to be somewhat
"safe". (eg it is not nice to hear a group of hanging notes due to a
lost packet).

Can DMIDI currently deal with errors ? What protocol do you use ? RTP or
raw UDP ?
Not sure if the paradigm of "better late than never" fits into MIDI but
as said missing notes,
 controller msgs etc can do much more damage than late events.
So I think we need a bit of redundancy when sending MIDI events.
In the case you are using raw UDP, how about simply sending two
identical packets for each
group of events and having the host detecting and discarding the
duplicates ?
As said before a lost packet on a non-broken LAN happens very seldom
(except in extremely
 congested networks but that is not the typical case of a LAN used for
MIDI transmission).
Thus commonsense would say me that if we send two packets instead of one
the probabilty
 that both don't come through is very very low.
( in an uniform error distribution Pboth_packets_losts=Ppacket1_lost *
Ppacket2_lost)

I think this is a very interesting topic and I'd like you to share your
thoughts with us.

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.

I'm currently designing an efficient RAM sampler object that can fit
within the modular and
 recompilable sampler concept. (using time stamps for maximum precision
and efficiency).
I will post a diagram and a description in 1-2 days so that the list can
comment on and correct
 eventual design mistakes.

cheers,
Benno

--
http://linuxsampler.sourceforge.net
Building a professional grade software sampler for Linux.
Please help us designing and developing it.