Re: MIDI over wifi on Linux, revisited

"Jonathan E. Brickman" <jeb@xxxxxxxxxxxxxxxx> · Mon, 4 Jan 2016 12:55:52 -0600



    I think (from what I have read of the OP setup) that
      this case has two things that call for reliablility.
      

      1) The MIDI stream is heavy. It includes the whole backing
      orchestration. The use of a panic button would be very noticable.
      (maybe more so than the hung note it was correcting)
      

      2) The person controlling the playback is playing a sax over top
      of it and therefore needs his hands to play that. That is he has
      no way of monitoring and manually correcting things.
      

      I can not see how adding OSC as yet another layer with no error
      checking or correction could be any better than ipmidi.
      

    Agreed.  A panic button, for me (a multidevice keyboardist), is
    about as useful as a power button.  If my architecture needs a panic
    button, my architecture isn't good enough for me.

    
      rtpmidi with journaling looks to be the best bet on this because
      there is no resend needed. The journaling info is sent if needed
      or not so there is much less latency required for error
      correction. Journaling does not cover all possibilities BTW, but
      it is very picky about note off events. In the case of controllers
      the last value is journaled rather than the whole string of
      values.
      

    Of all the current code bases in this thread, which are all the ones
    I have heard of thus far, indeed, rtpmidi with journaling does sound
    the best to me.  Anyone have, or know of a source of, the old
    midistream source .deb for Ubuntu?  It is reported as "no longer
    available", I wonder if there was a patent / copyright issue or
    something.

    
    But in truth, I don't want any risk of out-of-order, or missed,
    commands in the stream.  Delay is fine, only as a great indicator
    that I have to abandon wireless and use my backup wired approach. 
    If I'm spraying notes around as fast as my fingers will go on my
    88's for consecutive minutes, nothing shall be out of order, or
    something has to get switched out.

    
    Which, strangely enough, brings me right back to primordial
    methods.  After all, even audio and video streaming over a gigabit
    wired LAN depends on caching if it's going to be hifi and truly
    flawless, TCP/UDP was never designed to keep packets in original
    order.

    
    I really do wonder.  What about this for Linux-to-Linux MIDI:

    
    - Processes on each end of the link connect to their respective MIDI
    port devices via simple binary opens

    - The processes set up two TCP connections over the LAN, two
    separate TCP ports, one for each direction of data flow

    - The processes set up two Zmodem connections, small block sizes,
    one connection each direction, one per TCP port

    
    Anyone know why this should not be maximally reliable and
    low-latency too?  We don't have to worry about any of the details of
    the data being transmitted; Zmodem handles what history needs there
    are; either the wifi rig is good enough or not.  

    
    -- 

      
        Jonathan E. Brickman   jeb@xxxxxxxxxxxxxxxx   (785)233-9977

        Hear us at http://ponderworthy.com
        -- CDs and MP3 now
          available!

        Music of compassion; fire, and life!!!
      
    
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user