PRISM Rainbow - causing crash

Plugins & Modules
1

Anyone else having issues with Prism’s Rainbow?

It crashes Rack, even with an empty patch.

2

Please report the issue here: Issues · SteveRussell33/Prism · GitHub giving as much detail as possible.

Thanks.

3

Just tried loading it 15 times and nothing bad happened :man_shrugging: :man_shrugging:

4

Thanks for the issue post Peter.

I’ve had a pre-release build sitting around for a bit, could you try that one. Comment on the issue either way.

1 Like
5

I saw it when I posted the issue but as I said it’s intermittent so 2.3.3 is behaving now but I’ll install 2.3.4 and see what it does.

2.3.4 looks stable, but so did 2.3.3 after the crash.

6

I’ve made a couple more fixes, both for Rainbow and the Spectrum expander, that should add to general stability including a crash (I hope!) that I hadn’t had much luck with fixing. All seems good now. Probably going to make this a release to the library.

Thanks again for the help.

P.S. I’ve updated the builds on the release page.

1 Like
7

Oh, so i am not alone. Yesterday it crashed my VCV to the point of resetting the program (i even had to log in to my vcv account after that). Well, it’s not crashing my OS and i rarely use it anyway, so that’s fine, i guess…

8

What OS? What Prism version? Do you have a log file?

9

Windows 7 SP1. Prism, it was the latest one, not sure of the update\version number. I usually update everything as soon as vcv shows me that there are updates for my library. No log file, sorry… At least i don’t think so, I am not sure where vcv stores crash reports

11

There’s no log files there except for the changelog for vcv itself… vvvvcv That’s what i see

12

logfile is in your user folder, not the application folder

13

Oh, i see now! But it seems like it generates that every time you open VCV. No crash stuff from yesterday…

14

Thanks for the correction, my user folder is the installation folder as I like everything to be together.

15

Post the log file next time you get a crash.Thanks.

16

I had this crash just before testing but then re-opened Rack to try it again and it didn’t crash the second time, so it may be opportunistic. It seems like one time it fails and then next time it works. This pattern has repeated twice.

On Mac here. Rack 2.1.1, Prism 2.3.4

17 
[90.810 info src/app/Browser.cpp:94 chooseModel] Creating module widget Prism Rainbow
[90.827 fatal adapters/standalone.cpp:49 fatalSignalHandler] Fatal signal 11. Stack trace:
16: Rack(fatalSignalHandler(int)+27)
15: libsystem_platform.dylib(_sigtramp+29)
14: ???(0x0+0)
13: plugin.dylib(rainbow::FilterBank::process_audio_block()+808)
12: plugin.dylib(rainbow::Audio::ChannelProcess1(rainbow::IO&, rack::engine::Input&, rack::engine::Output&, rainbow::FilterBank&)+3052)
11: plugin.dylib(Rainbow::process(rack::engine::Module::ProcessArgs const&)+4672)
10: libRack.dylib(rack::engine::Module::doProcess(rack::engine::Module::ProcessArgs const&)+143)
9: libRack.dylib(rack::engine::Engine::stepBlock(int)+1699)
8: libRack.dylib(rack::audio::Device::processBuffer(float const*, int, float*, int, int)+325)
7: libRack.dylib(rack::RtAudioDevice::rtAudioCallback(void*, void*, unsigned int, double, unsigned int, void*)+143)
6: libRack.dylib(RtApiCore::callbackEvent(unsigned int, AudioBufferList const*, AudioBufferList const*)+335)
5: libRack.dylib(callbackHandler(unsigned int, AudioTimeStamp const*, AudioBufferList const*, AudioTimeStamp const*, AudioBufferList*, AudioTimeStamp const*, void*)+21)
4: CoreAudio(HALC_ProxyIOContext::IOWorkLoop()+7441)
3: CoreAudio(invocation function for block in HALC_ProxyIOContext::HALC_ProxyIOContext(unsigned int, unsigned int)+63)
2: CoreAudio(HALB_IOThread::Entry(void*)+72)
1: libsystem_pthread.dylib(_pthread_start+125)
0: libsystem_pthread.dylib(thread_start+15)
18

Are you able to test with a debug version and GDB?