Not got a test rig for it yet.
The only rtpmidi attempt I’ve made is to turn off the qmidinet, network that has run successfully. ( I play on the Motor 61 on MIDI 3 I get Bells on the zynth attached to the HifBerry 25 watt amp with a couple of JBL control ones. A very light rig.)
I turned on rtp-midi and expected to get a similar result but nothing as yet.
I’ve also downloaded touchdaws onto an Android tablet and tried to see if I could allocate some controllers but didnt get too much of that together either, so not seen it work yet.
It should just build a local zynthian MIDI net shouldn’t it?
Not been following the debate too closely, in truth, so was working from assume functionality,
I presume a synth should make a useful RTP-MIDI source ( my A-88 master keyboard) for other devices on the network or am I completely misunderstanding
From a purely zynthian perspective we should have one conceptual model of what we expect to happen. The qmidinet pool of 16 MIDI channels working as all can write and all can listen works well. Jofo out simpled me way back in this, and it’s a very good concept.
IF the rtp-MIDI network can provide a similar simplicity of network then it’s really easy whenever zynth’s get together to handle stuff like remote patching in a simple way. The actual transport mechanism (qmidi/rtp) shouldn’t matter.
If the rtp-midi space has extra goodies then so much the better.
Well, Output used to work, but now it doesn’t. I know in the midi ports setup Qmidinet shows up but not RTP-Midi. Perhaps some recent change stopped sending midi through net_out?
We really need more port routing options as well as having USB devices have their own set of channels. I have some identical midi controllers this would be usefull.
Basically I was using it to remotely connect multiple midi controllers over the net to my windows machine. So Zynthian was just passing the midi through. Also, my Casio CDP-220’s windows USB drivers are crap and sometimes lock up so this is a way around that. Lockups in VR Really suck!
And for VR, I added support for midi to High Fidelity so I could use my controllers in VR. Really surprised a friend of mine who had the same keyboard when I started playing it remotely… High Fidelity recently went closed source so a group of us users forked it .https://projectathena.io/ I have made a Virtual Keyboard, Also a Ground piano you can walk on with foot trackers. Also scripts that use MIDI to trigger events etc. I use my Novation Launch ControlXLs For controlling lights and particle effects and Avatar Morphing. I’m thinking of making a Quaternion Vector Synth to control 7 midi channels volumes to see what can be done… Heck with 2 controllers it could be 14…
I just checked and i can’t see anything bad from the zynthian POW, Jack MIDI ports and routing are OK.
Anyway, recently there was a change that could have affected: the jackrtpmidid binary that existed in the repo was deleted by @BEB and i changed the build script so it’s compiled from source code. Compilation is perfectly clean (no warnings) and the code has not been changed, but who knows? Perhaps @BEB could give some tip about this?
if I understand well your problem, the latest version is not anymore sending anything to the network ?
If so, could you make a screenshot of the JACK routing configuration? First thing to check is that rtpmidid input is connected to something from the router
And what do you mean by “RTP-MIDI does not show up in the MIDI port setup”? You mean in the admin panel ?
@wyleu You have to think about the latency. Light via fiber has a speed of round about 100.000 km/s. With 20ms latency you get a range of 2000km… without any latency added by any internet routing Equipment.
It’s actually pitched as a use case in the rfc, Maybe not so much as viable performance option but it wouldn’t half prove the technology ! and I’ve got a few zynths here that could be molested and a router with port forwarding.
Hi C0d3man,
main problem is not the velocity of the light or electromagnetic signals, but the processing time of all routers that will be encountered on the path between the two machines.
We have done tests in the past for some customers at KissBox to pass through Internet (I remember especially one who wanted to control a pipe organ from a remote location, around 20 kms if I remember well).
Technicallly, the setup was working, but the latency was a true pain. The fun thing was that latency was not so different between short distances like 20 kms and across ocean (I made a test between our office in USA and my home in France).
And there is also another factor which kills such setups : the latency jitter
There are ways to get rid of fixed latency (as long as you don’t expect to play in realtime ) but in most case the latency changes depending on the routers load…
But Wyleu is right, MIDI control over WAN is one of the use cases described in RFC6295
High Fidelity recently went closed source so a group of us users forked it .
) but in most case the latency changes depending on the routers load…