[solved/ race condition] midi link issues ?!

Testing/Troubleshooting
1

hi folks,

several midilink issues, I guess.

2 cores

4 midi port (in out for each core)

the 1st core with optocoupler, the 2nd without optocoupler

midi out from J11 of 1st Core to midi in J11 of 2nd Core

1st core midi merger forward point

2nd core midi merger endpoint

no core ID issues. correct ID (thanks to smashTV/tim), correct upload process.

in init, I put these message in order to be sure all core run:

// note on hello from core1

	MIOS_MIDI_BeginStream();

	MIOS_MIDI_TxBufferPut(0x90);

	MIOS_MIDI_TxBufferPut(0);

	MIOS_MIDI_TxBufferPut(0x7f);

	MIOS_MIDI_EndStream();

// note on hello from core2

	MIOS_MIDI_BeginStream();

	MIOS_MIDI_TxBufferPut(0x90);

	MIOS_MIDI_TxBufferPut(1);

	MIOS_MIDI_TxBufferPut(0x7f);

	MIOS_MIDI_EndStream();

midiOx with midiin cable in midi in of 1st core, midiout cable with midi out from 2nd core

no prob with MIOS_MIDI_BeginStream(); and MIOS_MIDI_EndStream(); indeed, din handled by 1st core works correctly (I have message from them through the 2nd core)

BUT

  • I only received a hello message from the 2nd when I switch on the whole beast (if I put a midi cable at the midi out of the 1st one, I have its hello message)

  • when I upload with mios studio, it works. BUT in smart mode, the 1st core doesn’t upload correctly with the cable as described before. if I move the midi in (PC) from midi out 2nd core to midi out 1st core, I can upload in smart mode the 1st core.

  • if I upload in manual mode the 1st core with cable like describe before (at the beginning), it works, and when the first core reboots, it fires the little hello midi note…

my conclusion: “some” messages don’t go from the 1st core to the 2nd, sometimes… why? How could I unstick me?

I could be happy, din, ain from the 1st core fire good messages to the 2nd… so I have the whole thing almost ok.

but I’m afraid this behaviour drives me to unstability or smthg like that.

all ideas, advices would be appreciated.

2
  • I only received a hello message from the 2nd when I switch on the whole beast (if I put a midi cable at the midi out of the 1st one, I have its hello message)

Thats a classical race condition - it’s unpredictable which core will be ready for receiving MIDI events first (e.g. it depends on the code which is executed in the Init() function).

Another issue: interrupts are not enabled during Init() - than longer it takes, than longer the core won’t be able to receive MIDI events.

Do you generate this “hello message” for debugging, or is it required for your application? In this case, there are much better methods which I could propose.

  • when I upload with mios studio, it works. BUT in smart mode, the 1st core doesn’t upload correctly with the cable as described before. if I move the midi in (PC) from midi out 2nd core to midi out 1st core, I can upload in smart mode the 1st core.

MIOS specific SysEx events generated by the first core are filtered by the second core. They are not tunneled to avoid feedback loops.

You could temporary turn your second core into a common MIDI merger (w/o endpoint enable) by using the Debug Tool which is integrated into MIOS Studio. It allows you to execute the MIOS_MIDI_MergerSet() function with WREG=1 (=MIDI merger enabled) for Device ID 01, so that MIOS specific messages of the first core are forwarded by the second core.

my conclusion: “some” messages don’t go from the 1st core to the 2nd, sometimes… why? How could I unstick me?

See answers above - both are explainable and expected.

Best Regards, Thorsten.

3

thanks a lot for your precise explanation!!

it illustrates clearly the race condition concept I thought I understood…

“hello” was for debug purpose indeed… but it wasn’t a good method ; proof: both 2 cores are ok, but only one “hello” :slight_smile:

so, I can write the protodeck is all ok!

excepted for ltc module that doesn’t work as I would like…I posted in another thread, I’ll repost inside it soon…

thanks again Thorsten, & all messages received here :slight_smile: