search

juce-framework / JUCE

JUCE is an open-source cross-platform C++ application framework for desktop and mobile applications, including VST, VST3, AU, AUv3, LV2 and AAX audio plug-ins.
https://juce.com
Other
6.38k stars 1.69k forks source link

JACK connection management #333

Open umlaeute opened 6 years ago

umlaeute commented 6 years ago

building a plugin as a standalone application with JACK support, it seems that the connection management logic is bogus^W conflicting with JACK's idea of connection management.

One core idea of JACK is to be able to connect arbitrary channels of a single application to arbitrary channels of arbitrary applications. Unfortunately JUCE's JACK support focuses on the idea of multi-channel io-devices rather than single ports. It enforces this idea by doing the connection management itself, only allowing to connect to all outputs/inputs of another jack client. This obviously prevents the user to connect to certain channels selectively (e.g. it is not possible to connect a JUCE mono plugin to the 3rd input channel of a 24 channel soundcard; the best you get is a 24 channel plugin connected to all inputs).

Being able to select input and output devices (e.g. soundcard; my DAW;...) is nice for a quick setup, but it only caters for the most trivial cases (see my example in #332 )

so here's a suggestion: selecting <<none>> (or some other generic non-device name) as input/output in the plugin's audio settings, should instantiate the plugin with inputs and outputs (as declared with withInput() resp withOutput()) but not auto-connect to any other client. This should probably also be the default connection mode.

this would allow users to use the already existing and pretty robust and mature jack connection management tools (e.g. qjackctl, jack-plumbing, qjackconnect, patchage, njconnect, PatchMatrix, Catarina to name just a few) rather than fight with the way JUCE thinks this should be handled.

For any connection management to work properly, client names with a low likelihood of name-clashes are a must (see #331)

mzuther commented 6 years ago

I was just to open an issue about this. Thanks @umlaeute for doing the hard work for me! :)

I'm very happy with the JACK implementation in JUCE, with this being the one thing that drives me crazy. Well, a little... ;)

mark-orion commented 1 year ago

This urgently needs solving. The JUCE Jackd implementation is throwing the whole Jackd philosophy of being able to freely connect, disconnect and route audio and MIDI over board. The most useful implementation would be one that has the current autoconnect behaviour disabled by default, but allows autoconnection to be enabled as an option.

PowerUser64 commented 10 months ago

Is there any way I can help accelerate resolving this?

essej commented 10 months ago

I’m also in agreement that this needs to be done, having the default implementation expose the Jack client with a possibly selectable number of inputs and outputs (within limits), and no auto-connections so that it plays nicely with classic JACK behavior.

I think one of us who has time should just go ahead and do a reference implementation on a fork, and present it as a PR and let JUCE decide how to proceed, in the meantime anyone can use/merge from the fork.