Re: [LAD] jack client autoconnection

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

Re: [LAD] jack client autoconnection

Kjetil Matheussen

Fons Adriaensen:
>
>> 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.

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.



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


-------------------------------------------------------------------------
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: [LAD] jack client autoconnection

Kjetil Matheussen


On Sun, 3 Feb 2008, Paul Coccoli wrote:

>
> In most other situations, I find auto-connect to be completely annoying.
>

And this api will help you turn it off, if you want to.


-------------------------------------------------------------------------
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: [LAD] jack client autoconnection

Bob Ham
In reply to this post by Kjetil Matheussen
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 <[hidden email]>


-------------------------------------------------------------------------
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: [LAD] jack client autoconnection

Fons Adriaensen-2
On Mon, Feb 04, 2008 at 01:52:32PM +0000, Bob Ham wrote:

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

IMHO, jack is not the place to hande this sort of thing.
For one, those clients that could benefit from autoconnection
need not all connect to the same ports. A 5.1 player will want
to use different ones than a stereo one, etc. etc. Building
all the intelligence needed to handle this sort of thing into
jack is just burdening it with things that are not if its
concern.

The only thing that *could* be part of jack is not the
autoconnection itself, but some form of access control,
which maybe is useful by itself but would also be a
line of defense against abusive autoconnecters.

If reading an env variable is 'too much hassle' what
are we doing here ? Anyway, a function to help apps
doing this and create the connections they need could
be part of libjack (or a specific lib) without having
to involve jackd itself. It just needs to be written
once.

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
Reply | Threaded
Open this post in threaded view
|

Re: [LAD] jack client autoconnection

Kjetil Matheussen
In reply to this post by Bob Ham


On Mon, 4 Feb 2008, Bob Ham wrote:

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

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);



-------------------------------------------------------------------------
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: [LAD] jack client autoconnection

Bob Ham
On Mon, 2008-02-04 at 15:14 +0100, Kjetil S. Matheussen wrote:
> 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?

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.

> 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 <[hidden email]>


-------------------------------------------------------------------------
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: [LAD] jack client autoconnection

Jonatan Liljedahl
Bob Ham wrote:
...

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

But, sometimes you want to create a port and *not* autoconnect it,
regardless of the state of the global autoconnect boolean. Ardour comes
to mind... And Sooperlooper, which has a main mix output (which should
autoconnect) and individual outs for each port (which should not
autoconnect, they are there just in case the user wants to route them to
something...)

So, I think it would be better to have a JackPortAutoconnect bit (part
of JackPortFlags) passed in the flags argument to jack_port_register().
Then if the global autoconnect boolean is true (default) then it will
autoconnect, if false, the JackPortAutoconnect bit will be ignored.

This makes it easy for clients to do autoconnection *if* they want (they
only pass the JackPortAutoconnect bit), and also for people to turn off
autoconnection globally. The boolean should perhaps even be
'jack_ignore_autoconnect' and default to false.

--
/Jonatan         [ http://kymatica.com ]

-------------------------------------------------------------------------
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: [LAD] jack client autoconnection

Kjetil Matheussen
In reply to this post by Bob Ham


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


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.


-------------------------------------------------------------------------
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: [LAD] jack client autoconnection

Bob Ham
In reply to this post by Kjetil Matheussen
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 <[hidden email]>


-------------------------------------------------------------------------
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: [LAD] jack client autoconnection

Jonatan Liljedahl
In reply to this post by Kjetil Matheussen
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:
>>>> 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?
>> 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.
>>
>>> 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.
>>
>
>
> 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.

I think my proposal with a JackPortAutoConnect bit in JackPortFlags is
sane, it would not break old applications; they would continue to
function exactly as they are now. but updated code can get rid of their
own autoconnection and use this autoconnect bit in the flags to
jack_port_register() instead.

it might need one addition though, there's different ways of
autoconnecting multiple clientports to multiple playback ports when the
number of them is unequal. One app might have 8 output ports and the
soundcard in the system has 2 playback ports. Should the first two
connect to the playback ports and the other 6 not be autoconnect, or
should they also connect to the first 2? Sometimes this is wanted,
sometimes not. Sometimes one wants to connect all port to separate
playback ports if available, else mix them in to the ones available.

This could be handled by a jack_autoconnect_reset() that resets the
autoconnect counter, or by two flags instead of one:
JackPortAutoConnectFirst and JackPortAutoConnectNext.

--
/Jonatan         [ http://kymatica.com ]

-------------------------------------------------------------------------
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: [LAD] jack client autoconnection

Fons Adriaensen-2
In reply to this post by Bob Ham
On Mon, Feb 04, 2008 at 03:40:12PM +0000, Bob Ham wrote:

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

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.


-------------------------------------------------------------------------
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: [LAD] jack client autoconnection

Bob Ham
In reply to this post by Kjetil Matheussen
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 <[hidden email]>


-------------------------------------------------------------------------
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: [LAD] jack client autoconnection

Kjetil Matheussen
In reply to this post by Kjetil Matheussen

Jonatan Liljedahl:

>>
>>
>> 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.
>
> I think my proposal with a JackPortAutoConnect bit in JackPortFlags is
> sane, it would not break old applications; they would continue to
> function exactly as they are now. but updated code can get rid of their
> own autoconnection and use this autoconnect bit in the flags to
> jack_port_register() instead.
>

Yes, as long as JackPortAutoConnect is false by default, that's
definietely a sane solution. Its basically the same kind of
proposal I made, just using a flag to jack_port_register
instead of a new function.


But there is one problem with it:

jack_client_t *client=...
jack_port_t
   *out_port[0]=jack_port_register(client,...JackPortAutoConnect);
jack_port_t
   *out_port[1]=jack_port_register(client,...JackPortAutoConnect);

<something happens>

jack_port_t
   *new_out_port[0]=jack_port_register(client,...JackPortAutoConnect);
jack_port_t
   *new_out_port[1]=jack_port_register(client,...JackPortAutoConnect);

The problem is that new_out_port[0] and new_out_port[1] will
connect to physical port number 2 and 3 instead of 0 and 1.


How do you fix this problem without adding a new function to jacklib?


-------------------------------------------------------------------------
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: [LAD] jack client autoconnection

Kjetil Matheussen
In reply to this post by Bob Ham


On Mon, 4 Feb 2008, Bob Ham wrote:

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

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)


-------------------------------------------------------------------------
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: [LAD] jack client autoconnection

Bob Ham
In reply to this post by Fons Adriaensen-2
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:
> > 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.
>
> 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.

> 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 <[hidden email]>


-------------------------------------------------------------------------
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: [LAD] jack client autoconnection

Jonatan Liljedahl
In reply to this post by Kjetil Matheussen
Kjetil S. Matheussen wrote:

>
> Jonatan Liljedahl:
>>>
>>>
>>> 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.
>>
>> I think my proposal with a JackPortAutoConnect bit in JackPortFlags is
>> sane, it would not break old applications; they would continue to
>> function exactly as they are now. but updated code can get rid of their
>> own autoconnection and use this autoconnect bit in the flags to
>> jack_port_register() instead.
>>
>
> Yes, as long as JackPortAutoConnect is false by default, that's
> definietely a sane solution. Its basically the same kind of
> proposal I made, just using a flag to jack_port_register
> instead of a new function.
>
>
> But there is one problem with it:
>
> jack_client_t *client=...
> jack_port_t
>   *out_port[0]=jack_port_register(client,...JackPortAutoConnect);
> jack_port_t
>   *out_port[1]=jack_port_register(client,...JackPortAutoConnect);
>
> <something happens>
>
> jack_port_t
>   *new_out_port[0]=jack_port_register(client,...JackPortAutoConnect);
> jack_port_t
>   *new_out_port[1]=jack_port_register(client,...JackPortAutoConnect);
>
> The problem is that new_out_port[0] and new_out_port[1] will
> connect to physical port number 2 and 3 instead of 0 and 1.
>
>
> How do you fix this problem without adding a new function to jacklib?

By having a JackPortAutoConnectFirst and JackPortAutoConnectNext instead:

jack_client_t *client=...

jack_port_t *new_out_port[0] =
  jack_port_register(client,...JackPortAutoConnectFirst);

jack_port_t *new_out_port[1] =
  jack_port_register(client,...JackPortAutoConnectNext);

jack_port_t *new_out_port[2] = ...

 <something happens>

jack_port_t *new_out_port[0] =
  jack_port_register(client,...JackPortAutoConnectFirst);

jack_port_t *new_out_port[1] =
  jack_port_register(client,...JackPortAutoConnectNext);

jack_port_t *new_out_port[2] = ...

--
/Jonatan         [ http://kymatica.com ]

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