1 Feb
2008
1 Feb
'08
2:34 p.m.
Fons Adriaensen:
Absolutely. I think a new function for jack would be
better than an environment variable though:
int jack_autoconnect_playback (jack_client_t *,
int portnum,
const char *source_port);
int jack_autoconnect_record (jack_client_t *,
int portnum,
const char *destination_port);
The reason is that this API will make it easier
for programs to make autoconnection configurabe.
Autoconnecting the old way (which includes finding
the physical ports and/or checking environment variables
for ports to connect to, etc.) is a lot more
hassle than just calling the functions above.
You can be as much of a professional user as you
want to.
It doesn't change the fact that other professionals might
not want the system to behave like you do.
Which again means it should be configurable. BTW, JSB may turn in his grave, but I _do_ like the
sound of sandysth... I still have to go through the
works to understand the algorithm...
Thank you very much. :-) I don't understand the algorithm
myself, so if someone else understood it, that would
be great. I think its quite similar to green noise,
which I read about later, created by moore at ucsd if
I remember correctly.
3 Feb
3 Feb
2:54 p.m.
New subject: jack client autoconnection
On Feb 1, 2008 1:34 PM, Kjetil S. Matheussen <k.s.matheussen(a)notam02.no> wrote:
Fons Adriaensen:
Absolutely. I think a new function for jack would be
better than an environment variable though:
int jack_autoconnect_playback (jack_client_t *,
int portnum,
const char *source_port);
int jack_autoconnect_record (jack_client_t *,
int portnum,
const char *destination_port);
The reason is that this API will make it easier
for programs to make autoconnection configurabe.
Autoconnecting the old way (which includes finding
the physical ports and/or checking environment variables
for ports to connect to, etc.) is a lot more
hassle than just calling the functions above.
If I understand your API above correctly, jackd would need to know
what playback ports it would allow autoconnection to, right? For
example, I'd like to be able to tell jackd that I have a pair of
physical outs connected to my power amp, and I will allow client to
auto-connect to those:
jackd [normal options] --allow-autoconnect --main-monitors
alsa_pcm:playback_3,alsa_pcm:playback_4
One instance where I've found auto-connect useful is with a simple
sample auditioner I wrote that uses gstreamer with the jack sink. I
want the auditioner to require as few clicks as possible, so I can
quickly start it up and check out a bunch of samples without having to
think about connecting it, etc.
In most other situations, I find auto-connect to be completely annoying.
You can be as much of a professional user as you
want to.
It doesn't change the fact that other professionals might
not want the system to behave like you do.
Which again means it should be configurable. 
4 Feb
4 Feb
9:52 a.m.
New subject: jack client autoconnection
On Fri, 2008-02-01 at 19:34 +0100, Kjetil S. Matheussen wrote:
int jack_autoconnect_playback (jack_client_t *,
int portnum,
const char *source_port);
int jack_autoconnect_record (jack_client_t *,
int portnum,
const char *destination_port);
The reason is that this API will make it easier
for programs to make autoconnection configurabe.
Autoconnecting the old way (which includes finding
the physical ports and/or checking environment variables
for ports to connect to, etc.) is a lot more
hassle than just calling the functions above.
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 enables a control interface that can present the user with a simple
system-wide toggle switch that would dictate whether or not ports are
automatically connected.
Bob
--
Bob Ham <rah(a)bash.sh>
10:15 a.m.
New subject: jack client autoconnection
On Mon, 4 Feb 2008, Bob Ham wrote:
On Fri, 2008-02-01 at 19:34 +0100, Kjetil S.
Matheussen wrote:
I'm not sure what you mean by the last sentence.
Is the "autoconnect" variable either 0 or 1?
But how do libjack know the order of ports? By just
using creation order? Well, I guess that will work.
How about this interface then?
void jack_enable_autoconnect(jack_client_t *);
void jack_disable_autoconnect(jack_client_t *);
And then a typical playback client would work like this:
jack_client_t *client=...
jack_enable_autoconnect(client);
jack_port_t *out_port[0]=jack_port_register(client,...);
jack_port_t *out_port[1]=jack_port_register(client,...);
jack_disable_autoconnect(client);
int jack_autoconnect_playback (jack_client_t
*,
int portnum,
const char *source_port);
int jack_autoconnect_record (jack_client_t *,
int portnum,
const char *destination_port);
The reason is that this API will make it easier
for programs to make autoconnection configurabe.
Autoconnecting the old way (which includes finding
the physical ports and/or checking environment variables
for ports to connect to, etc.) is a lot more
hassle than just calling the functions above.
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 enables a control interface that can present the user with a simple
system-wide toggle switch that would dictate whether or not ports are
automatically connected.
10:39 a.m.
New subject: jack client autoconnection
On Mon, Feb 04, 2008 at 03:14:54PM +0100, Kjetil S. Matheussen wrote:
How about this interface then?
void jack_enable_autoconnect(jack_client_t *);
void jack_disable_autoconnect(jack_client_t *);
And then a typical playback client would work like this:
jack_client_t *client=...
jack_enable_autoconnect(client);
jack_port_t *out_port[0]=jack_port_register(client,...);
jack_port_t *out_port[1]=jack_port_register(client,...);
jack_disable_autoconnect(client);
Or this one:
jack_client_t *client=...
jack_port_t *out_port[0]=jack_port_register(client,...);
jack_port_t *out_port[1]=jack_port_register(client,...);
connected = jack_autoconnect (2, out_port);
(one less call !!!)
Where jack_autoconnect() would use environment variables,
read .rc files, invoke the Buddha, or consult Paul Davis or
the oracle of Delphi to find out which ports to use, but
without requiring any special support from jackd itself.
In other words, ** you could write this function today **.
The functionality you want does not require any changes
to jack.
It may end up one day in libjack or in some other place
from where it can be reused.
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
11:40 a.m.
New subject: jack client autoconnection
On Mon, 2008-02-04 at 15:32 +0100, Fons Adriaensen wrote:
Or this one:
jack_client_t *client=...
jack_port_t *out_port[0]=jack_port_register(client,...);
jack_port_t *out_port[1]=jack_port_register(client,...);
connected = jack_autoconnect (2, out_port);
In other words, ** you could write this function today
**.
The functionality you want does not require any changes
to jack.
The problem is, you're still going to get client authors who say "Well,
I have to implement insanely-annoying-automatic-port-connection because
I have to cater for the people who don't use $your_system" By bringing
autoconnection into JACK itself, there's a standardised, authorised,
proven, approved method.
Bob
--
Bob Ham <rah(a)bash.sh>
12:03 p.m.
New subject: jack client autoconnection
On Mon, Feb 04, 2008 at 03:40:12PM +0000, Bob Ham wrote:
It's none of those, and it's crippled.
People who think that calling one (1, uno) function is a problem
should not be writing any form of applications, because they won't
get very far. Typically you need tens, hundreds, thousands. Raising
sheep may be a better occupation for them.
I will respect the opinions, tastes, and personal preferences of anyone
who demonstrates a minimal amount of engagement, but _not_ of someone who
is so blatantly lazy as you suggest (I don't mean you, but the people you
refer to), and stupid enough to admit it.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
On Mon, 2008-02-04 at 15:32 +0100, Fons Adriaensen
wrote:
In other
words, ** you could write this function today **.
The functionality you want does not require any changes
to jack.
The problem is, you're still going to get client authors who say "Well,
I have to implement insanely-annoying-automatic-port-connection because
I have to cater for the people who don't use $your_system" By bringing
autoconnection into JACK itself, there's a standardised, authorised,
proven, approved method.
12:45 p.m.
New subject: jack client autoconnection
On Mon, 2008-02-04 at 16:56 +0100, Fons Adriaensen wrote:
On Mon, Feb 04, 2008 at 03:40:12PM +0000, Bob Ham
wrote:
It's none of those, and it's crippled.
People who think that calling one (1, uno) function is a problem
should not be writing any form of applications
Well, in fact there would be no need to call any function to implement
generalised autoconnecting. All that is necessary is a daemon that pays
attention to the creation of new ports and connects them to hardware
ports.
The problem is that, whatever system you use that isn't JACK, is another
layer and some authors won't want to rely on it in order to provide
autoconnection functionality.
On Mon, 2008-02-04 at 15:32 +0100, Fons
Adriaensen wrote:
In other
words, ** you could write this function today **.
The functionality you want does not require any changes
to jack.
The problem is, you're still going to get client authors who say "Well,
I have to implement insanely-annoying-automatic-port-connection because
I have to cater for the people who don't use $your_system" By bringing
autoconnection into JACK itself, there's a standardised, authorised,
proven, approved method. I will respect the opinions, tastes, and personal
preferences of anyone
who demonstrates a minimal amount of engagement, but _not_ of someone who
is so blatantly lazy as you suggest (I don't mean you, but the people you
refer to)
Those authors that I'm referring to are the ones who would implement
their own autoconnecting functionality rather than making one function
call. Laziness is not the issue. The issue is the additional
dependency needed to provide autoconnection functionality.
Bob
--
Bob Ham <rah(a)bash.sh>
12:53 p.m.
New subject: jack client autoconnection
On Mon, Feb 04, 2008 at 03:32:23PM +0100, Fons Adriaensen wrote:
Where jack_autoconnect() would use environment
variables,
read .rc files, invoke the Buddha, or consult Paul Davis or
the oracle of Delphi to find out which ports to use, but
without requiring any special support from jackd itself.
The code required is much shorter than the length of this
thread so far, so I take the liberty to post it.
Quickly but not fully tested.
Enjoy.
(C) Fons Adriaensen, License: GPL
--- jack_autoconnect.h
#ifndef __JACK_AUTOCONNECT_H
#define __JACK_AUTOCONNECT_H
#ifdef __cplusplus
extern "C" {
#endif
#include <jack/jack.h>
/*
Connect to JACK ports specified by an environment variable.
Args:
client: Pointer to jack client_t of your application.
nport: The number of ports to connect.
ports: An array of existing jack ports you want to connect.
envvar: The name of the environment variable containing a comma-separated list of the
full
names of the ports you want your ports connected to.
Returns:
-1 if 'envvar' does not exist, the number of connections made otherwise.
Ports can be input or output in any mix, but of course directions should match
those of the ports specified by 'envvar'.
The name 'envvar' can be application-specific, e.g. MY_VERY_SPECIAL_PLAYER_PORTS,
or
general, e.g. JACK_STEREO_PLAYBACK_PORTS, JACK_5DOT1_PLAYBACK_PORTS, etc.
*/
extern int jack_autoconnect (jack_client_t *client, int nport, jack_port_t **ports, const
char *envvar);
#ifdef __cplusplus
}
#endif
#endif
--- jack_autoconnect.c
#include <stdlib.h>
#include <string.h>
#include <jack/jack.h>
#define BUFFSIZE 4096
int jack_autoconnect (jack_client_t *client, int nport, jack_port_t **ports, const char
*envvar)
{
int n, r;
char *t;
const char *p, *q;
char buff [BUFFSIZE];
p = getenv (envvar);
if (p == 0) return -1;
strncpy (buff, p, BUFFSIZE);
buff [BUFFSIZE - 1] = 0;
p = buff;
for (n = 0; n < nport; n++)
{
if ((p == 0) || (ports [n] == 0)) return n;
t = strchr (p, ',');
if (t) *t = 0;
q = jack_port_name (ports [n]);
if (jack_port_flags (ports [n]) & JackPortIsInput)
{
r = jack_connect (client, p, q);
}
else
{
r = jack_connect (client, q, p);
}
if (r) return n;
p = t ? (t + 1) : 0;
}
return n;
}
--- end of code
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
11:08 a.m.
New subject: jack client autoconnection
On Mon, 2008-02-04 at 15:14 +0100, Kjetil S. Matheussen wrote:
Yes, sorry. The "int autoconnect" parameter would be a boolean
indicator; 1 to enable autoconnecting, 0 to disable it. It would
probably be sensible to have a complementary jack_get_autoconnect()
function to return the value as well.
On Mon, 4 Feb 2008, 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 enables a control interface that can present the user with a simple
system-wide toggle switch that would dictate whether or not ports are
automatically connected.
I'm not sure what you mean by the last sentence.
Is the "autoconnect" variable either 0 or 1? But how do libjack know the order of ports? By just
using creation order? Well, I guess that will work.
Indeed. This is how most client-side autoconnecting seems to work at
the moment. Clients simply get "a list" of hardware ports from the
server and connect them in sequence against the client's own ports.
How about this interface then?
void jack_enable_autoconnect(jack_client_t *);
void jack_disable_autoconnect(jack_client_t *);
And then a typical playback client would work like this:
jack_client_t *client=...
jack_enable_autoconnect(client);
jack_port_t *out_port[0]=jack_port_register(client,...);
jack_port_t *out_port[1]=jack_port_register(client,...);
jack_disable_autoconnect(client);
Sorry; I obviously wasn't specific enough about the semantics of the
toggle function.
What I am suggesting is not to toggle autoconnecting for individual
clients, but to toggle autoconnecting for *all* clients, globally. The
flag that gets toggled would be a property of the engine, not the
client.
In terms of autoconnecting, clients would do quite literally nothing at
all. The above code would be rewritten as follows:
jack_client_t *client=...
jack_port_t *out_port[0]=jack_port_register(client,...);
jack_port_t *out_port[1]=jack_port_register(client,...);
Clients would never call the new function unless they were control
interfaces, eg. QJackCtl, a jack_autoconnect CLI program, or some
gnome-jack-autoconnect-switch applet.
This removes from client authors the burden of implementing
autoconnection, and enables a convenient interface for controlling
autoconnect behaviour.
Bob
--
Bob Ham <rah(a)bash.sh>
11:26 a.m.
New subject: jack client autoconnection
On Mon, 4 Feb 2008, Bob Ham wrote:
On Mon, 2008-02-04 at 15:14 +0100, Kjetil S.
Matheussen wrote:
Yes, sorry. The "int autoconnect" parameter would be a boolean
indicator; 1 to enable autoconnecting, 0 to disable it. It would
probably be sensible to have a complementary jack_get_autoconnect()
function to return the value as well.
Thanks for clearing up. But I'm pretty sure your idea is too
simple. We also need a way to create ports which are not
autoconnected.
The ideal way, if we follow this thread of thinking, would
be to add another type of jack_port_register function, which
does not autoconnect:
jack_port_register_no_autoconnect(client,...);
However, this new API will break a lot of current programs
which are using the old jack_port_register function instead.
Infact I don't think there is any (sane) way to make your
proposal work without creating lots of mess with ports
in old programs who are autoconnecting when it shouldn't.
On Mon, 4 Feb 2008, 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 enables a control interface that can present the user with a simple
system-wide toggle switch that would dictate whether or not ports are
automatically connected.
I'm not sure what you mean by the last sentence.
Is the "autoconnect" variable either 0 or 1? But how do libjack know the order of ports? By
just
using creation order? Well, I guess that will work.
Indeed. This is how most client-side autoconnecting seems to work at
the moment. Clients simply get "a list" of hardware ports from the
server and connect them in sequence against the client's own ports.
How about this interface then?
void jack_enable_autoconnect(jack_client_t *);
void jack_disable_autoconnect(jack_client_t *);
And then a typical playback client would work like this:
jack_client_t *client=...
jack_enable_autoconnect(client);
jack_port_t *out_port[0]=jack_port_register(client,...);
jack_port_t *out_port[1]=jack_port_register(client,...);
jack_disable_autoconnect(client);
Sorry; I obviously wasn't specific enough about the semantics of the
toggle function.
What I am suggesting is not to toggle autoconnecting for individual
clients, but to toggle autoconnecting for *all* clients, globally. The
flag that gets toggled would be a property of the engine, not the
client.
In terms of autoconnecting, clients would do quite literally nothing at
all. The above code would be rewritten as follows:
jack_client_t *client=...
jack_port_t *out_port[0]=jack_port_register(client,...);
jack_port_t *out_port[1]=jack_port_register(client,...);
Clients would never call the new function unless they were control
interfaces, eg. QJackCtl, a jack_autoconnect CLI program, or some
gnome-jack-autoconnect-switch applet.
This removes from client authors the burden of implementing
autoconnection, and enables a convenient interface for controlling
autoconnect behaviour.
12:22 p.m.
New subject: jack client autoconnection
On Mon, 2008-02-04 at 16:25 +0100, Kjetil S. Matheussen wrote:
On Mon, 4 Feb 2008, Bob Ham wrote:
> On Mon, 2008-02-04 at 15:14 +0100, Kjetil S. Matheussen wrote:
>> On Mon, 4 Feb 2008, Bob Ham wrote:
> What I am suggesting is not to toggle
autoconnecting for individual
> clients, but to toggle autoconnecting for *all* clients, globally.
Thanks for clearing up. But I'm pretty sure your
idea is too
simple. We also need a way to create ports which are not
autoconnected.
As Jonatan Liljedahl noted, a new bit in JackPortFlags would suffice.
Infact I don't think there is any (sane) way to
make your
proposal work without creating lots of mess with ports
in old programs who are autoconnecting when it shouldn't.
Backward compatibility (*mumble*) would be maintained by making ports'
default autoconnect bit negative; ie, having to set JackPortAutoconnect
to enable autoconnecting rather than set JackPortNoAutoconnect to
disable. Alas, this means the client author once again has to do
something.
Bob
--
Bob Ham <rah(a)bash.sh>
12:34 p.m.
New subject: jack client autoconnection
On Mon, 4 Feb 2008, Bob Ham wrote:
On Mon, 2008-02-04 at 16:25 +0100, Kjetil S.
Matheussen wrote:
No, as I wrote later, (I have problems with my smtp-server), it won't.
(fons' jack_autoconnect function would though, I think thats a good one)
On Mon, 4 Feb 2008, Bob Ham wrote:
> On Mon, 2008-02-04 at 15:14 +0100, Kjetil S. Matheussen wrote:
>> On Mon, 4 Feb 2008, Bob Ham wrote:
> What I am suggesting is not to toggle
autoconnecting for individual
> clients, but to toggle autoconnecting for *all* clients, globally.
Thanks for clearing up. But I'm pretty sure
your idea is too
simple. We also need a way to create ports which are not
autoconnected.
As Jonatan Liljedahl noted, a new bit in JackPortFlags would suffice.
11:04 a.m.
New subject: jack client autoconnection
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
5935
days inactive
5938
days old
linux-audio-dev@lists.linuxaudio.org
14 comments
5 participants
participants (5)
-
Bob Ham -
Fons Adriaensen -
Kjetil S. Matheussen -
Krzysztof Foltman -
Paul Coccoli