|
»
« Return to Thread: [proposal] connection veto callback
Re: [proposal] connection veto callback
by Fons Adriaensen-2
::
Rate this Message:
On Sat, May 30, 2009 at 12:15:57PM +0200, torbenh@... wrote:
> On Thu, May 28, 2009 at 10:00:46PM +0200, Fons Adriaensen wrote:
> > But IHMO this veto system has all it takes to create more
> > miseray than it could solve - it basically allows any app
> > to veto any connection, making it impossible to decide or
> > configure this on any higher level. One would need a veto
> > system agains clients abusing this to ensure things remain
> > sane.
> >
> > If clients want to restrict access to their own ports that
> > is OK. Anything else should not be the business of any
> > particular client but be decided higher up.
>
> actually this is what i am fearing a bit too. iE dumb client vetoing
> disconnect of their autoconnected ports.
>
> *shiver*
*Shiver* indeed. And I wouldn't be surprised at all
if some apps start doing this sort of thing.
I've been musing a lot about this and related issues
lately. There's yet no complete picture resulting from
this, but some ideas seem to emerge and wanting to stay.
One of them is this: 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.
It certainly does not correspond to anything in the
'real' (hardware) world. Pieces of audio equipment
do not connect themselves.
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. Once the app runs
the net result is the same as it is now. But since
these ports can be semi-permanent (in the sense that
they are created as part of a more or less fixed
studio setup) their connections can be as well.
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.
The patchbay sockets are permanent, they exist
even if the equipment is not used or switched off.
It is this permanent wiring to a central patching
device that allows you to set up a studio once and
then use it a hundred times by just switching it
on. 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.
One more: in a 'real' studio having a hardware
mixer (or even a control surface looking like
a real mixer), it is the mostly the mixer that
is used for routing signals. Suppose someone
walks in with his MP3 player and saying 'you
should listen to this'. Will you wire the player
to the monitoring amps ? Probably not. You plug
it into two free mixer line inputs on the patchbay
and use the mixer to determine how to listen to
it.
What allows you to do this is that the mixer is
there all the time, its structure is more or less
fixed, and many if its inputs and outputs are wired
semi-permanently - even if not used - in a way that
makes practical sense. All you need to do is push
up a fader and hit a button or two. Even recalling
a session and restoring a complete mixer state does
not modify it in an essential way. And it certainly
does not modify the external wiring. It may change
the way connectors map to internal signals, but
that is something quite different - and internal.
--
FA
Io lo dico sempre: l'Italia รจ troppo stretta e lunga.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
> On Thu, May 28, 2009 at 10:00:46PM +0200, Fons Adriaensen wrote:
> > But IHMO this veto system has all it takes to create more
> > miseray than it could solve - it basically allows any app
> > to veto any connection, making it impossible to decide or
> > configure this on any higher level. One would need a veto
> > system agains clients abusing this to ensure things remain
> > sane.
> >
> > If clients want to restrict access to their own ports that
> > is OK. Anything else should not be the business of any
> > particular client but be decided higher up.
>
> actually this is what i am fearing a bit too. iE dumb client vetoing
> disconnect of their autoconnected ports.
>
> *shiver*
*Shiver* indeed. And I wouldn't be surprised at all
if some apps start doing this sort of thing.
I've been musing a lot about this and related issues
lately. There's yet no complete picture resulting from
this, but some ideas seem to emerge and wanting to stay.
One of them is this: 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.
It certainly does not correspond to anything in the
'real' (hardware) world. Pieces of audio equipment
do not connect themselves.
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. Once the app runs
the net result is the same as it is now. But since
these ports can be semi-permanent (in the sense that
they are created as part of a more or less fixed
studio setup) their connections can be as well.
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.
The patchbay sockets are permanent, they exist
even if the equipment is not used or switched off.
It is this permanent wiring to a central patching
device that allows you to set up a studio once and
then use it a hundred times by just switching it
on. 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.
One more: in a 'real' studio having a hardware
mixer (or even a control surface looking like
a real mixer), it is the mostly the mixer that
is used for routing signals. Suppose someone
walks in with his MP3 player and saying 'you
should listen to this'. Will you wire the player
to the monitoring amps ? Probably not. You plug
it into two free mixer line inputs on the patchbay
and use the mixer to determine how to listen to
it.
What allows you to do this is that the mixer is
there all the time, its structure is more or less
fixed, and many if its inputs and outputs are wired
semi-permanently - even if not used - in a way that
makes practical sense. All you need to do is push
up a fader and hit a button or two. Even recalling
a session and restoring a complete mixer state does
not modify it in an essential way. And it certainly
does not modify the external wiring. It may change
the way connectors map to internal signals, but
that is something quite different - and internal.
--
FA
Io lo dico sempre: l'Italia รจ troppo stretta e lunga.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
« Return to Thread: [proposal] connection veto callback
| Free embeddable forum powered by Nabble | Forum Help |
