Hey people,
I have a keyboard that has two MIDIbox cores build in. It’s because I use one running MB_KB for highspeed-keyboard scanning and the other one running NG for the controllers. So I’d like to ask if there is a way to chain those MIDIboxes without using a MIDI OUT -> IN - chain!
Thanks,
Chris
Hi Chris,
there is no alternative solution for the physical connection, but if speed does matter: I could easily provide an option to increase the baudrate.
E.g. 10 times faster, which would mean that MIDI events are sent within 100 uS instead of 1 mS
Best Regards, Thorsten.
Hi Thorsten
Also interested with this to chain two or more core !
Side question, can we interconnect two core directly without optocoupler ?
I mean for example MO1 (PA2) from one core to MI1 (PA3) from second core ?
My use case (moving fader) will be to have up to 4 core connected to a master which can handle routing from MIDI to USB (or RTPM) to have a single USB (or ethernet) cable to run 4 MCU/HUI instance (like 4 MF_NG hooked to one core). All core running NG.
Master will certainly have dedicated event send/receive to manage slave core global data, like my conditional mute and “solo in place” function (actuating analog FET audio mute via optocoupler at DOUT)
Do you think there will be enough “power” and bandwidth to send/receive 32xPB data constantly changing ? (worst case with 32 fader always moving)
Best
Zam
38 minutes ago, Zam said:
Side question, can we interconnect two core directly without optocoupler ?
Yes, if powered from the same power supply this is no problem!
4 minutes ago, ilmenator said:
Yes, if powered from the same power supply this is no problem!
mmm… not quite sure yet for the +5, but for sure SMPS (vero trivolt) will be in the same enclosure sharing same 0V ref at chassis earth/grounding
As sense detection is at annoter PCB (the one with all Din/Dout, 3m from core 19’ rack) there is voltage change at Core PCB which can be different if different +5V rail are used depending of LED activity.
But that’s another topic 
Best
Zam
Dear TK,
yes! The only reason why I asked is the speed. I know.. 1ms is not much… but I try to save latency whereever possible. So if you could provide such a feature, that would be really great!
Thanks,
Chris
Before providing this option on a comfortable way (eg. via bootloader for all apps), it would be nice if you could configure and rebuilt the applications by yourself.
The configuration has to be done in mios32_config.h, e.g. add following #define statements to set all MIDI interfaces to 312.5k baud:
#define MIOS32\_UART0\_BAUDRATE 312500 #define MIOS32\_UART1\_BAUDRATE 312500 #define MIOS32\_UART2\_BAUDRATE 312500 #define MIOS32\_UART3\_BAUDRATE 312500
And if you have some time, it would be interesting to know at which baudrate MIDI transfers become instable.
Up to 10 MBit are supported; this won’t work through an optocoupler anymore, but should work with a direct eletrical connection.
With higher speeds the RX buffer has to be increased, otherwise we run into potential data loss issues.
By default, 64 bytes are allocated for each MIDI IN, which can bridge ca. 20 mS at normal baudrate, and ca. 2 mS at 10x faster baudrate (as proposed above) - should still be enough for a common MIOS application.
But for the case that you notice data loss, try higher values. Max. supported size is 255 bytes (and not 256 as somebody could assume)
#define MIOS32\_UART\_RX\_BUFFER\_SIZE 255
Quote
My use case (moving fader) will be to have up to 4 core connected to a master which can handle routing from MIDI to USB (or RTPM) to have a single USB (or ethernet) cable to run 4 MCU/HUI instance (like 4 MF_NG hooked to one core). All core running NG.
You’ve to try out if the higher MIDI rate improves the overall performance, and you’ve to find the sweet spot.
With higher speeds also the performance of your computer, operating system and DAW become relevant.
I’m very interested on reports before providing this as a general configuration option for “common users”.
Best Regards, Thorsten.
18 hours ago, TK. said:
Quote
My use case (moving fader) will be to have up to 4 core connected to a master which can handle routing from MIDI to USB (or RTPM) to have a single USB (or ethernet) cable to run 4 MCU/HUI instance (like 4 MF_NG hooked to one core). All core running NG.
You’ve to try out if the higher MIDI rate improves the overall performance, and you’ve to find the sweet spot.
With higher speeds also the performance of your computer, operating system and DAW become relevant.I’m very interested on reports before providing this as a general configuration option for “common users”.
Best Regards, Thorsten.
Hi TK
I only have 8 fader and one core running for the moment, hope I can build the second pack soon (need to order the revised PCB)
So unfortunately I’m not able to give any feedback now, I also need to go deeper at soft side knowledge, compiling etc …, I still not so good at this…
Best
Zam
Hey TK,
sure! I can test that! I’ll give you feedback asap.
Thanks,
Chris
Hi TK
Ok, I work some hours to build an HW config to emulate 4 MCU controler
test condition:
One “master” core (Benoit RTPM core pcb) as midi router only. IN1->USB1…IN4–>USB4 same with the other way
One core (SmashTV) emulating 4 MCU instance, one MCU at midi1, and 3 MCU XT at midi 2 3 and 4
As I have only 8 fader for now, physical 1 and 2 go to midi 1, 3 and 4 to midi 2 etc… same for all button and led with midi event.
Midi connection between core are quite direct, I remove optocoupler at input master core but use the buffer at output, for slave core it’s direct at J11.
I compile different app:
-suggested 10x speed, 312.5k - buffer 64, look to work fine
-20x speed, 625k - buffer 64, look to work fine…
-aprox 30x, 1000k - buffer 64, strange things happen, like button mixed up with midi data and fader send wrong data, CC in place of PB etc, for sure there is massive lost in the data transfer…
-same 1000k with buffer at 128, don’t seem to help
I don’t go further for now with buffer at 255 for high speed, because for now 20x work… 1ms ?
Voilà !
System is wired and up for running, so let me know if you need more experimentation at my side.
Best
Zam
Thanks for checking that! I’ll do a test with 20x speed and will check if everything works at my side! I’ll report later today.
: Thorsten wrote some posts above, that 10x speed means 1ms… so if you are at 20x it should be about 0,5ms.
BTW: this setting has just effect on the MIDI ports right? The USB-speed is not affected by that, correct? (every ms counts )
54 minutes ago, FantomXR said:
Thorsten wrote some posts above, that 10x speed means 1ms… so if you are at 20x it should be about 0,5ms.
are you sure ???
On 21/12/2016 at 8:38 PM, TK. said:
By default, 64 bytes are allocated for each MIDI IN, which can bridge ca. 20 mS at normal baudrate, and ca. 2 mS at 10x faster baudrate (as proposed above) - should still be enough for a common MIOS application.
I read 2 ms
17 minutes ago, FantomXR said:
BTW: this setting has just effect on the MIDI ports right? The USB-speed is not affected by that, correct? (every ms counts
I think it’s only UART port…
Best
Zam
On 21.12.2016 at 10:51 AM, TK. said:
E.g. 10 times faster, which would mean that MIDI events are sent within 100 uS instead of 1 mS
This is what I meant 
Alright… here is my result:
I made a direct connection between two cores like suggested. PA2 to PA3. One core runs MB_KB, the second core runs MB_NG. The connection is in one direction only: Out from KB to in of NG. No optocoupler used here.
I opened the mios32_config.h like suggested and added the lines. I compiled different versions like Zam with 312k, 625k, 1000k. Of course the applications in my test run the same baudrates.
First test was with 312.5k. Didn’t test yet under heavy circumstances. Just tested if notes come through. They do… works good for now. Than I went over to 625k. Here it stopped working. When pressing my keys, the NG receives random pitchbends and program changes. Also the console says:
[765645.838] [MIOS32\_MIDI\_Receive\_Handler] Timeout on port 0x20
Than I tried to modify both applications and add a buffer of 255. But this didn’t change anything. I didn’t test another baudrate yet because if this is not working I don’t think that higher rates will work. So for now my conclusion is: 10x speed seems to work fine. Above that it get’s unstable in my environment.
Just now, FantomXR said:
On 21/12/2016 at 10:51 AM, TK. said:
E.g. 10 times faster, which would mean that MIDI events are sent within 100 uS instead of 1 mS
This is what I meant
mmm…ok maybe this is transfer speed, without buffer consideration and MIOS data analysis ?
Your test is interesting, I think I run a way more heavy stream than you, 8 PB constantly changing, bidirectional, 4 port used, acting button and led, with sysex stream etc… and I can use trice the speed ?
What is your cable length between cores ?
Here midi In (master core) come with 1k to 3V3 pull up, and midi out (master core) is after a line buffer(74HC244) and 220R (series), ribbon about 30 cm
Best
Zam
There is only one cable that connects both cores. This goes from PA2 to PA3. It’s about 10cm. But I didn’t use a pullup. Just a straight connection. I will try with using the pullup (as the MIDI standard dictates ).
Maybe it’s a problem with combining different apps… we should check with TK.
Just now, FantomXR said:
Maybe it’s a problem with combining different apps… we should check with TK.
Yes we have a difference here, I don’t mention it but I use MB_NG (1.036) at both core.
Let’s wait advise from TK.
Best
Zam
I just noticed, that the cable that goes from PA2 to PA3 is equipped with a 220Ohm resistor. I do not use a buffer. So the only differences we have are the applications and the 1k pullup to 5V. I don’t have the tools to build this small setup here. But I’ll try to test as soon as possible.
I’m worried about keyboard scan resolution/speed for my project too.
What about adding a Doepfer MKE instead of a second core? That should work in the same way, right?
: I followed up on this today and I can confirm, that 20x speed (625k) seem to work okay. I didn’t test any other baudrates yet…