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

Retornz · 13 December 2023 20:06

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 :

Build Cabbage & CabbagePluginSynth from the latest develop branch
Export the VST named “test123.so” to my Desktop (~/Desktop/test123.so)
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

Install Cabbage & CabbagePluginSynth from the latest Azure DevOps package
Export the VST named “test123.so” to my Desktop (~/Desktop/test123.so)
This automatically creates the ~/Desktop/test123.csd
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

Thanks in advance for your help

(I am using Lubuntu 22.04 LTS on a VM)

rorywalsh · 13 December 2023 09:36

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

github.com

rorywalsh/cabbage/blob/develop/Source/Audio/Plugins/CabbagePluginProcessor.cpp#L66-L74


	CabbageUtilities::debug(CabbageManufacturer);
	csdFile = File::getSpecialLocation(File::currentExecutableFile).withFileExtension(String(".csd")).getFullPathName();
	if (!csdFile.existsAsFile())
	{
        //In Linux, plugin application directory will reside in ~/Manufacturer/PluginName
		String filename = "~/" + String(CabbageManufacturer) + "/" + File::getSpecialLocation(File::currentExecutableFile).getFileNameWithoutExtension() + "/" + File::getSpecialLocation(File::currentExecutableFile).withFileExtension(String(".csd")).getFileName();


		csdFile = File(filename);
	}

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.

Retornz · 13 December 2023 16:59

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

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

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

Found some interesting topics about this : https://forum.juce.com/t/file-currentexecutablefile-in-plugin-did-something-change/35756
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…

rorywalsh · 13 December 2023 17:06

The CI is set to use:

github.com

rorywalsh/cabbage/blob/develop/azure-pipelines.yml#L60


      DOTNET_SKIP_FIRST_TIME_EXPERIENCE: 1
      DOTNET_CLI_TELEMETRY_OPTOUT: 1
  - task: PublishBuildArtifacts@1
    inputs:
      artifactName: 'Installers' 
      pathtoPublish: '$(Build.ArtifactStagingDirectory)'
#       # artifactName: '${SYSTEM_DEFAULTWORKINGDIRECTORY}/Cabbage.pkg'


- job: Linux
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - script: |
     sudo apt-get install ninja-build
     pip install requests
     python --version
     python build.py --config=Release --installLinuxDeps=True --packageType="Remote"
    env:
      COREHOST_TRACE: 0
      DOTNET_SKIP_FIRST_TIME_EXPERIENCE: 1
      DOTNET_CLI_TELEMETRY_OPTOUT: 1

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…

rorywalsh · 13 December 2023 17:08

Yes you can disable standalone here:

github.com

rorywalsh/cabbage/blob/develop/CMakeLists.txt#L161




IF(${midiEffectProject} GREATER 0)
    set(PLUGIN_AU_MAIN_TYPE "kAudioUnitType_MIDIProcessor")
    set(MIDI_EFFECT True)
else()
    set(MIDI_EFFECT False)  
endif()


juce_add_plugin(${PROJECT_NAME}
    PLUGIN_NAME ${PROJECT_NAME}
    FORMATS VST VST3 Standalone AU
    PLUGIN_MANUFACTURER_CODE ${JucePlugin_ManufacturerCode}
    PLUGIN_CODE RORY
    DESCRIPTION ${JucePlugin_Desc}
    NEEDS_MIDI_INPUT TRUE
    NEEDS_MIDI_OUTPUT TRUE
    IS_SYNTH ${PLUGIN_IS_A_SYNTH}
    BUNDLE_ID com.CabbageAudio.plugin
    IS_MIDI_EFFECT ${MIDI_EFFECT}
    EDITOR_WANTS_KEYBOARD_FOCUS TRUE
    VST_NUM_MIDI_INS 16

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

Retornz · 13 December 2023 21:22

Disabling “Standalone” did the trick
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

Very excited to release this soon !

rorywalsh · 14 December 2023 09:27

We look foward to this very much!

rorywalsh · 14 December 2023 09:47

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