VST x Python Static Binary communication problem

General JUCE discussion
1

I’m trying to create a static binary file from a Python script that communicates with my VST plugin. The plugin currently is only VST3 and its main task is to:

  1. Start a Python script (Demucs) for processing.
  2. Run the script to split audio stems.
  3. Send the processed audio files back to the VST.

How it works is:

  • A user drags an audio file into the VST.
  • The Python script processes the file and returns the results to the plugin.
  • It also saves the processed stems and logs in a folder under Documents.

This setup worked perfectly for me, so I tried converting the Python file into an executable to store in ~/Library/Application Support/MyToBeMadeCompanyName/System. I managed to make it work briefly, but now I can’t replicate it and I’m completely stuck.

The workflow is simple and functional when all dependencies are installed, but I want to package it in a way that eliminates the need for users to manually set up dependencies, making it “distribution-ready” and reducing errors.

After trying a couple times to change it into an executive file the vst pops up but no audio pops back into it. It just doesn’t process. Doesn’t seem to be load up the executive file and/or load up demucs properly.

Does anyone know how to package this properly or where I might be going wrong? Any help would be appreciated

2

Did you notarize and codesign the binary? This is a bag of worms … without some clarity about your OS version and the entitlements of the DAW that you’re testing with, those worms are also thorny.

How are you spawning the custom binary? Did you pack the entire Python modules/dependencies into a single binary?

I think you’re going to need to codesign and notarize so that your binary is trusted to be spawned from another process …

3

Would you do a different approach? I just did this approach because Demucs doesn’t work through C++.

4

How important is it that this be done on MacOS? You don’t have such limitations on Linux …

An alternative approach would be to set up demucs entirely independently from a JUCE Plugin, perhaps writing a JUCE App “wrapper” around it as a service, and then having that App “wrapper” communicate with plugins (i.e. with Shared memory or IPC) to get the resources ‘commuted’ across these barriers…