Bob Ham wrote: > Even less hassle is for clients to do nothing at all and leave the whole > business entirely for jackd. I suggest the following function instead: > int jack_set_autoconnect(jack_client_t *, int autoconnect);
This is fine for simple clients that have two outputs that are always connected to default playback ports, and two inputs that are always connected to default capture ports. However, it is of little use in the more complex cases, where ports come and go, some ports may be mono, there may be 8 synth output ports and 8 soundcard playback ports. What I could propose is API like this: int jack_port_add_tag(jack_port_t *, const char *tag, int priority); void jack_port_remove_tag(jack_port_t *, const char *tag); const char **jack_port_get_tags((jack_port_t *); jack_port_t **jack_get_ports_by_tag(jack_client_t *, const char *tag); void jack_port_tags_free(const char **); void jack_port_list_free(jack_port_t **); and perhaps: typedef void (*PortTagListUpdateCallback)(jack_port_t *t, void *data, const char *tag, int was_added); void jack_set_tag_callback(PortTagListUpdateCallback, void *data); Example tags (some are for physical ports, some are for application ports): - related to channels: mono, stereo, stereo-left, stereo-right, 5.1, 5.1-left-front, 5.1-right-front, 5.1-left-rear, 5.1-right-rear, 5.1-center-front, 5.1-surround (so a left stereo channel would have "stereo" and "stereo-left") - related to purpose: default-out (system:playback_1/2 or first unconnected mixer input, a mixer will specify the higher priority), physical-out (physical soundcard), physical-out-2, physical-out-3, reverb (inputs and outputs of reverb effect), chorus, fx-1, fx-2 (for global fx) - related to port purpose: midi-in, kbd (and kbd-2 etc.), drums, ctlsurface, guitar (for audio capture for guitar), mic (audio capture for mic), synth (for synth application's midi port AND audio output), drummachine (for drum machine's midi port and audio output) - related to relationship to other ports - audio-output-for:system:midi_capture_1 etc. - related to application name (name:hydrogen) Then a definable, prioritized set of JACK-wide rules (provided by default, but configurable via some sort of GUI) could make reasonable autoconnection possible. I guess the autoconnection mechanism could be separate from JACK itself, as there may be some uses for both simple autoconnection mechanisms (which only deal with things like connecting instrument outputs to audio out, and instrument inputs to one predefined MIDI port) as complex auto-patchbay systems (where you could juggle between 4 different drum machines, 3 synths and 5 main mixers and have everything working :) ). And the complex systems might be written at some time in the future or not at all. The patchbay system (with automatic connection based on tags) might be a part of session handling as well. Okay, the system looks very complex so perhaps it is a bit scary. Still, it's just 6-7 functions in the API, and the only one to be used by most non-patchbay clients is jack_port_add_tag. Not THAT scary. On the other hand, perhaps 99.9% of audio application users have at most 2 inputs, 2 outputs and 1 MIDI, and building a complex tagging system for 2 people total is pointless. Krzysztof _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
