In this article you will learn about one of the best practices for software based setups: don’t mix plugin formats from the same company.
OK – before we go deep, in principle there is absolutely nothing wrong with using different plugin formats with Gig Performer or indeed with any plugin host. You can generally mix VSTs, VST3s and (on Mac) AU plugin formats and generally with no problem. So if you already have a gig file that uses multiple formats and it’s working fine, you don’t need to rush off to change it.
Too long – don’t want to read the details
We are recommending that as a best practice, if you use a particular format for a particular plugin, always use the same format when you add more copies of that same plugin (like in A), regardless of in which rackspace you are inserting them. Don’t mix plugin formats for the same plugin (like in B).
You can use the VST version of plugin A and the VST3 version of plugin B and the AU version of plugin C but if you’re inserting plugin A (say), then always insert the VST version of plugin A.
Note: if you want your gig files to be cross-platform, then avoid using AU plugins. Make to read this blog article for more information.
Tip1: if you open Gig Performer’s plugin manager, you can sort the list by format, select all the plugins using a format you don’t want and right-click on the “Enabled” column and select Disable after which point, those particular plugins will no longer be available for insertion into any rackspace.
Tip 2: You can click on the “Plugins In Use…” menu item (under the Windows main menu) to quickly see what plugins you are using in your actual gig file.
Tip 3: Plugins are technically shared libraries which means that the code for the same plugin does not have to be physically loaded multiple times. So if you always use the same format of a particular plugin, then the other format doesn’t have to be loaded, resulting in a slight reduction in loading time.
So what’s the problem?
We’re going to get a little technical here because we’re hoping this information might be useful to other customers who run into similar issues as well as to other plugin developers.
A couple of months ago, one of our customers reported a problem where Gig Performer was just crashing at random times. This had only started happening after a particular change by the customer but we’ll get back to that later.
The crashes were starting to to happen often. They happened during shows (yuk) but they also happened between shows when when the customer left the computer on with Gig Performer running. The customer reached out to us for help. The first thing thing we needed to do was determine whether the problem was due to Gig Performer or to some plugin. We’re not fans of just arbitrarily blaming other developers so this was a critical first step
Unfortunately, the crash reports were pretty useless – Gig Performer was simply terminating with no obvious reason and no indication as to what was causing the issue. There was a very strange message in the crash report, Exception: mutex lock failed: Invalid argument
but that was it.
We were just seeing information like the following:
Thread 0 Crashed:: HotFudge Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x7ff8055911f2 __pthread_kill + 10 1 libsystem_pthread.dylib 0x7ff8055c8ee6 pthread_kill + 263 2 libsystem_c.dylib 0x7ff8054efb45 abort + 123 3 libc++abi.dylib 0x7ff805583282 abort_message + 241 4 libc++abi.dylib 0x7ff8055753fb demangling_terminate_handler() + 267 5 libobjc.A.dylib 0x7ff8052497d6 _objc_terminate() + 104 6 libc++abi.dylib 0x7ff8055826db std::__terminate(void (*)()) + 6 7 libc++abi.dylib 0x7ff805585123 __cxa_rethrow + 99 8 libobjc.A.dylib 0x7ff805255914 objc_exception_rethrow + 37 9 AppKit 0x7ff808726d01 -[NSApplication run] + 659 10 GigPerformer5 0x10c2169fa 0x10baad000 + 7772666 11 dyld 0x7ff80526f41f start + 1903
However, there were two very interesting entries in this example (highlighted above). Line 8 above meant that “something” was not dealing with an error it encountered and was simply passing the problem back to the host. But line 3 above suggested that somewhere there was a message that perhaps might have contained more information. By running Gig Performer from a terminal window rather than by the usual “double-click on the icon” to run it, we were actually able to capture that message. The message was
libc++abi: terminating due to uncaught exception of type CppSQLite3Exception
Now, SQLite is a lightweight database system that can be included with an application and doesn’t require a separate server. Coupled with the “mutex lock failed” error mentioned above, we were able to guess that multiple plugins were trying to use the same database and somehow there was a problem. However, while the error messages now made sense – we knew what was going wrong – but we still didn’t know what was causing the problem. However, one of our amazing developers was able to create a special build of Gig Performer with more instrumentation. We gave that build to the customer to see if we could capture any more information. Well, sure enough, on the next crash, the customer was able to provide us with a much more useful crash report.
Thread 0 Crashed:: HotFudge Dispatch queue: com.apple.main-thread 0 Massive X 0x168e85bb5 NI_5_15_10_R1::QReadWriteLock::tryLockForWrite(int) + 21 1 Massive X 0x169706da6 NI_5_15_10_R1::QSqlDatabasePrivate::removeDatabase(NI_5_15_10_R1::QString const&) + 54 2 Massive X 0x166e0cef5 Lechtal::MX::DB::ContentDatabase::~ContentDatabase() + 69 3 Massive X 0x166dfb4d2 Lechtal::MX::DB::MasterContentManager<Lechtal::MX::DB::....... 4 Massive X 0x166dfb67e Lechtal::MX::DB::MXMasterContentManager::~MXMasterContentManager() + 14 5 libsystem_c.dylib 0x7ff81b4aaba1 __cxa_finalize_ranges + 409 6 libsystem_c.dylib 0x7ff81b4aa9bb exit + 35 7 GigPerformer5 0x10668cf22 0x105f26000 + 7761698 8 GigPerformer5 0x10668cd59 0x105f26000 + 7761241 9 libc++abi.dylib 0x7ff81b5926db std::__terminate(void (*)()) + 6 10 libc++abi.dylib 0x7ff81b592696 std::terminate() + 54 11 libsystem_c.dylib 0x7ff81b4aaba1 __cxa_finalize_ranges + 409 12 libsystem_c.dylib 0x7ff81b4aa9bb exit + 35 13 GigPerformer5 0x10668cf22 0x105f26000 + 7761698 14 GigPerformer5 0x10668cd59 0x105f26000 + 7761241 15 libc++abi.dylib 0x7ff81b5926db std::__terminate(void (*)()) + 6 16 libc++abi.dylib 0x7ff81b592696 std::terminate() + 54 17 libsystem_c.dylib 0x7ff81b4aaba1 __cxa_finalize_ranges + 409 18 libsystem_c.dylib 0x7ff81b4aa9bb exit + 35 19 libdyld.dylib 0x7ff81b5f08d3 dyld4::LibSystemHelpers::exit(int) const + 11 20 dyld 0x7ff81b27f458 start + 1960
Well, this was really interesting. The plugin that was crashing was a rather wonderful plugin from NI called Massive X. Now that reference in line 0 is a directly give away. That tryLockForWrite is a function that would use a mutex to get solo access to a shared resource and the highlighted names in lines 1 and 2 clearly referred to a database, which fits with the early reference to the SQLite error. Finally, in line 6, the shared library (that’s the plugin) was just quitting and passing the error back to Gig Performer and causing Gig Performer to just terminate as well.
At that point, using Gig Performer’s Plugins In Use feature, we got a list of every single plugin being used in every rackspace. What we saw was that the customer had both VST and VST3 versions of Massive X in different rackspaces. He was also using both VST and VST3 versions of Kontakt and FM8, e.g. twenty Kontakt VST3 plugins and three Kontakt VST plugins. At this point we got suspicious and wondered whether the different formats were trying to use the same shared database but the database content generated by one plugin format wasn’t completely compatible with the content used by the other format.
At this point we reached out to Native-Instruments and their development people were incredibly helpful (thank you Native Instruments). After seeing what was going on, they recommended that the customer change all the non-VST3 versions of Massive X to the VST3 versions. They recommended the same thing for the other NI plugins he was using.
Success
After making the recommended changes, the customer had absolutely no more issues and has been performing almost nightly on tour over the summer.
We would like to thank that particular customer for his patience. He stuck with us because he really did not want to give up using Gig Performer and just hoped that we would be able to figure out the problem. Native Instruments plugins, particularly Kontakt, are staples for many musicians (including those of us at Deskew) and so we are extremely happy that this issue has been resolved.
If you have some questions or want to share your feedback, please visit this community thread.
.
Related topics:
– How to identify what plugin crashed?
– Tips to troubleshoot your computer based setup