Re: [Jack-Devel] ladish + jack autoconnect

PrevNext  Index
DateSun, 08 Jan 2012 14:42:01 -0500
From Tim E. Real <[hidden] at rogers dot com>
To[hidden] at lists dot jackaudio dot org
In-Reply-ToNedko Arnaudov Re: [Jack-Devel] ladish + jack autoconnect
Follow-UpPaul Davis Re: [Jack-Devel] ladish + jack autoconnect
On January 8, 2012 3:59:52 AM you wrote:
> "Tim E. Real" <[hidden]> writes:
> > 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...
> 
> It will interfere badly with ladish if ladish rooms are in use. Please
> make your app to not autoconnect when it detects that it is started by
> the ladish daemon. Qtractor already implementes such check. The check
> inspects the LADISH_APP_NAME environment variable. The environment
> variables that ladishd sets upon starting app are documented here:
> 
> http://ladish.org/wiki/envvars
> 
> I'll leave jack-session detection to be described by whom worships it.
> 
> AFAIK LASH library initialization success is a sign of LASH server
> availability.
> 
> The bad(or good) news here is that at some point ladish will allow self
> connects. For this to work properly jack clients/ports participating in
> given virtual graph should be separated from those participating in
> other virtual graphs. Separated at JACK API level. This is actually a
> good reason to not ban (in political sense) autoconnects at app level
> but to restrict them in the jack server, when user setup actually
> requires it.

OK Thanks for the cool tips!

The more I think about it, the more wrong my auto-connect seems.
I should not auto-create ports or auto-connect anything, even at startup.

Instead I should try to find a way, certainly, to present our user with the 
 found Jack midi port names - from directly within our midi tracks for
 convenience - and let them decide from there what to create and connect, 
 but under no circumstances should I 'auto-do' anything.

It's interesting how re-connections of this nature tie in with session
 managers. It's like, at some point the session manager could be seen as
 more like part of the 'project manager' inside the app - more integral to 
 the app than just a sort of external 'loader'.
That at some point I should hand off this desired reconnect functionality 
 to the session manager, that's what they do. ('Gotcha' here is what if the 
 session manager is not running...)

Thanks. Tim.
PrevNext  Index

1326051755.28885_0.ltw:2,a <1511179.xj3r8tlQME at amd64-desktop>