midi throughput issue in Rack2 ? (was MPE)

VCV Rack
1

EDIT: seems now this issue is more with receiving a lot of midi data (quickly), MPE just happens to trigger it.

since original post, Ive not recreated the same with a midi lfo from a hardware sequencer on a single midi channel sent into vcv, so it’s related to a lot of continuous midi data coming in reasonably fast.

note: tested on macOS 11.6.1/M1

is MPE working for anyone on Rack 2?

it crashes and burns for me with the simplest of patches… (fundamental midi cv-> vco → vcv → out)

tried two different MPE controllers, same issue.

Thread 9 Crashed:: com.apple.audio.IOThread.client
0   ???                           	0x00007ffe9467a8f4 ???
1   libsystem_kernel.dylib        	0x00007fff2041b92e __pthread_kill + 10
2   libsystem_c.dylib             	0x00007fff2039f406 abort + 125
3                                 	0x000000010074b4ee fatalSignalHandler(int) + 366
4   libsystem_platform.dylib      	0x00007fff2048fd7d _sigtramp + 29
5   ???                           	000000000000000000 0 + 0
6   libsystem_c.dylib             	0x00007fff2039f406 abort + 125
7   libsystem_malloc.dylib        	0x00007fff2027f165 malloc_vreport + 548
8   libsystem_malloc.dylib        	0x00007fff202822aa malloc_report + 151
9   libRack.dylib                 	0x00000000007de380 rack::midi::InputQueue::tryPop(rack::midi::Message*, long long) + 288
10  libRack.dylib                 	0x0000000000875eaf rack::core::MIDI_CV::process(rack::engine::Module::ProcessArgs const&) + 95
11  libRack.dylib                 	0x0000000000888a5f rack::engine::Module::doProcess(rack::engine::Module::ProcessArgs const&) + 143
12  libRack.dylib                 	0x0000000000881653 rack::engine::Engine::stepBlock(int) + 1699
13  libRack.dylib                 	0x00000000007b477b rack::audio::Device::processBuffer(float const*, int, float*, int, int) + 331
14  libRack.dylib                 	0x00000000007eb10f rack::RtAudioDevice::rtAudioCallback(void*, void*, unsigned int, double, unsigned int, void*) + 159
15  libRack.dylib                 	0x0000000000cd100b RtApiCore::callbackEvent(unsigned int, AudioBufferList const*, AudioBufferList const*) + 331
16  libRack.dylib                 	0x0000000000cd03c5 callbackHandler(unsigned int, AudioTimeStamp const*, AudioBufferList const*, AudioTimeStamp const*, AudioBufferList*, AudioTimeStamp const*, void*) + 21
17  com.apple.audio.CoreAudio     	0x00007fff21cf0a8c invocation function for block in HALC_ProxyIOContext::HALC_ProxyIOContext(unsigned int, unsigned int) + 6534
18  com.apple.audio.CoreAudio     	0x00007fff21e8bb04 HALB_IOThread::Entry(void*) + 72
19  libsystem_pthread.dylib       	0x00007fff2044a8fc _pthread_start + 224
20  libsystem_pthread.dylib       	0x00007fff20446443 thread_start + 15

I emailed support 2 days ago, not heard anything back… but I guess they are (understandably) busy.

Im not sure if its MPE, since Ive had the same crash, and stack trace without MPE enabled. so Im suspicious its could just be when we have large amount of continuous midi data over multiple channels. (don’t think poly related, as I only had 4 touches enable on controllers, and tried with 4-16 poly channels)

I tried in vcvrack 1.x same patch, and didn’t appear to have same issue, so seems like its just 2.0 :frowning:

1 Like
2

Huh! My guess would be that you’re right and it’s total throughput, rather than anything MPE-specific. It would be interesting to hook up MIDI loopback to a script and just generate a whole bunch of CCs; might be able to identify where the threshold of instability is.

I’m going to try V2 MPE over the weekend on Win10 if I have time and will report back.

3

yeah, its throughput…

Ive just got vcv to crash by using a simple midi lfo from a (hardware) sequencer sending in a single cc :frowning:

(ive updated title as it doesn’t seem like its MPE related but more general)

4

Why characterize the crash, why not just ask Andrew to fix it?

5

I emailed vcv ( as pointed out in first post) and hadn’t got a reply. So I was interested if others were seeing the same thing, and if it was just MPE. It would still be useful to know if it’s a Mac only issue.

My follow up was simply because I had new information, which I duly sent to vcv via email.

The more info we can supply to developers the better, often helps reproduce or point them to the issue.
As a developer, I’ve never complained about too much information about a bug report or someone reporting via an appropriate forum :wink:

This morning I have received an email saying they will contact me if more info needed.

2 Likes