Thats why my thought are always going back towards a independent working midi controller.
Ok, understood.
Do you think it cold be possible to enhance latencies with a connection over the CAN bus with MBNet?
Yes, the usage of CAN would simplify the wiring, and it would allow to communicate between the cores with reduced latency. But the integration of MBNet into the application is a low-prio task for me. It will require intensive testing at my side, and currently you are the only guy who would really use this approach due to the restrictions of your DAW.
Therefore I’m thinking about a solution which already exists, and still would be sufficient for your usecase.
The “MIDIbox Link” approach was the best solution for PIC based cores, which had only 1 MIDI IN and OUT -> chaining the cores, and tunneling MIDI events from forwarding points to the endpoint was the only solution for a bidirectional communication.
LPC17 has 4 MIDI IN and OUT ports, this allows a better strategy for such a purpose, which still has acceptable latencies.
And here it is:
Under the assumption that:
-
The latency would be 1 mS per MIDI event to Core2/3/4 (*)
-
the backpath to the host would mainly transmit MIDI events generated from motorfader or button movements. Latency doesn’t really matter here, and we also don’t have to expect so much MIDI traffic. Therefore for such a path we could use a chained arrangement. In the example above I chained MIDI IN4/OUT4 of the cores (*)
-
the MBHP_MF_NG modules would have to be connected to MIDI IN2/OUT2 (not shown in this picture) via the normal MIDI interface. In theory you could connect them at TTL level as well, like the core-to-core interconnections), but the advantage of the optocouplers would be the galvanic isolation, e.g. between the PSU you are using for the motorfaders, and the LPC17 core supply which could come from the USB port. This would avoid the danger for jittering values at high resolution, and it would avoid ground loops.
-
(*) in theory we could even increase the baudrate of the MIDI3/4 interfaces, e.g. 10 times faster -> 100 uS per event… or even faster. In this case we would reach the same performance like the CAN based solution!
The attractive point on this solution is, that it doesn’t require firmware enhancements. The MBNG application already gives you all functions to realize such a routing!
Why is the midibox limited to eight displays? I would love to have a ninth
I’ve prepared MBNG for 255 LCDs - but the electrical connections will be a challenge, because you won’t be able to connect them in parallel without decoupling and “amplifying” the signals. Also the selection lines would have to be multiplexed - somehow - this will be difficult to handle.
The RAM for the LCDs is limited to 512 characters ( /edit: for CLCDs 1024 characters ), which means that 64 2x16 LCDs could be handled, or 32 2x16 LCDs, or 25 2x20 LCDs, or 12 2x40 LCDs (I don’t want to count the GLCD combinations ;-))
The LCD size configuration isn’t implemented yet - and currently it’s especially only possible to use 2 (G)LCDs with up to 64x4 characters. I will work on a more flexible configuration next year.
The electrical part will be a challenge - it will probably require dedicated solutions depending on the LCD types being used.
So: only recommended for experts who know how to develop the appr. circuits, and would directly implement & test the LCD driver by themself.
http://discourse.midibox.org/t/topic/17205
Best Regards, Thorsten.
my order on taobao is not shipped yet.
