Re: [LAD] further in on midi2udp/tcp
On Tue, 11 Sep 2018, Jonathan E. Brickman wrote: The current software thought is to have both sides have two threads: one thread running callback to JACK, the other handling UDP/TCP, the threads communicating by Python FIFO queues, the UDP/TCP thread being constrained by 31.5kHz wait-state Use jack ring buffers for thread communication. They are rt safe. I have used them with a midi to qwerty keyboard bridge. (see: http://www.ovenwerks.net/software/midikb.html ) -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] further in on midi2udp/tcp
Am 11.09.18 um 14:49 schrieb Jonathan E. Brickman: > I ran into minor difficulty getting Mido into python2, You should not use Python 2 fro new projects. Support will run out in less than two years. > and difficulty considerably beyond my knowledge getting Mido into python3, > into this up-to-date Manjaro, Like I said, mido uses python-rtmidi as the default backend. This works with Python 3.4+ (and Python 2.7). The Cython-generated C-sources distributed with python-rtmidi 1.1.0 where incompatible with Python 3.7, so if you were trying to build that version from source with Python 3.7, it would have failed. Version 1.1.1, which I released last week fixes that and installs and runs with Python 27, and 3.4 - 3.7. What problems were you having with Python 3 anyway? Let me know and I can probaly help. > tcp2midi link based on the sample code using blocking waits on both MIDI You should use a callback function for MIDI reception. The mido documentation is unfortunately not very good about showing this. IMH opinion, unless you need the choice of different backends, I don't see the need for the extra wrapper anyway and I suggest you look into using python-rtmidi directly? The repo has lots of examples on using it: https://github.com/SpotlightKid/python-rtmidi/tree/master/examples After the prototyping stage, I would consider implementing the MIDI and network handling parts in C/C++ anyway, since Python, as a a garbage-collected runtime, isn't really suited for real-time tasks. You can still write the glue code in Python. Chris ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] further in on midi2udp/tcp
I have set up and run a number of tests now. Mido under python2, uses 5-7% of two different 2.4GHz+ cores for a one-way midi2tcp --> tcp2midi link based on the sample code using blocking waits on both MIDI and TCP ports. I ran into minor difficulty getting Mido into python2, and difficulty considerably beyond my knowledge getting Mido into python3, into this up-to-date Manjaro, so my next tests were midi2udp --> udp2midi using just Python3 and libraries JACK-Client and 'socket'; this is quite promising, just 2% CPU total, and the test is a bit crude. So now I'm working on designing an algorithm which models a hardwired MIDI cable over a UDP connection. Specific goals are: - MIDI over IP. Using UDP right now, will use TCP if a reason to do so emerges. - Simplicity. I want this implementable in dedicated hardware as easily and inexpensively as possible. I want $20 boxes where I can dial the src/dest IPs using dip switches. Dreaming? Maybe... - Very well-suited for live performance. This means absolutely no MIDI event dropouts without being unaware, and using MIDI resends and reset in emergency to handle packet loss. - Solid LAN immediately. Very slightly lossy LAN/WLAN next. WAN if there is call for it. - Reliability and predictability at MIDI standard speeds -- 31.5 kHz -- not bandwidth availability. Once this works it may be doubled or quadrupled, or brought to HD-MIDI's clock once someone decides on one. The current software thought is to have both sides have two threads: one thread running callback to JACK, the other handling UDP/TCP, the threads communicating by Python FIFO queues, the UDP/TCP thread being constrained by 31.5kHz wait-state loop of some sort. Any suggestions, abridgements, et cetera? Also any thoughts on the best way to build that UDP/TCP thread wait-state loop? I'm beginning to imagine that TCP might have the advantage of being able to build up the buffering...but all of this has been fairly far from my practical programming, and I know that so many of you live here, so I thought I might ask :-) -- Jonathan E. Brickman j...@ponderworthy.com(785)233-9977 Hear us at ponderworthy.com -- CDs and MP3 available! Music of compassion; fire, and life!!! ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
