Re: [LAD] MIDI-2-TCP, TCP-2-MIDI
> > In the last day or two I have been playing with the Mido library's > documentation> examples, and just now found much more apparently > practical examples:> > > https://github.com/olemb/mido/tree/master/examples>; > including what > looks like two actual JACK<-->RTP-MIDI bridges in the 'ports' and> > 'sockets' subsections. Will be studying. Seeking much input :-) > It would be interesting to know what the throughput and latency is > with that setup. I have never thought of python as being particularly > great for real time applications. However, something that works is a > great start. The road from python to c or c++ is not too bumpy > depending on the librarys used. Agreed! Am getting there, but am running into a bobble which I am hoping you or someone else will understand :-) Have assembled the two files below, midi2tcp.py and tcp2midi.py; you may find them here. When run thus, in separate xterms: python2 tcpmidi.py localhost:0 python2 midi2tcp.py localhost:0 the second connects with the first via TCP, and they both sit quietly, waiting. In Catia, I connect RtMidiIn-Client to UM-ONE (USB MIDI interface to my keyboard), everything still sits quietly. Then I press one key on the keyboard once, and both sides report note_on and note_off over and over again, without stopping until I terminate them! Have gone over the Mido docs and sample code several times, have tried setting 'message' to None after transmit and after receive on both sides, have also recoded to use accept(), no change. Have not found a way to handle this besides terminating and restarting the TCP connection at every message. Ideas anyone? Interestingly, the frequency of the current unintended behavior is a very steady 12 messages per 1/100 of a second (1200 messages per second), so I'll think the Mido library is probably incorporating timing of some sort to semi-mimic hardware MIDI and/or prevent overuse of hardware; time will tell. -- 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
Re: [LAD] MIDI-2-TCP, TCP-2-MIDI
On Mon, 3 Sep 2018, Jonathan E. Brickman wrote: Indeed, MIDI's 31.25 kbps gives (because of its 8+2 bit protocol) a rough upper cap of 1500+ datacommands (including notes and timing blips...) per second, notes being one byte per command, one more for value. And even if we use the old (and lately often obsolete) 50% rule, that's still 750+ items per second. A note on or note off is three bytes, chanel/command, note and velocity. Running status (first byte doesn't change from event to event) allows a second note on in the same chanel to omit the first byte. This is why some controllers send note off as a note on with velocity 0. Using note on and note off means note, release, note is 9 bytes rather than 7 bytes for note on on_with_0_velocity, on. Anyway, 1k is about the highest one can expect on a per event basis. "Realtime" events are single byte and patch events are two bytes. rpn and nrpn events are a minimum of 9 - 12 bytes for the first one sent but may be a little as 3 for a next value though good practice pretty much demands sending the whole 12 bytes every time. Jack always converts incoming midi to full three byte events. I do not know if it sends using running status to hardware devices. All midi "mixing" requires converting to full events as well as queuing bytes event at a time. It would certainly be nice to blow all of those numbers away by two or three orders of magnitude! And it would be gorgeous to have MIDI data simply pervade an IP stage network, or an IP instrument network, or one multi-instrument box through localhost, or a stack-of-Raspberry-Pis network, or a creative combo. I don't like the idea of using CAT5e generally on stage, because MIDI DINs are just There are high use/cycle cat connectors and cables designed for this kind of use. Take a look at almost anyone who sells network snakes or stage boxes. Most of these cables are 100 foot cables :) but I am sure shorter cables (or longer) can be had. Yes this would mean adding the matching connectors on each of the boxes you wanted to connect. In the last day or two I have been playing with the Mido library's documentation examples, and just now found much more apparently practical examples: https://github.com/olemb/mido/tree/master/examples including what looks like two actual JACK<-->RTP-MIDI bridges in the 'ports' and 'sockets' subsections. Will be studying. Seeking much input :-) It would be interesting to know what the throughput and latency is with that setup. I have never thought of python as being particularly great for real time applications. However, something that works is a great start. The road from python to c or c++ is not too bumpy depending on the librarys used. -- 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] MIDI-2-TCP, TCP-2-MIDI
On Sun, 2018-09-02 at 07:31 +0200, Ralf Mardorf wrote: > On Wed, 29 Aug 2018 13:00:07 -0700 (PDT), Len Ovens wrote:MIDI was > designed to handle in realtime (10 events from 10 fingers) > That is incorrect, MIDI was designed for sequencer usage, too, so > MIDIprovides 16 channels ;). While I only can play 6 channels in > real-timeusing my guitar synth, even my C64 and Atari ST could play > 16 channelsand more (btw. with way less MIDI jitter than any Linux PC > can do). Indeed, MIDI's 31.25 kbps gives (because of its 8+2 bit protocol) a rough upper cap of 1500+ datacommands (including notes and timing blips...) per second, notes being one byte per command, one more for value. And even if we use the old (and lately often obsolete) 50% rule, that's still 750+ items per second. It would certainly be nice to blow all of those numbers away by two or three orders of magnitude! And it would be gorgeous to have MIDI data simply pervade an IP stage network, or an IP instrument network, or one multi-instrument box through localhost, or a stack-of-Raspberry-Pis network, or a creative combo. I don't like the idea of using CAT5e generally on stage, because MIDI DINs are just so much more durable, but of course CAT5e cables are inexpensive, and if the journaling works, we could use CAT5e simply as a fallback where wifi, lifi, or xifi [not sure IP-over-xray will happen :] is not practical. In the last day or two I have been playing with the Mido library's documentation examples, and just now found much more apparently practical examples: https://github.com/olemb/mido/tree/master/examples including what looks like two actual JACK<-->RTP-MIDI bridges in the 'ports' and 'sockets' subsections. Will be studying. Seeking much input :-) -- 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
