Re: [proposal] connection veto callback

On Sat, 2009-05-30 at 23:11 +0200, Fons Adriaensen wrote:
> allowing any jack client to make its
> own connections (or others) is seen as a 'natural' thing
> because this is, and always has been, part of the client
> API. But is it such a good idea ? I'm more and more
> convinced it isn't.

I'd agree with you; LASH would be a lot simpler if JACK clients weren't
able to connect their own ports.  However, LASH is also a JACK client.
At some point, there has to be some API for external applications to
connect JACK ports together.  Otherwise, relying on static configuration
of ports would reduce the flexibility of JACK, and its power.  And
moving the API out of libjack would only obfuscate it, not remove the
capability.

There is also the issue of the valid use of JACK ports to connect audio
objects within a single client, such as ardour.  Such clients would all
need to reimplement the currently-shared port connection functionality
that already exists within JACK and this doesn't seem like a good idea.


> It certainly does not correspond to anything in the
> 'real' (hardware) world. Pieces of audio equipment
> do not connect themselves.

I agree with this; I really dislike the ubiquitous "auto-connect output
ports to hardware ports" functionality.  IMHO this is the job of a
session manager or some other layer outside the client.

You could modify the semantics of the existing JACK API to only allow
connections to and from a client's own ports.  But then, again in order
to support inter-client connections, there will need to be another API
that will allow this.  And then the "we'll do everything for you"
clients (rosegarden, ardour, etc, etc) will just take to using the
separate API.  To do everything for you :-)

Possibly the veto is the way to go.  In fact, you could implement any
restriction scheme you liked using a veto.  The key issue is that there
must be no way to veto the veto, otherwise you're back at square one.


> One step beyond this is 'persistent application ports'
> - these correspond to an application but exist even
> if the application doesn't run. Instead of creating
> them the app would 'bind' to them.

> Again this corresponds more to a hardware scenario:
> when you install a new piece of equipment it gets
> a place in a rack and is wired to the patchbay.

> What we do now in software corresponds more to
> breaking down your studio completely after each
> session, and having to rewire it from scratch for
> the next. The applies to jack, to ardour sessions,
> and also to what LASH tries to do.

This does seem like a good idea.  Really, though, it's just a matter of
what software does it.  Some software at some point will have to
construct this static patch bay from some configuration file.

At present, this is the kind of functionality that LASH aims to support.
The 'binding' occurs through the creation of consistently named ports,
which LASH will then connect appropriately according to the
configuration stored in the session.  LASH could also refer to a static
map in addition to the session configuration; that wouldn't be much of a
change.  The details of specifying and matching against a static map
would probably be non-trivial, though.

Bob

--
Bob Ham <rah@...>


_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org