Re: jack client autoconnection

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: jack client autoconnection

Kjetil Matheussen


Fons Adriaensen:

>
> 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.
>
>


I would say that your function is a connect-many-ports-at-once
function, not an autoconnect function.

What I'm thinking is that the jackd program has an extra
option called "--autoconnect-ports / -ap", which contains
a comma-separated list of port names. If its not supplied,
or "--no-autoconnect / -no" is not supplied either,

   jack_autoconnect(client,num_ports,port);

will connect to the physical ports.

This requires some modification to jack.
But it shouln't be that much of a work.



Besides, two other functions are needed as well:

int jack_get_num_autoconnect_playback_ports(void);
int jack_get_num_autoconnect_record_ports(void);


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jack client autoconnection

Fons Adriaensen-2
On Mon, Feb 04, 2008 at 06:16:38PM +0100, Kjetil S. Matheussen wrote:

> I would say that your function is a connect-many-ports-at-once
> function, not an autoconnect function.

It is 'auto' in the sense that a client wanting to connect
to a sensible place as a convenience to the user can do so
with one function call, and without having the know which
ports that will be.

Further it has the following properties:

- It takes into account the client's needs that may depend
  on what the client is going to do, e.g. play 5.1 or stereo
  wich will require different ports.

- It takes into account the user's requirements, i.e. that
  the playback ports need not be the physical ones, but e.g.
  the inputs of a room correction system, or that the user
  doesn't want any client to connect by itself.

- It has a safe default: no connections are made if the
  required env var does not exists. Without a safe default
  any such scheme would be as unacceptable as a dumb auto-
  connect.

> What I'm thinking is that the jackd program has an extra
> option called "--autoconnect-ports / -ap", which contains
> a comma-separated list of port names. If its not supplied,
> or "--no-autoconnect / -no" is not supplied either,
>
>    jack_autoconnect(client,num_ports,port);
>
> will connect to the physical ports.

If an app requires me to type an option to *not* connect
and has no way of being configured once and for all to
not autoconnect or to connect to some ports that I choose,
then for me it's as big a nuisance as one without such an
option. I will remove it from my system, and following
Machiavelli's advice, also exterminate its offspring and
family.

Typing a comma-separated list of ports each time I start
an app is a pain, hence the env var. Which also can be
shared for a number of clients, similar to e.g. 'EDITOR'.

The alternative is that the autoconnect ports are specified
in the client's configuration file. Given the fact that most
desktop apps have numerous configuration options even for
the silliest things such as e.g. skins, even the laziest app
writer can't really object to adding one more.


> This requires some modification to jack.

Again, IMHO, this sort of thing doesn't belong in jack.
You are mixing up the requirements of desktop entertainment
with those for an pro audio connection system. They should
remain well separated as there's no compromise between the
two. Let them both be happy by not depending on each other.

Ciao,

--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel