11 Sep
2018
11 Sep
'18
4:50 p.m.
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 jeb(a)ponderworthy.com (785)233-9977
Hear us at ponderworthy.com -- CDs and MP3 available!
Music of compassion; fire, and life!!!
11 Sep
11 Sep
5:50 p.m.
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
9:13 p.m.
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
9:19 p.m.
New subject: ?==?utf-8?q? further in on midi2udp/tcp
Am Dienstag, 11. September 2018 19:13 CEST, Len Ovens <len(a)ovenwerks.net> schrieb:
On Tue, 11 Sep 2018, Jonathan E. Brickman wrote:
That's C-code, iirc. The problem with python: the interpreter has a global lock (the
infamous GIL). So, unless you write your jack callback in C/C++ your code might block.
Cheers, RalfD
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(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
2063
days inactive
2063
days old
linux-audio-dev@lists.linuxaudio.org
3 comments
4 participants
participants (4)
-
Christopher Arndt -
Jonathan E. Brickman -
Len Ovens -
Ralf Mattes