Sending a lot midi data OUT of rack2 seems to possibly crash Rack2!

Plugins & Modules
1

Hey :slight_smile:

I am working on a patch where I need a good deal of midi send out of VCV rack, to turn on LEDs on my Launch Key Mini.

First I thought I got it, the mechanism is working, but when I open my patches, most of the time it crashes Rack2.

I thought I’d swing it by the forum before writing support.

I get this in the log.txt file:

[1.763 fatal adapters/standalone.cpp:49 fatalSignalHandler] Fatal signal 11. Stack trace:
6: Rack(fatalSignalHandler(int)+27)
5: libsystem_platform.dylib(_sigtramp+29)
4: ???(0x0+0)
3: libRack.dylib(rack::RtMidiOutputDevice::runThread()+464)
2: libRack.dylib(void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct>>, void (rack::RtMidiOutputDevice::*)(), rack::RtMidiOutputDevice*>>(void*)+62)
1: libsystem_pthread.dylib(_pthread_start+125)
0: libsystem_pthread.dylib(thread_start+15)

I am not sure what that means, but it seems like there is some fatal errors, but not 100% sure what to make of it.

Is it because I might be overloading the Gate>Midi module?

When I disconnect the inputs for that midi module the patch loads fine, but then I don’t get the LED feedback I’d like. I am updating all 16 outputs at once, to get 2 radio buttons of 8 each.

Any tips for understanding the log.txt is appreciated!

Screenshot 2024-03-07 at 21.31.22
Screenshot 2024-03-07 at 21.31.22422×534 152 KB

2

Looks similar to a crash I found caused by a bug in Rack’s RTMIDI wrapper. I reported the bug and provided a fix, but VCV hasn’t released the fix (and I don’t know if they plan to). I posted the description of the issue and the fix a while back, but I can’t find the post.

I recommend you contact support@vcvrack.com and report your issue.

If you build Rack yourself, you could try applying my 1-line fix and see if it is the same bug. Let me know if you want to try it.

…and, please report the issue to VCV, regardless.

1 Like
3

Is this is the post with the RTMIDI wrapper bugfix that you are referring to?

1 Like
4

That’s the one!

For reference, here’s a link to the post: Save/restore of module with multiple audio interfaces on MacOS - #12 by pachde

1 Like
5

Thank you for the feedback guys!

I’ve send a report to VCV support, with description and link to this thread, hopefully they will look into it, since you also reported some issues with the RT midi wrapper.

The LED feedback is kind of important, when trying to build a more hands on setup with midi controllers and you can’t really do that, without sending lots of data. Pure Data does this pretty well.

Anyway, we will see what they say :slight_smile:

1 Like
6

BTW, is it hard to build Rack2?

I think I’d like to try, if it’s not too hard. I found the build guide here, which doesn’t look too complicated:

What do I need to do to add the possible fix?

7

It’s not that complicated. If you follow the instructions exactly. The instructions are very good.

1 Like
8

I did build back in 0.6, when I tried making my first modules, so I feel confident I’ll make it work again.

Just need to be sure what exactly I need to add for the build to try to fix the midi issue.

9

Yes, that would be the tricky part. Unless @pachde has a fork with the fix in it.

10

I gave the fix in the linked post. It’s a one-line change (two if you count fixing the indentation due to a removed if).

11

Huh I’ve occasionally ran into this recently too working on a MidiThing V2 bridge (essentially sending channels of CV using tons of pitch bend messages). @pachde / @Jaffasplaffa - keen to hear if you hear anything from VCV support.

1 Like
12

Will keep you updated :slight_smile:

13

Hey again :slight_smile:

So I’ve been in contact with support, they are asking for log and so on, which I will provide.

Meanwhile, I think I got a little bit closer to understanding the issue. It’s not actually the patches itself that’s the issue. It’s when I load patches with a complicated midi setup, right after each other. So if I have one patch with a complicated midi setup and I load another patch with a complicated midi setup, I get that error and Rack crashes.

If I have a patch with complicated midi setup and then first load an empty patch and THEN loads another patch with complicated midi setup, it works fine.

At least that’s what I experience, when I load an empty patch in between the patches that have complicated midi setups, it works.

1 Like
14

In case it’s useful, this is what I get (exact same as you):

[39.241 fatal adapters/standalone.cpp:49 fatalSignalHandler] Fatal signal 11. Stack trace:
6: Rack(fatalSignalHandler(int)+40)
5: libsystem_platform.dylib(_sigtramp+56)
4: libRack.dylib(rack::RtMidiOutputDevice::runThread()+504)
3: libRack.dylib(rack::RtMidiOutputDevice::runThread()+504)
2: libRack.dylib(void* std::__1::__thread_proxy[abi:v15006]<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct>>, void (rack::RtMidiOutputDevice::*)(), rack::RtMidiOutputDevice*>>(void*)+64)
1: libsystem_pthread.dylib(_pthread_start+136)
0: libsystem_pthread.dylib(thread_start+8)
15

Hey @hemmer :slight_smile:

Do you have any idea what causes it?

16

I’m pretty sure @pachde has an understanding of why and a fix linked above. Or if you mean how to trigger it, then just sending lots of midi and waiting a long time (it’s rare).

17

If it happens to actually be the same issue, yes. If you have a consistent repro case, and you can build Rack, you can verify if my fix works or not. Fix is given in the linked thread.

I wasn’t able to provide a consistent repro case, because my plugin requires hardware that VCV likely don’t possess.

If you can provide a consistent repro to VCV support, it’s more likely VCV will fix it.

1 Like