Serial Midi In double triggering notes

[miotislucifugis]

Just discovering that with the last few builds (from today) midi In via Serial is causing a double trigger of notes... both on Note On (when key is pressed) and Note off (key is released)... eventually this causes the pi/ minidexed to stop responding altogether.
Perhaps this may be why Ive been having difficulty sending sysex parameter changes.

I just installed an older version of MiniDexed (before sysex stuff was added) and it behaves normally

The problem is only with Serial Midi In. usb Midi works fine

[probonopd]

Thanks for reporting this @miotislucifugis. Does this one work?
MiniDexed_2022-05-05-76620d1

It is the build from 76620d1.

If yes, does MiniDexed_2022-05-09-3894cb3? MiniDexed_2022-05-11-b6df892? MiniDexed_2022-05-11-6d14da8?

[miotislucifugis]

Sure thing!

MiniDexed_2022-05-05-76620d1 - yes working

MiniDexed_2022-05-09-3894cb3
no

MiniDexed_2022-05-11-b6df892
no
I didnt bother trying the last one

[probonopd]

Looks like it might have to do with #195 then?

cc @dcoredump

[dcoredump]

Looks like it might have to do with #195 then?

cc @dcoredump

Umpf... Have to take a deeper look at this. I hope my scope is arriving today, so I can fix my MiniDexed. After Superbooth I will have some more time for this and fix it - sorry for delay!

(BTW: Delay -> I started the framework for a delay class... comming after the fixes)

[diyelectromusic]

I'm not entirely sure, but I notice that m_SerialMIDI.Process() is called twice from CMiniDexed.Process()?

And there might also be something odd in the RunningStatus handling in CSerialMIDIDevice.Process as a consequence of the SysEx additions. m_nSerialState/case 4 has lost it's else statement that reset MIDI handling in the case of receiving a CMD message (it has moved to cases 1,2 which are already processing data bytes...)... but this might be a "red herring" as I'm getting a little lost following the two goto statement's logic...

[dcoredump]

I'm not entirely sure, but I notice that m_SerialMIDI.Process() is called twice from CMiniDexed.Process()?

And there might also be something odd in the RunningStatus handling in CSerialMIDIDevice.Process as a consequence of the SysEx additions. m_nSerialState/case 4 has lost it's else statement that reset MIDI handling in the case of receiving a CMD message (it has moved to cases 1,2 which are already processing data bytes...)... but this might be a "red herring" as I'm getting a little lost following the two goto statement's logic...

Yes, you are totaly right! Thanks for reporting. Will fix this in an hour or two.

I think this happend due to my excessive debugging when implementing SYSEX until I found that the problems was my MIDI input circuit...

[probonopd]

Thanks @dcoredump