hiyaaa
wondering if its possible to disable or block hotkey commands inside of vcv rack?? specifically i want to stop pressing “enter” to bring up the module selection screen. not trying to re-map commands or anything, just stop this one (:
Rack itself has no keymapping (or un-mapping) feature.
6 Likes
thanks so much!! this works perfectly.
1 Like
I wish I could remap this Enter Hotkey for opening the library to the Tab Key (like in touch designer). I try to keep my right hand on the mouse at all times to speed things up and that tab key is just so much more convenient to hit…
I think someone could theoretically make a module with a single trigger input that opens up the module browser when a high voltage comes in?
ENTER will do it
What does the Rack log show for the crash?
im not sure how to decipher, but heres the file: log.txt (44.1 KB)
overall its not a great solution anyways, as the tab key isnt mapped to the midi keyboard by default
Hi Reina!
The part at the end of the log is the important part where the crash is:
[5.308 fatal adapters/standalone.cpp:49 fatalSignalHandler] Fatal signal 11. Stack trace:
/Applications/VCV Rack 2 Free.app/Contents/MacOS/Rack: fatalSignalHandler(int) +0x1b
/usr/lib/system/libsystem_platform.dylib: _sigtramp +0x1d
??: ?? +0x0
/usr/lib/libc++.1.dylib: std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::__assign_external(char const*) +0x15
/Users/reina/Library/Application Support/Rack2/plugins-mac-x64/Stoermelder-P1/plugin.dylib: StoermelderPackOne::MidiKey::MidiKeyModule<16>::processKey(int, unsigned char) +0xdf
/Users/reina/Library/Application Support/Rack2/plugins-mac-x64/Stoermelder-P1/plugin.dylib: StoermelderPackOne::MidiKey::MidiKeyModule<16>::midiProcessMessage(rack::midi::Message) +0x189
/Users/reina/Library/Application Support/Rack2/plugins-mac-x64/Stoermelder-P1/plugin.dylib: StoermelderPackOne::MidiKey::MidiKeyModule<16>::process(rack::engine::Module::ProcessArgs const&) +0xc6
/Applications/VCV Rack 2 Free.app/Contents/Resources/libRack.dylib: rack::engine::Module::doProcess(rack::engine::Module::ProcessArgs const&) +0x74
/Applications/VCV Rack 2 Free.app/Contents/Resources/libRack.dylib: rack::engine::Engine::stepBlock(int) +0x534
/Applications/VCV Rack 2 Free.app/Contents/Resources/libRack.dylib: rack::audio::Device::processBuffer(float const*, int, float*, int, int) +0x11e
/Applications/VCV Rack 2 Free.app/Contents/Resources/libRack.dylib: rack::RtAudioDevice::rtAudioCallback(void*, void*, unsigned int, double, unsigned int, void*) +0x7b
/Applications/VCV Rack 2 Free.app/Contents/Resources/libRack.dylib: RtApiCore::callbackEvent(unsigned int, AudioBufferList const*, AudioBufferList const*) +0x14d
/Applications/VCV Rack 2 Free.app/Contents/Resources/libRack.dylib: callbackHandler(unsigned int, AudioTimeStamp const*, AudioBufferList const*, AudioTimeStamp const*, AudioBufferList*, AudioTimeStamp const*, void*) +0x24
/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio: HALC_ProxyIOContext::IOWorkLoop() +0x32d9
/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio: invocation function for block in HALC_ProxyIOContext::HALC_ProxyIOContext(unsigned int, unsigned int) +0x8d
/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio: HALC_IOThread::Entry(void*) +0x49
/usr/lib/system/libsystem_pthread.dylib: _pthread_start +0x73
/usr/lib/system/libsystem_pthread.dylib: thread_start +0xf
This doesn’t prove anything for sure, but the crash happened inside Stoermelder MidiKey. The crash was caused by an invalid memory access (signal 11). This could be a bug in MidiKey, or it could be memory corruption caused by another module. Those are harder to diagnose.
Maybe @stoermelder wants to take a look at this?
1 Like
Thanks for the creativity and possible solutions (if a crash can be prevented of course).
1 Like
Thank you for letting me know, I will take a look.
1 Like
the setup above functions correctly now, btw!
2 Likes