Interpreter crash when get midi message

Questions
1

When get midi message “start” “Song Position Pointer” from midiclock device
,Interpreter crash .Dose anyone have same trouble ?

Interpreter has crashed or stopped forcefully. [Exit code: -1073741819]

os:windows10
midiclock : https://www.e-rm.de/data/E-RM_midiclock_manual_EN.pdf

2

I had tried to reproduce this with a “start” message, but, no crash.

Which OS? The MIDI backend is different in all 3 supported OS types.

hjh

3

Thank you.

I use windows 10.
SC : 3.11.1

4

I can reproduce the crash in Windows. I’ll log a bug report. Edit: https://github.com/supercollider/supercollider/issues/5199

It looks to me like any of the MIDI messages “MTC quarter frame,” “song position,” “song select” cause SC in Windows to crash. If there is any way to configure the hardware module not to send these messages, you could probably work around the problem that way.

hjh

5

Oh , thank you so much.

It’s good problem reason became clear .
I hope this bug will fix.

In my case, midiclock device sends “start” and “song position” messages together and no setting to select message.

6

Another possible workaround would be to use Pure Data to filter the incoming MIDI.

I’m not on a Windows machine now, but I think it would go like this:

  1. Install loopMIDI https://www.tobias-erichsen.de/software/loopmidi.html

  2. In loopMIDI, set up one bus.

  3. In Pd > Media > MIDI settings, set the input to receive from hardware and the output to loopMIDI.

  4. In Pd, create the following patch. This will catch the MTC, song position and song select messages and direct them to… nothing, while forwarding other clock-related messages. (Though, it isn’t handling song position data bytes… probably data bytes without status bytes just get dropped… hope this works OK.)
    pd-midiclock-workaround

  5. In SC,

    MIDIClient.init;
MIDIIn.connect(0, MIDIClient.sources.detect { |src| src.device.contains("loopMIDI") }.uid);

    … and then do the rest of the MIDISyncClock startup procedure.

This should prevent the offending messages from ever reaching SC.

I don’t know if this will introduce any extra jitter or latency.

hjh

7

There is now a test build fixing this issue: http://supercollider.s3.amazonaws.com/builds/supercollider/supercollider/win64/topicWindowsMIDIRtFixes-latest.html

Unpack the ZIP and run ‘scide.exe’ from this folder. (It’s not an installer, just run from the folder.)

hjh

1 Like
8

wow,thank you!!i’ll try it!!!

9

hey, thanks i had the same issue, but its working with the test build. is this fix implemented in a future version of sc?

10

As far as I can see, this fix is included in 3.12.0 (second release candidate is available now).

hjh

11

thats great, thanks alot :slight_smile: