large usb midi interface

[nickverlinden]

Hi Rene, for a project i need a lot of midi ports. so i'm looking at this interface. it's class compliant according to the manufacturer. Do you see any problems getting this to work with circle? Is 16 in and outputs supported over usb? Any potential issues i should be worried about?

kind regards,
Nick

https://miditech.de/en/portfolio/midiface-16x16/

[rsta2]

Nick, that's an expensive one. I wouldn't use this on a RPi 1-3. RPi 4/5 with their xHCI host should be able to handle it. But, as you know, I cannot give a warranty.

[nickverlinden]

thx Rene. No of coarse i understand, just want to check with you if there were any immediately recognisable obstacles, such as a midi port limit in the usb implementation or something. I was thinking about alternatives, maybe you have a good suggestion. bqsically i have 16 pi 4s running circle and some custom code, they can work individually with midi instruments, but i also need to be able to connect all 16 of them to a pi 4 running circle with custom code, and the 16 pi's basically need to respond to midi start/stop events (mtc or transport, to be decided), and send midi notes back to the 1 pi. I guess i could try to write some tcp socket code and connect all of them using a ethernet switch. i also thought about i2c or spi but that seems way more difficult to get working. Do you have any suggestions?

[rsta2]

There is no hard-coded channel limit in the MIDI driver. What I don't really know is, how this device handles the 16 ports, but I guess it uses the 16 virtual MIDI cables in USB MIDI and there is only one USB MIDI interface, provided by this device. This should work. But it must be MIDI 1.x not 2.0, which is not supported by Circle.

That's a huge setup. I do not really have a better solution for this. With TCP you can get jitter, because QoS is not implemented. I think I2C is not well suited for this purpose. Remains SPI. You could build a SPI token ring, which is operated on a secondary core of the RPi 4's, but it is probably not easy to get this running.

[nickverlinden]

thank you for this advice. I think i'm going to try TCP, implementation looks reasonably simple and i'm not too worried about jitter. the timing doesnt need to be as accurate as an atomic clock. I just hope the jitter will not exceed like 20ms or something.