Kevin Walsh Posted April 28 Share Posted April 28 I updated my TONEX plugin today to 1.71 and after installing, opening a pre-existing TONEX instance or trying to add a new instance to a track would instantly crash SONAR with a dump file. Turns out that IK installs the plugin into this folder: c:\program files\common files\VST3\IK-TONEX.vst3\Contents\x86_64-win\TONEX.vst3 I had to delete the SONAR registry entry for the plugin, then move the .vst3 file to c:\program files\common files\VST3\TONEX.vst3, then delete the old folder and re-scan. After that, it worked. Prior to doing all that, I tested it in CbB, SONAR and Reaper. Reaper worked, but CbB and SONAR crashed. I suspect SONAR sees the IK-TONEX.vst3 folder and assumes by it's extension that it is a vst3 file and tries to open it as such, but that's just guessing. Hope this helps someone else who sees this. Link to comment Share on other sites More sharing options...
Heath Row Posted April 28 Share Posted April 28 Just out of curiosity did you try just renaming the top level folder from 'IK-TONEX.vst3' to 'IK-TONEX' ? There was discussion about this somewhere here in the last month or so, I read it but didn't take much attention as I don't use SONAR/CbB/Sonar and the issue doesn't affect me, but the above would have been my first stumbling attempt to solve if it did. Link to comment Share on other sites More sharing options...
OutrageProductions Posted April 28 Share Posted April 28 (edited) CbB has had similar issues with other (but, strangely, not every) plug that gets installed into a nested folder with a vst[3] in the name, like Spitfire BBCSO Discovery and several others. Simplest solution is to move the plug executables up and out of named subdirectory, and delete the offending directory. FWIW; I've seen this same issue occurring in a Protools vst scan path as well, but not with AAX plugs. Stranger things... I've not seen this problem in my Cubase 13 or Nuendo 13, so I'm thinking that Steinberg has a secret that they aren't letting out to other developers about the way they parse naming conventions. Edited April 28 by OutrageProductions Link to comment Share on other sites More sharing options...
Kevin Walsh Posted April 28 Author Share Posted April 28 1 hour ago, Heath Row said: Just out of curiosity did you try just renaming the top level folder from 'IK-TONEX.vst3' to 'IK-TONEX' ? There was discussion about this somewhere here in the last month or so, I read it but didn't take much attention as I don't use SONAR/CbB/Sonar and the issue doesn't affect me, but the above would have been my first stumbling attempt to solve if it did. Yes, and that worked, but in the end I just moved it up to the top of the VST3 tree for simplicity's sake. In either case, SONAR seems to be crashing when it encounters a folder is named with a .vst3 extension. Note that it doesn't crash during the scan, it crashes when you try to add it to the fx bin on a track. The rename workaround is all very good, but imho in most cases it's not good form for software to crash. 1 Link to comment Share on other sites More sharing options...
Kevin Walsh Posted April 28 Author Share Posted April 28 51 minutes ago, OutrageProductions said: CbB has had similar issues with other (but, strangely, not every) plug that gets installed into a nested folder with a vst[3] in the name, like Spitfire BBCSO Discovery and several others. Simplest solution is to move the plug executables up and out of named subdirectory, and delete the offending directory. FWIW; I've seen this same issue occurring in a Protools vst scan path as well, but not with AAX plugs. Stranger things... I've not seen this problem in my Cubase 13 or Nuendo 13, so I'm thinking that Steinberg has a secret that they aren't letting out to other developers about the way they parse naming conventions. Reaper seems to have the secret as well. I only have CbB, Sonar and Reaper so those are the tests I ran. Link to comment Share on other sites More sharing options...
HIBI Posted April 28 Share Posted April 28 (edited) 19 hours ago, OutrageProductions said: CbB has had similar issues with other (but, strangely, not every) plug that gets installed into a nested folder with a vst[3] in the name, like Spitfire BBCSO Discovery and several others. I am guessing that the problem may occur in the following case. If an old version "C:\Program Files\Common Files\VST3\PluginName.vst3 (actual plugin file)" is originally existed and it's already scanned with Cakewalk, and a subsequent update installed the actual plugin file "PluginName.vst3" under a folder named "PluginName.vst3", such as "C:\Program Files\Common Files\VST3\PluginName.vst3 (folder)\Contents\x86_64-win\PluginName.vst3 (actual plugin file)". In this case, resetting and rescanning the plugin may solve the problem. (Just rescanning is not enough) So, I believe the baker should review the behavior of "VstScan.exe". Edited April 29 by HIBI 2 Link to comment Share on other sites More sharing options...
OutrageProductions Posted April 29 Share Posted April 29 12 minutes ago, HIBI said: So, I believe Bakers should review the behavior of "VstScan.exe". While this is certainly a worthwhile suggestion, it is kind of a Windows Julian extension naming convention issue as well. If you name a directory as 'filename.pdf' or 'filename.exe', and then stuff an identically named file inside it, Windows will throw up in your lap during a search, and log some strange stuff in the admin events. It's much safer to realize that the VST's are easier to scan when they are at the expected nesting hierarchy. Link to comment Share on other sites More sharing options...
Kevin Walsh Posted April 29 Author Share Posted April 29 I have no doubt the Windows has that problem but in this case the file and directory were not identically named. In fact, the file was a in another directory below the unfortunately named directory. Link to comment Share on other sites More sharing options...
Kevin Walsh Posted April 29 Author Share Posted April 29 (edited) On 4/28/2024 at 6:50 PM, HIBI said: I am guessing that the problem may occur in the following case. If an old version "C:\Program Files\Common Files\VST3\PluginName.vst3 (actual plugin file)" is originally existed and it's already scanned with Cakewalk, and a subsequent update installed the actual plugin file "PluginName.vst3" under a folder named "PluginName.vst3", such as "C:\Program Files\Common Files\VST3\PluginName.vst3 (folder)\Contents\x86_64-win\PluginName.vst3 (actual plugin file)". In this case, resetting and rescanning the plugin may solve the problem. (Just rescanning is not enough) So, I believe the baker should review the behavior of "VstScan.exe". That wasn't the problem in this instance. As I said in my OP, I reset the plugin, moved the plugin file, TONEX. vst3, to the common files\vst3 folder, and then delete the IK-TONEX.vst3 folder. I believe that if I had simply reset the plugin and rename the foler to say. IK-TONEX it would have worked as well. Thanks! Edited April 30 by Kevin Walsh Link to comment Share on other sites More sharing options...
HIBI Posted April 29 Share Posted April 29 33 minutes ago, Kevin Walsh said: That wasn't the problem in this instance. Yes, I knew, that because it seems you were creating a folder with a different name (IK-TONEX), so my comment was not directly relevant to the problem you had. I was merely referring to what often happens with recent plugin updates in response to OutrageProductions' comment. Sorry if I confused you. Anyway, I'm glad to hear your problem has been resolved. 1 Link to comment Share on other sites More sharing options...
Heath Row Posted April 29 Share Posted April 29 (edited) Just out of curiosity I checked out how many others there were like this in my VST3 folder, there were 73, well 72 I guess discounting TONEX. No issues at all. Edited April 29 by Heath Row Link to comment Share on other sites More sharing options...
Starship Krupa Posted April 30 Share Posted April 30 On 4/28/2024 at 4:50 PM, HIBI said: If an old version "C:\Program Files\Common Files\VST3\PluginName.vst3 (actual plugin file)" is originally existed and it's already scanned with Cakewalk, and a subsequent update installed the actual plugin file "PluginName.vst3" under a folder named "PluginName.vst3", such as "C:\Program Files\Common Files\VST3\PluginName.vst3 (folder)\Contents\x86_64-win\PluginName.vst3 (actual plugin file)". In this case, resetting and rescanning the plugin may solve the problem. (Just rescanning is not enough) So, I believe the baker should review the behavior of "VstScan.exe". Yeah, it doesn't seem to choke other hosts. My guess is that, if Windows barfs upon encountering that situation, it's passing the barf on to Sonar. Cakewalk is probably using a system call to get the file list whereas other hosts may be doing their own thing. On 4/28/2024 at 5:09 PM, OutrageProductions said: It's much safer to realize that the VST's are easier to scan when they are at the expected nesting hierarchy. For who to realize? Plug-in manufacturers such as IK Multimedia seem to have gotten it wrong, and innocent end users can't be expected to check for it. We have a situation where some installers seem to do this. It would be great if vstscan.exe could handle it more gracefully. 2 Link to comment Share on other sites More sharing options...
Matthew Russell Posted May 1 Share Posted May 1 I had the exact same thing and this thread has saved my life! I renamed folder and it didn't work, I had to move the plugin to where it originally existed. 1 Link to comment Share on other sites More sharing options...
John Maar Posted May 1 Share Posted May 1 (edited) Read this 2022 thread in the JUCE forum. Unfortunately, the .VST3 folder structure is the wave of the future. The non-folder installation of a .VST3 plugin in the /Common Files/VST3 folder was deprecated since the VST3 v3.6.10 SDK release (now on v3.7). JUCE forum thread on the .VST3 folder name extension Steinberg shows once again that they could not care less about users of non-Steinberg apps, which have already or will be forced to update their plugin scanners and plugin handlers. Edited May 1 by John Maar Link to comment Share on other sites More sharing options...
user 905133 Posted May 1 Share Posted May 1 (edited) Thanks for the relevant but generalized comments re: *.vst3 plugins being placed in folders named with a vst3 suffix. It prompted me to set up two new searches: "*.vst3" for files and "vst3 Folders" for folders that have the vst3 suffix. Edited May 1 by User 905133 Link to comment Share on other sites More sharing options...
msmcleod Posted May 1 Share Posted May 1 So Tonex 1.6 was installed, I updated to 1.7.1 and it crashed Sonar... so I did my usual with VSTi's that are also stand-alone: 1. Run Tonex standalone... let it sort itself out, then exit the app 2. Run Sonar 3. Run VST scan from Preferences 4. Drag Tonex into an FX bin - success! I recommend following these steps for all VSTi's that have a stand-alone version. 1 Link to comment Share on other sites More sharing options...
Kevin Walsh Posted May 1 Author Share Posted May 1 44 minutes ago, msmcleod said: So Tonex 1.6 was installed, I updated to 1.7.1 and it crashed Sonar... so I did my usual with VSTi's that are also stand-alone: 1. Run Tonex standalone... let it sort itself out, then exit the app 2. Run Sonar 3. Run VST scan from Preferences 4. Drag Tonex into an FX bin - success! I recommend following these steps for all VSTi's that have a stand-alone version. That's all very useful to know, thank you, it's great to have a good workaround from the Cakewalk team. Still I've got to believe there's some way Cakewalk could handle this situation without a crash with no error messages whatsoever. I know that for many people, running to a forum for an answer isn't something they normally do. Just my two cents worth. Link to comment Share on other sites More sharing options...
msmcleod Posted May 2 Share Posted May 2 8 hours ago, Kevin Walsh said: That's all very useful to know, thank you, it's great to have a good workaround from the Cakewalk team. Still I've got to believe there's some way Cakewalk could handle this situation without a crash with no error messages whatsoever. I know that for many people, running to a forum for an answer isn't something they normally do. Just my two cents worth. From what I could see, it was TONEX that was crashing Cakewalk - not the other way around. Link to comment Share on other sites More sharing options...
HIBI Posted May 2 Share Posted May 2 20 hours ago, msmcleod said: So Tonex 1.6 was installed, I updated to 1.7.1 and it crashed Sonar... so I did my usual with VSTi's that are also stand-alone: 1. Run Tonex standalone... let it sort itself out, then exit the app 2. Run Sonar 3. Run VST scan from Preferences 4. Drag Tonex into an FX bin - success! What will be changed by step 1? (Is it mandatory?) Does step 3 simply scan without resetting? Link to comment Share on other sites More sharing options...
Kevin Walsh Posted May 2 Author Share Posted May 2 (edited) 15 hours ago, msmcleod said: From what I could see, it was TONEX that was crashing Cakewalk - not the other way around. Sorry I misunderstood your comment and the fact that the plugin was causing the crash. I know there's not a lot that a DAW can do to prevent a plug-in from taking the whole thing down. I assumed it was cake walks problem because it doesn't crash with reaper. Speaking philosphically as a software user who isn't qualified to make the distinction between crash culprits, it would be lovely if all the companies involved could gather around a table and figure out how to prevent that from happening. Thanks for the information. Edited May 2 by Kevin Walsh Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now