Feat - environment variable for overriding bespoke config file location

[PowerUser64]

Summary

One of the things bespoke doesn't support very well is JACK. This is mostly the fault of JUCE, but bespoke can help make it better by allowing changing the config file location (userprefs.json) in a way that is scriptable. This environment would probably be called something like BESPOKE_CONFIG_LOCATION or BESPOKE_USERPREFS.

Motivation

This would make it easier to work around issues with JUCE by generating config files. For example, it would be possible to make a script that generates a config file that causes bespoke to spawn an arbitrary number of IO ports when combined with something like https://github.com/guysherman/jack-passthrough.

Related: #500, #503, https://github.com/juce-framework/JUCE/issues/333

[grammoboy2]

In general it would be better if those JACK related issues in JUCE would be fixed instead of implementing less ideal workarounds. I think BespokeSynth deserves reliable JACK support. Lot's of (talented) hobby programmers can implement JACK support properly, but JUCE can't? Hard to believe. It hurts other synths as well, Vital and Surge for instance, to name a few nice ones.

[PowerUser64]

I wish JUCE would fix their problems rather than ghosting everyone in the comments on their issues and making us deal with it. I want to get things like this solved.

[crshrprt]

Bespoke is already capable of spawning an arbitrary number of ports when using JACK (real one, not PipeWire) backend and using jack_passthru. There are some problems when the number of ports gets over a certain number, that is dependent on several factors. See: #921, #626.

[PowerUser64]

Yes! jack_passthru is actually what I want to script. If the config file could be overridden, it would be possible to make a script that:

• picks two names (e.g. "Bespoke In" and "Bespoke Out")
• starts two instances of jack_passthru, each with JACK clients named according to the two names above
• generates a bespoke config file with the jack inputs and outputs set to the names of the two jack_passthru instances
• starts bespoke with the generated config file (it will then auto-connect to jack_passthru)

Additionally it would be possible to do things from the script like change the number of ports on jack_passthru to change the number of ports that bespoke spawns with.

[crshrprt]

Your usecase looks to me it can be easily solved with some clever symlinking, pointing at or swapping different configuration files, all done with a script (or session manager running it). Since you are going to run other programs, having env variables is going to solve your problem partially.

Also, BespokeSynth has already a max_(input/output)_channels setting where you can define the maximum number of ports. They will be created considering the audio_(input/output)_device defined in the settings, and the number of ports the device/node have. To avoid problem always set max_(input/output)_channels >= the number of ports your device/node has. I had crashes when max_(input/output)_channels are less than the ports they are connecting to.

All that said, I'm in favor having some more commandline arguments or variables, the more the better. Your case lacks a bit of evidence of needing env variables. One stronger case could be having multiple BespokeSynth instances running on the same machine with different configs, for example (if that could ever makes sense).