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

[Phil K. <phi...@el...>]

Hi Benno,

100mb ethernet..... Oh that's so old fashioned, WiFi is better :)

That's the goal of DMIDI, it allows any platform to communicate with
anything.  This really would allow LinuxSampler to gain a good foothold
in non Linux studio's if it can be controlled from exiting applications
or hardware.

There's always a balance between using TCP and UDP, but there's a great
deal of overlap especially when we are talking about LAN environments.

I've been testing networks for a while and even on our POS 10mb LAN in
work I've not dropped a packet but TCP does give you an extra level of
protection. RTT's within a lan would be good enough to use TCP but IIRC
it does add a small delay (0.5 ms) 

DMIDI uses raw UDP as RTP would only tell you how late a packet is.  UDP
is also supported by a wider range of languages and hardware (important
for me)  The only time you need protection is when you try and stream
over the internet and this is where John Lazzaro has done good work.
When describing ideal DMIDI networking conditions I use the analogy of
audio cabling.  Our target audience of non-technical musicians
understand this concept well.

Double sending UDP packets works quite well and doesn't seem to add much
network overhead.  MIDI doesn't have any protection mechanism and it
works well.

It may be good if people checkout SpiralSynth and DMIDI to get a taste
of how it works:

www.dmidi.org.

Note.  I get playback delays with SpiralSynth itself of 200-400ms quite
often, test this by using a qwerty keyboard.  The plan is to add more
remote control to SSM and then update SpiralSynth later.

Cheers

Phil

On Wed, 2002-11-06 at 13:08, Benno Senoner wrote:
> (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.
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm 
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel