rtpmidid VS PJON

rtpmidid[1]. After getting some hardware synthesizers and wanting to connect them without using a computer.. but being able to use them too using the computer I stumbled upon with rtpmidi the protocol and it ticked all the boxes I needed. I could connect all my gear to a raspberry pi, use ALSA sequencer to connect devices to each other with another of my programs AseqRC[2], and then use my synths from my DAW without touching any cable.

So after a fast prototype I created rtpmidid and I'm quite happy on how it works.

And it also helps with the USB ground loop noise that it seems unavoidable some times.

For some time I had even two Orange Pis connected to two sections of my gear, using USB gadget support so my MPC One could speak rtpmidi. MPC One has support to connect as host to MIDI devices, but as guest (connect to the computer) only in controlled mode which is not what I needed to convert my MIDI tracks to my DAW.

[1] https://github.com/davidmoreno/rtpmidid

My hope is that they finish the MIDI 2.0 rtpmidi protocol, and that starts to be truly used in real hardware, not half used as current rtpmidi.

This would allow easy connectivity with very low latency over normal LAN, including switches, power over Ethernet...

Disclaimer: I created a rtpmidi implementation for linux https://github.com/davidmoreno/rtpmidid

I've been using rtp-midi, using rtpmidid and it's working fine.

I'm trying to figure out how to use rtpmidid by David Moreno with my iConnectivity Mio XL. Just running rtpmidid makes all ports show up in Carla and in Reaper, but no MIDI seems to be sent. In Bitwig i can't even see the ports. Maybe because it uses jackmidi and rtpmidid uses alsamidi?

One idea I've been toying wit (but don't have the skills to implement) is a standard for hardware that's a bit more verbose than things like i2c or serial. I'd like one connector I can plug into a piece of hardware (a sensor, a servo, a keypad, etc) and have it just work. The protocol would have to be a bit more complicated, maybe something like PJON^1, and you'd need to deliver power at a few different voltages.

I've been calling it kitbash in my head, just throw a bunch of components together in various topologies and you're good to go. Considering you can get a very cheap microcontroller for something like 40 cents I can definitely see the appeal of adding a "kitbash port" to various pieces of hardware, even if it means adding a whole new microcontroller.

1: https://github.com/gioblu/PJON

When the physical layer of devices in the home don’t offer Wireless connectivity, hardware communication modules needs to be adopted to bridge the existing connectivity.

This protocol exists already is called PJON: https://github.com/gioblu/PJON

Until it ultimately relies on Amazon S3 and a commercial network provider this stuff looks rather useless. I hope IPFS will someday run on top of protocols like PJON ( https://github.com/gioblu/PJON ). Decentralization and democratization of networking will happen from the lower end, when the network infrastructure will be ours, and we will not be forced to pay multiple corporations to temporarily store our data or get it from one end to the other. We should build our own global, private network infrastructure and use it for free without the need of an ID or a contract. On top of this sort of infrastructure something like IPFS may have sense.

PJON supports mesh networking too, it is open-source and free to use, check it out: https://github.com/gioblu/PJON

its address space may be beneficial (more flexible, lower overhead) for many use cases.

Bitcoin should run over a network protocol like PJON https://github.com/gioblu/PJON and a private network infrastructure made by people.

Protocol specification: https://github.com/gioblu/PJON/blob/13.0/src/strategies/Soft...

Really cool thanks for the link. I have experimented a lot with the OOK modulation and optical communication described in the paper using just visible light LEDs as detectors and small laser diodes. A free-space optical link can be built in minutes, see https://github.com/gioblu/PJON/tree/master/src/strategies/An...

It should use PJON for communication: https://github.com/gioblu/PJON