Mysterious! Your video looks correct to me. I tried upgrading to ProQ 3.2.5 and nothing changed (problem persists). Loading the rack and then deactivating or deleting Kontakt also makes no difference for me. (But deleting Kontakt, saving the modified rack, then closing and reloading it does make the problem disappear—at least for now.)
I wonder whether the bug is timing-sensitive. It feels like maybe something can load in the wrong order probabilistically. If so, that makes it harder to duplicate across machines.
Is there any info I can dump while it’s in a bad state that might be useful for you?
Just chipping in to say that I had two crashes on 4174 related to disabling many busses on Kontakt simultaneously. I ended up going disabling a few at a time and and saving between to at least retain any progress being made. Reports were generated and you should have them, @brad
All the best!
I’ve just put up build 4177, which has a small fix for audio busses configuration for another issue. I highly doubt it’s the cause of this problem, but it’s definitely worth trying before digging any deeper with this.
I had a look at this and it’s actually crashing in the plugin after (not during) setting the bus/speaker arrangement. I don’t get crashes like that with Kontakt 7, so I suspect a plugin issue.
As you predicted, upgrading to 4177 unfortunately didn’t affect the issue on my end.
I’m not sure whether this will help, but I sent you a crash dump by crashing my Cantabile while the rack was in a bugged state (no left audio output).
[To induce the crash, I exploited another (unrelated) bug I know involving sys-ex binding targets. Triggering a binding whose target is “Sys-Ex / Raw Bytes” where the raw bytes contain 0xF0 crashes to desktop.]
I’ve reproduced this in Kontakt 6.6.1 and checked everything Cantabile is doing and it all looks correct. I’ve opened a ticket with NI but since this doesn’t happen in 7 I’m guessing they’re aware of it, but not fixing it in 6.0. We’ll see.
As for the access error on log.txt, I’ll take a look at it, but that can happen when the crash reporter can’t access the log file to capture it - usually because something has locked the original crashing process (I’m guessing Kontakt).
It also shows you’re running Kontakt 6, which is known to cause crashes relating to audio busses (see previous post on this topic). I’m becoming very suspicious of that plugin, and wondering if FabFilter is a casualty. If you’ve got time to experiment I’d be very interested to see if you can reproduce this if Kontakt 6 is never loaded during the session. I’ll do some more experimenting in this area too and see if I can repro it.
To test this without directly modifying the rack, I tried the following experiment: I removed Kontakt 6 from my VST3 folder to prevent Cantabile from loading it. Then I started up Cantabile, loaded the rack, and confirmed that Cantabile had not loaded Kontakt 6 (it was marked “failed” in the rack view). Then I performed the same sequence of steps as before, and got the same result (no left-audio after disabling and re-enabling the rack a few times).
Well, if it’s down to the plugin, the solution is to mollycoddle Kontakt, a few busses at a time, into the desired condition, then save as a rack for future use.
(Or update to K7 :-))
Update:
It seems that outputs can safely be enabled (so far) but watch out if you want to disable them again. Go one at a time.
I’ve tried this again here today and still can’t reproduce the issue - which is weird since we’re running the same editions of everything, I think.
Before anything further, could I get you to uninstall and reinstall the FabFilter plugins - I just want to make sure you’re definitely running the latest version.
Assuming that still gives the problem, I’d like to try replicating your setup here as exactly as I can. If you’ve got time would you mind:
Try to put together a song/rack where you can reproduce the issues, just using Omnisphere and ProQ3. Make sure the problem is reproducible from a fresh start of Cantabile with only ever loading that song/rack.
From Cantabile’s Tools menu, choose Open Settings Folder
Close Cantabile
From the folder opened in step 2, send me settings.json, log.txt, log-previous.txt, plugins.json and plugins.cache.json along with a copy of the song/rack.
From that I’ll try to establish as close setup here as I can and hope I can make the issue happen.
If I can reproduce it, then good. If I still can’t reproduce it, I might do a special build with some one-off logging. Basically, I want capture enough technical detail to either realize what’s going on or to ask FabFilter about.
In the video, I managed to see the bug on the first activation of the rack, but usually it takes multiple rounds of disabling/re-enabling the rack.
I’m on the latest version of all FabFilter plugins (I verified within Cantabile that it’s ProQ v3.2.5).
The simplest rack I can find that reliably exhibits the bug is still the Rock Organ rack I sent earlier (also included in the .zip above), but you don’t actually need Kontakt 6 even though it has a Kontakt 6 instance in it. Just remove/rename the Kontakt 6 plugin from your VST3 folder and let the Kontakt 6 instance fail to load, and you’ll have an environment just like mine in the video.
Whenever I mess with that rack in any way to make it simpler (e.g., deleting any of the plugins, routes, or bindings) the bug becomes much harder to reproduce. Maybe that’s because re-saving the rack in the newer versions of Cantabile does something to it aside from whatever changes I make to it. Or maybe if the bug is a Byzantine fault, any adjustment I make tweaks the timing to disguise it. I’m not sure.
Could I get you to double check the modified time of your ProQ plugin. Mine is showing modification date of Feb 2024. According to plugins.json yours is from Sep 22 (almost two years ago).
We’ll I’m pretty much stumped because I used your song/rack, your settings file (with some audio driver settings tweaks) and I still can’t reproduce this.
Would you mind sending me a copy of that plugin file for me to try here? (Don’t post it here, send via email or PM).
Failing that, I’ll do a build with some additional logging in it.
Ran into a problem with a particular VST3 (Audio Assault Head Crusher v2). As of build 4172 and later i was getting no sound from the plugin. Looking at the Audio Ports in the properties, the Input In and Output Out showed as “(missing)”.
Also, looking at the Audio Busses, both the Input and Output were defaulted to disabled (unchecked). Checkmarking these to enable the busses, and then checking the box for “Automatically Map Ports to Plugin Busses” in the Audio Ports page brought the Input and Output ports back. (Which i then got to do on every song and rack that used the plugin.)
It’d be nice if Cantabile could detect something like this, to avoid unpleasant surprises when a plugin that had been working becomes non-functional when upgrading to a newer build of Cantabile - at least it could pop up a warning when scanning plugins at startup.
But finding stuff like this is why we have experimental builds, right ?
Thanks for reporting this. Sounds like a weird edge case where the plugin is reporting that none of it’s audio busses should be enabled by default. I’ll check it out during the week and see if I can make it a bit smarter for previously saved files.