Re: [Jack-Devel] ladish + jack autoconnect

On January 8, 2012 1:01:06 AM Adrian Knoth wrote:
> On 01/07/2012 09:43 PM, Fons Adriaensen wrote:
> 
> Hi!
> 
> >> Stephane, Fons et al may provide some [constructive] criticism once
> >> the
> >> detailed proposal is out.
> > 
> > Constructive or not, this is what I think about the proposal.
> > 
> > I'm _not at all_ in favour of adding functionality to Jack
> > that only serves to resolve problems created by application
> > authors who either by ignorance or by design do things they
> > shouldn't do, such as autoconnecting without providing an
> > option to configure or disable it.
> > 
> > Doing this only encourages the creation or continued acceptance
> > of apps that don't behave as required. The correct course of
> > action is to discourage the same, and force app authors to
> > either do their homework or face being excluded.
> 
> While I think you clearly have a point here, the discussion reminds me
> about the glibc memcpy() bug on newer Intel processors: copying
> backward turned out to be faster on some architectures, and for the
> sake of efficiency, glibc changed from copying forward to copying
> backward on these machines.
> 
> Though memcpy's manpage is absolutely clear that source and target
> memory areas must not overlap, some application developers did not worry
> about it. Overlap was no problem as long as memcpy() was traversing from
> low to high addresses. Once changed, many applications broke, including
> flash.
> 
> There was a big discussion and blaming of application developers, Adobe
> in particular, that memmove() should have been used as mentioned all
> over the place.
> 
> Linus' position was rather clear: the user doesn't care who broke it,
> the user demands a working system. As simple as that, end of the story.
> 
> 
> It's exactly what we're facing here. We could probably continue to argue
> purity vs. pragmatism for weeks.
> 
> How about the following: let's do both - work around the bug to please
> the user *AND* blame the application developers.
> 
> For this to work, I suggest to emit a (rude) warning every time an
> application tries to self-connect (its output ports) if jackd is running
> in one of the "compatibility modes" (a.k.a. ladish mode).
> 
> Something like:
> 
>     "Application foo attempted to self-connect its ports. See
>      http://some.url.org/faq/... why this is bad and update your
>      application to a fixed version."
> 
> If there are really many broken applications out there, users would
> hopefully bug the upstream authors until they either do something about
> it or prove Nedko wrong. ;)
> 
> 
> Just my €0.02
> 
> Jack-Devel mailing list
> [hidden]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

Hi list. Sorry late post but I've followed the thread.
This looks like quite a good place to come in...

Just some experiments with so called 'auto-connect'.
It may not be the exact same thing as what you're discussing but
 I hope it's relevant.

To help new users and as a stepping stone to a better configuration system, 
 at startup I auto-fill our midi ports with found Jack midi devices now.
By that I mean I scan for Jack midi ports and create matching client ports
 and then automatically connect them together.
Then everything is ready to go, the user can immediately start creating midi 
 tracks and doesn't necessarily have to open our midi configuration dlg.
Thus as viewed in say qjackctl, we have matching client ports and 
 connections for every outside port found.
 
Not fond of auto-doing anything, it's behaviour can change as our 
 configuration system evolves, or be removed (and may very well be). 
But previously it was a rather clumsy affair for our users to set up devices.

So anyway I actually wanted to have the app /continuously/ watch for new ports
 and auto connect them as well, instead of just at startup or on-demand.
I didn't, because it seems a bad idea. 
It could lead to infinite recursive auto-connecting. Right?

Say two apps employ this auto-connecting technique.
Then they are both constantly watching for each others' ports.
As soon as the second app starts the first app creates matching ports,
 then the second app sees these new ports and creates matching ones,
 then the first one sees those ports and creates matching ones, and so on.

I'm wondering if even the one-time auto-connect at startup is still a bad 
 idea. It still kinda WIP, maybe make it more optional (click-to-auto-fill). 
(There sure are a lot of ports created!)
With this talk of auto-connect and session managers I would like to ask if 
 this one-time auto-connect at startup might also interfere with session 
 managers like LASH or LADISH, or even say Jack Session? (We only have LASH.) 
Maybe I should determine whether it is in fact a session, and bypass
 the automatic port creation and auto-connecting at startup...

Thanks. Tim.

1325985995.2896_0.ltw:2,a <25021232.SZxW69I6DF at amd64-desktop>