Melodyne STILL crashing Cubase 8.0.10 on Mac

So I looked at the “issue” forum, and I see that it is listed as a “known” issue, but the thread is locked. So, I wanted to say that it is STILL not fixed as of 8.0.10 on OS X 10.10.2 When removing/using Melodyne it crashes Cubase. I have reported this to Sternberg, but obviously it is doing no good as the issue has been hanging around since version 7 apparently. YIKES! C’mon Steinberg…

Process:               Cubase 8 [2249]
Path:                  /Applications/Cubase 8.app/Contents/MacOS/Cubase 8
Identifier:            com.steinberg.cubase8
Version:               8.0.10.427 (8.0.10.427)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           Cubase 8 [2249]
User ID:               501

Date/Time:             2015-03-27 14:41:05.205 -0500
OS Version:            Mac OS X 10.10.2 (14C1514)
Report Version:        11
Anonymous UUID:        EF559458-3854-51DB-BD6B-6C308464F198


Time Awake Since Boot: 100000 seconds

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x000000012eff07d0

VM Regions Near 0x12eff07d0:
    Stack                  000000012ddaf000-000000012ddb1000 [    8K] rw-/rwx SM=PRV  
--> 
    STACK GUARD            000000012ffc1000-000000012ffc2000 [    4K] ---/rwx SM=NUL  stack guard for thread 48

Application Specific Information:
objc_msgSend() selector name: setNextKeyView:


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib               	0x00007fff967fb0dd objc_msgSend + 29
1   com.apple.AppKit              	0x00007fff8a0d27ac -[NSView _removeFromKeyViewLoop] + 198
2   com.apple.AppKit              	0x00007fff8a0d1f36 -[NSView _finalizeWithReferenceCounting] + 806
3   com.apple.AppKit              	0x00007fff8a0d1bde -[NSView dealloc] + 151
4   libobjc.A.dylib               	0x00007fff9681b89c objc_object::sidetable_release(bool) + 236
5   libobjc.A.dylib               	0x00007fff96801e8f (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 575
6   com.apple.CoreFoundation      	0x00007fff8dded302 _CFAutoreleasePoolPop + 50
7   com.apple.Foundation          	0x00007fff93a921a3 -[NSAutoreleasePool release] + 146
8   com.steinberg.cubase8         	0x0000000105ccd0b7 0x104196000 + 28537015
9   com.steinberg.cubase8         	0x0000000105cd8597 0x104196000 + 28583319
10  com.apple.CoreFoundation      	0x00007fff8de68b64 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20
11  com.apple.CoreFoundation      	0x00007fff8de687f3 __CFRunLoopDoTimer + 1059
12  com.apple.CoreFoundation      	0x00007fff8dedbdbd __CFRunLoopDoTimers + 301
13  com.apple.CoreFoundation      	0x00007fff8de25288 __CFRunLoopRun + 2024
14  com.apple.CoreFoundation      	0x00007fff8de24858 CFRunLoopRunSpecific + 296
15  com.apple.HIToolbox           	0x00007fff8ac0daef RunCurrentEventLoopInMode + 235
16  com.apple.HIToolbox           	0x00007fff8ac0d86a ReceiveNextEventCommon + 431
17  com.apple.HIToolbox           	0x00007fff8ac0d6ab _BlockUntilNextEventMatchingListInModeWithFilter + 71
18  com.apple.AppKit              	0x00007fff8a08cf81 _DPSNextEvent + 964
19  com.apple.AppKit              	0x00007fff8a08c730 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 194
20  com.apple.AppKit              	0x00007fff8a080593 -[NSApplication run] + 594
21  com.steinberg.cubase8         	0x0000000105cd8ae0 0x104196000 + 28584672
22  com.steinberg.cubase8         	0x0000000105a8a8dd 0x104196000 + 26167517
23  com.steinberg.cubase8         	0x000000010501c536 0x104196000 + 15230262
24  com.steinberg.cubase8         	0x0000000104198a48 0x104196000 + 10824
25  com.steinberg.cubase8         	0x0000000104198294 0x104196000 + 8852

Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0   libsystem_kernel.dylib        	0x00007fff87925232 kevent64 + 10
1   libdispatch.dylib             	0x00007fff8abb8a6a _dispatch_mgr_thread + 52

Thread 2:: CRASH THREAD
0   libsystem_kernel.dylib        	0x00007fff8791f532 semaphore_timedwait_trap + 10
1   com.steinberg.cubase8         	0x0000000105da19fe 0x104196000 + 29407742
2   com.steinberg.cubase8         	0x0000000105da244d 0x104196000 + 29410381
3   com.steinberg.cubase8         	0x0000000104a5b40f 0x104196000 + 9196559
4   com.steinberg.cubase8         	0x0000000105da161f 0x104196000 + 29406751
5   libsystem_pthread.dylib       	0x00007fff8ba84268 _pthread_body + 131

Celemony knows about this and is investigating. Their suggestion was to disable the plugin for now.

Just throwing this out there -

As a possible interim workaround, have you tried using JBridgeM? It’s a 3rd-party plugin bridge that functions transparently (so projects load/save identically with or without - you can “wrap” and unwrap plugins any time.)

I’ve noticed using JBridge on occasion has introduced a layer of protection between Cubase and some crashing/dodgy plugins. It may work for you if you really need to use Melodyne, but I have not tried it specifically.

Found this topic while looking at my crash problem on the PC (Cubase 8.30 64 bit, Win7, Melodyne licensed by ILok)

What seems to have helped is:

  • Uninstalling all instances of Melodyne. When I looked in the control panel under Programs and Features, it showed 3 different installations. I got rid of them all.

Did a file search on the drive where Melodyne was installed for “melodyne”. In my case, there was a stray license file, and a few old directories. Got rid of them.

Reinstalled only VST3 64 bit and Rewire versions.

BTW, Melodyne recommends a buffer size of 1024…

As I said, so far, so good.

Celemony knows about this and is investigating. Their suggestion was to disable the plugin for now.

Ha. This reply was posted in March 2015. The problem predates that reply as far back as three and a half years ago…and that was when C6.5 was current. The problem continued through C7.0, C7.5, 8.0 and currently C8.5. I wrote to Celemony about this issue around June of 2012 and received roughly the same arrogant boiler-plate reply after they they couldn’t figure out a way to solve the problem.

This is not a Steinberg issue. It is clearly a Celemony issue. Think about it. Like many of you, I have hundreds of plugins…some of which are still 32 bit and they all can be deactivated without crashing Cubase. Melodyne is the only plugin I have ever run across that crashes Cubase if you try to remove it. And to add insult to injury, attempts to remove it from a saved Project you’ve activated it on is almost impossible to do without completely rebuilding it, even after the plugin has been disabled/removed from the system. I have done this little exercise and it is a time consuming nightmare. The plugin acts like a friggin’ virus.

The only suggestion I can make is to send trouble tickets to Celemony on a regular basis until they stop drinking the Cool-Aid on the issue and do something about it. Yes, it’s great tool, but it is severely broken as far as standard VST3 plugin management in Cubase is concerned.

The fact that this plugin has other issues (a quick Google search will verify this) and not been updated since 2012 speaks volumes.

One other possibility… is your copy of melodyne registered on an iLok? originally i had my licence on iLok and had no end of problems from crashing to the plugin showing as being unregistered… asked celemony to rescind the iLok and move over to their own licence manager and all has been good since…

Melodyne may be a great tool but I’ve stopped using it because of these crashes - and I will never buy another of their products again - this issue lingering on for years is not acceptable - it’s not much fun burning 200+ quid on something that just does not work - going to standalone melodyne is not an answer - that destroys my workflow. Mine is authorised via a serial number - not ilok - so it’s not related to ilok.

One other possibility… is your copy of melodyne registered on an iLok?

Nope. Never licensed it to the iLok. Uses the serial number scheme they provide.

When you say “all has been good since” I have to ask this: when you last removed a Melodyne plugin from a Track’s Insert point (and it didn’t crash) was there a second or more) instance of the Melodyne plugin sitting on another track or tracks?

It has been reported that Melodyne won’t crash, if it is removed, as long as there is at least one other instance of the plugin’s presence inserted into the Project. Bottom line is, once you get down to the last instance and remove it, that action will crash Cubase. Would this be true, in your case?

No, all has been good since I moved over from iLok regardless of how many instances. I tweaked a vocal with it yesterday so that would have been the only instance used in that particular project.

No, all has been good since I moved over from iLok regardless of how many instances. I tweaked a vocal with it yesterday so that would have been the only instance used in that particular project.

I think you may have misunderstood what I wrote.

If more that one instance of Melodyne is present in a Project, Cubase will not crash if one is completely dismissed from its Track’s Insert point. It is when you remove the very last instance that the crash will happen.

When you finished tweaking the vocal, did you bounce or export the track and then remove Melodyne completely from the Project without a crash? If so, I’m beginning to suspect that this iLok/SN variation may be a Mac-only issue.

Yes that’s exactly what I meant…