IK Multimedia TONEX install crashes SONAR

[Kevin Walsh]

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.

[Heath Row]

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.

[OutrageProductions]

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

[Kevin Walsh]

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.

 

[Kevin Walsh]

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.

[HIBI]

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

[OutrageProductions]

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. 

[Kevin Walsh]

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.

[Kevin Walsh]

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

[HIBI]

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.

[Heath Row]

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

[Starship Krupa]

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.

[Matthew Russell]

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.

[TheMaartian]

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

[user 905133]

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

[msmcleod]

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. 

[Kevin Walsh]

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.

[msmcleod]

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.

[HIBI]

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?

[Kevin Walsh]

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