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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Mon Feb 4 20:15:01 2008
This archive was generated by hypermail 2.1.8 : Mon Feb 04 2008 - 20:15:02 EET