Cabbage Logo
Back to Cabbage Site

[SOLVED] Linux : "could not find .csd file" when building from sources

Hello ! I just built Cabbage from source on Linux, but I’m having some troubles when I export a VST and try to use it in LMMS. (or in Ardour, same behaviour)

The steps I followed are :

  1. Build Cabbage & CabbagePluginSynth from the latest develop branch
  2. Export the VST named “” to my Desktop (~/Desktop/
  3. This automatically creates the ~/Desktop/test123.csd

When loading the VST in LMMS, the GUI is blank and the debug log of LMMS shows this :

So it can’t find the .csd because it is expecting the plugin name to be “NativeRemoteVstPlugin64” (which, btw, is the name of the LMMS VST handler : I tried to copy the .csd where it expects it, and… it works ! But it would prefer it to work normally : to use the real plugin name and find the .csd which is in the same folder as the .so)

Then, I tried with the latest artifact from Azure DevOps :confused:

  1. Install Cabbage & CabbagePluginSynth from the latest Azure DevOps package
  2. Export the VST named “” to my Desktop (~/Desktop/
  3. This automatically creates the ~/Desktop/test123.csd
  4. Load it in LMMS and now it works perfectly, the debug log doesn’t show any error :

So I tried to delete the .csd file from my desktop to see the debug message in LMMS logs, and the path where the .csd file is expected : the path is correct

@rorywalsh do you have and idea about what could explain this difference in behaviour ?
It is like when I build it myself, the .so get relinked to the host (because NativeRemoteVstPlugin64 is definetly something related to LMMS)
But I can’t see what I’m doing wrong here :confused:

Thanks in advance for your help :slight_smile:

(I am using Lubuntu 22.04 LTS on a VM)

Hmm, that’s odd. The relevant code is here:

You can place a breakpoint at line 68 and see if csdFile is valid. I suspect that File::currentExecutableFile is returning the host application rather than the plugin binary. But I have no idea why that is. :thinking:

1 Like

Thanks for your reply @rorywalsh !
I saw this part of the code and I think the same as you explained, but also I don’t know why :confused:

Maybe it is my Linux Distrib, I would like to test with the same version you use (or used before)
Could you tell me the Linux distrib of you Azure DevOps environment please ?

Thanks :slight_smile:

Btw, I confirm the theory that it’s pointing to the host exe :

Found some interesting topics about this : :wink:
So now the question is how to disable the “Standalone Plugin option” ? in Projucer I knew how to achieve that, but now with the new building system I’m not sure…

The CI is set to use:

According to their site that’s Ubuntu 22.04. Are you running the plugin through a debugger by any chance? I vaguely recall having this issue before when running through a debugger. Let me check…

Yes you can disable standalone here:

Funny, as I was typing my last message to you I was getting flashbacks of the issue myself. I was searching through the JUCE forum before I saw your link :rofl:

1 Like

Disabling “Standalone” did the trick :wink:
Hopefully this thread will be useful if someone stumble upon this issue in the future !
Thanks again for the help Rory, thanks to you ToneZ V2 will also be available on Linux Debian/Ubuntu !

Tested in Ardour : works great :smiley:

Very excited to release this soon !

We look foward to this very much!

1 Like

ToneZ is like the Cabbage equivalent of Surge XT :muscle: I can’t wait to hear how the new version sounds. Anyone unfamiliar with the original can check it out here