headers
Dave Robillard | 1 Apr 2007 21:30
Picon
Picon
Favicon

Re: [Jackit-devel] port and connection monitoring

On Sun, 2007-04-01 at 12:22 +0200, Fons Adriaensen wrote:
> On Sun, Apr 01, 2007 at 11:49:53AM +0200, Lars Luthman wrote:
> 
> > Agreed. I'm using the graph order callback and iterating over all ports
> > in Dino as well.
> 
> Using _only_ the graph reorder callback will not work in all cases.
> 
> When a new app is started, you normally get a number of port-registration
> callbacks followed by a graph-reorder. Even if you ignore the port
> callbacks you will discover the new app in the graph callback. So
> far so good.
> 
> But I have one app that creates 64 output ports. When this is started,
> I _first_ get a graph callback - and scanning the ports at that time
> doesn't show the new ones - followed by the port callbacks.
> So ignoring the port callbacks means you discover the new app only
> later, when it gets connected.

This happens even if there are connections to the new ports?  That's
definitely a bug.

-DR-


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
(Continue reading)

Permalink | Reply |
headers
Fons Adriaensen | 1 Apr 2007 23:37

Re: [Jackit-devel] port and connection monitoring

On Sun, Apr 01, 2007 at 03:30:18PM -0400, Dave Robillard wrote:

> > But I have one app that creates 64 output ports. When this is started,
> > I _first_ get a graph callback - and scanning the ports at that time
> > doesn't show the new ones - followed by the port callbacks.
> > So ignoring the port callbacks means you discover the new app only
> > later, when it gets connected.
> 
> This happens even if there are connections to the new ports?  That's
> definitely a bug.

No, when a connection is made to the new app there is a graph-reorder cb
and then all new ports are visible.

The point is that relying only the graph-reorder cb to discover the new
app will not work in this case as the this cb is made before the new ports
exist. 

--

-- 
FA

Follie! Follie! Delirio vano è questo !

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply |
headers
Dave Robillard | 2 Apr 2007 21:36
Picon
Picon
Favicon

Re: [Jackit-devel] port and connection monitoring

On Sun, 2007-04-01 at 23:37 +0200, Fons Adriaensen wrote:
> On Sun, Apr 01, 2007 at 03:30:18PM -0400, Dave Robillard wrote:
> 
> > > But I have one app that creates 64 output ports. When this is started,
> > > I _first_ get a graph callback - and scanning the ports at that time
> > > doesn't show the new ones - followed by the port callbacks.
> > > So ignoring the port callbacks means you discover the new app only
> > > later, when it gets connected.
> > 
> > This happens even if there are connections to the new ports?  That's
> > definitely a bug.
> 
> No, when a connection is made to the new app there is a graph-reorder cb
> and then all new ports are visible.
> 
> The point is that relying only the graph-reorder cb to discover the new
> app will not work in this case as the this cb is made before the new ports
> exist. 

Yes, my point is that this is a bug.  The ports should definitely (IMO?)
be reported /before/ the graph order callback.

Though in any case, a single [dis]connection callback would be much
nicer than the current graph order situation..

-DR-


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
(Continue reading)

Permalink | Reply |
headers
Paul Davis | 18 Apr 2007 20:54

Re: [Jackit-devel] port and connection monitoring

On Mon, 2007-04-02 at 15:36 -0400, Dave Robillard wrote:
> On Sun, 2007-04-01 at 23:37 +0200, Fons Adriaensen wrote:
> > On Sun, Apr 01, 2007 at 03:30:18PM -0400, Dave Robillard wrote:
> > 
> > > > But I have one app that creates 64 output ports. When this is started,
> > > > I _first_ get a graph callback - and scanning the ports at that time
> > > > doesn't show the new ones - followed by the port callbacks.
> > > > So ignoring the port callbacks means you discover the new app only
> > > > later, when it gets connected.
> > > 
> > > This happens even if there are connections to the new ports?  That's
> > > definitely a bug.
> > 
> > No, when a connection is made to the new app there is a graph-reorder cb
> > and then all new ports are visible.
> > 
> > The point is that relying only the graph-reorder cb to discover the new
> > app will not work in this case as the this cb is made before the new ports
> > exist. 
> 
> Yes, my point is that this is a bug.  The ports should definitely (IMO?)
> be reported /before/ the graph order callback.
> 
> Though in any case, a single [dis]connection callback would be much
> nicer than the current graph order situation..

how so?

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
(Continue reading)

Permalink | Reply |
headers
Dave Robillard | 20 Apr 2007 19:25
Picon
Picon
Favicon

Re: [Jackit-devel] port and connection monitoring

On Wed, 2007-04-18 at 14:54 -0400, Paul Davis wrote:
> On Mon, 2007-04-02 at 15:36 -0400, Dave Robillard wrote:
> > On Sun, 2007-04-01 at 23:37 +0200, Fons Adriaensen wrote:
> > > On Sun, Apr 01, 2007 at 03:30:18PM -0400, Dave Robillard wrote:
> > > 
> > > > > But I have one app that creates 64 output ports. When this is started,
> > > > > I _first_ get a graph callback - and scanning the ports at that time
> > > > > doesn't show the new ones - followed by the port callbacks.
> > > > > So ignoring the port callbacks means you discover the new app only
> > > > > later, when it gets connected.
> > > > 
> > > > This happens even if there are connections to the new ports?  That's
> > > > definitely a bug.
> > > 
> > > No, when a connection is made to the new app there is a graph-reorder cb
> > > and then all new ports are visible.
> > > 
> > > The point is that relying only the graph-reorder cb to discover the new
> > > app will not work in this case as the this cb is made before the new ports
> > > exist. 
> > 
> > Yes, my point is that this is a bug.  The ports should definitely (IMO?)
> > be reported /before/ the graph order callback.
> > 
> > Though in any case, a single [dis]connection callback would be much
> > nicer than the current graph order situation..
> 
> how so?

The graph reorder callback means you have to search through all ports to
(Continue reading)

Permalink | Reply |
headers
Marc-Olivier Barre | 20 Apr 2007 19:32
Picon

Re: [Jackit-devel] port and connection monitoring

Dave said :
> The current callback is really only suitable for trivial clients that
> can just nuke their port/connection/client state entirely and rebuilt it
> from scratch every time.

Hold on a sec, I'm the one in charge of nuking clients here ;-)

http://home.gna.org/jacknuke/

hu hu hu
__________________
Marc-Olivier Barre,
Markinoko.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
Permalink | Reply |
headers
Fons Adriaensen | 2 Apr 2007 22:16

Re: [Jackit-devel] port and connection monitoring

On Mon, Apr 02, 2007 at 03:36:35PM -0400, Dave Robillard wrote:

> Yes, my point is that this is a bug.  The ports should definitely (IMO?)
> be reported /before/ the graph order callback.

It depends on the application. The graph_reorder cb is triggerer by
jack_activate(). If the app creates any ports after that you get the
situation I described. And it's perfectly OK to do that.

> Though in any case, a single [dis]connection callback would be much
> nicer than the current graph order situation..

Agreed.

--

-- 
FA

Follie! Follie! Delirio vano è questo !

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply |
headers
Dave Robillard | 4 Apr 2007 05:33
Picon
Picon
Favicon

Re: [Jackit-devel] port and connection monitoring

On Mon, 2007-04-02 at 22:16 +0200, Fons Adriaensen wrote:
> On Mon, Apr 02, 2007 at 03:36:35PM -0400, Dave Robillard wrote:
> 
> > Yes, my point is that this is a bug.  The ports should definitely (IMO?)
> > be reported /before/ the graph order callback.
> 
> It depends on the application. The graph_reorder cb is triggerer by
> jack_activate(). If the app creates any ports after that you get the
> situation I described. And it's perfectly OK to do that.

Yes, but any connections to those ports should trigger another graph
reorder callback; which is when the client (ie patch bay) should deal
with said connections.

Basically my point is clients should never have to deal with information
about ports they don't even "know" (via port registration callbacks)
exist yet.  If that situation is ever happening then Jack isn't
reporting things in the right order.

Anyway, I think the real point here is that "graph reorder" is a
horribly ill-defined thing at the moment

> > Though in any case, a single [dis]connection callback would be much
> > nicer than the current graph order situation..
> 
> Agreed.

How about client attach and detach notification?  (It is possible to
have Jack clients without ports, e.g. a little transport master thing.
Regardless it would be really nice to get an explicit "client gone"
(Continue reading)

Permalink | Reply |
headers
Paul Davis | 4 Apr 2007 06:55

Re: [Jackit-devel] port and connection monitoring

On Tue, 2007-04-03 at 23:33 -0400, Dave Robillard wrote:

> 
> Seems that:
> 
> - New client
> - Client removed

these seem unnecessary to me. there is no meaningful interaction with a
port-less client.

> - New port
> - Port removed
> - Connection
> - Disconnection

agreed.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply |
headers
Fons Adriaensen | 4 Apr 2007 11:03

Re: [Jackit-devel] port and connection monitoring

On Wed, Apr 04, 2007 at 12:55:14AM -0400, Paul Davis wrote:
> On Tue, 2007-04-03 at 23:33 -0400, Dave Robillard wrote:
> 
> > 
> > Seems that:
> > 
> > - New client
> > - Client removed
> 
> these seem unnecessary to me. there is no meaningful interaction with a
> port-less client.
> 
> > - New port
> > - Port removed
> > - Connection
> > - Disconnection
> 
> agreed.

But

 1. They do simplify the code of any qjackctl-like app: the client
    will exists in the local data structures when it is first referred
    to.

 2. I can easily imagine an application that would show the client
    e.g. on a canvas and allow the user to interact with it.
    The port creation could be the result of such interaction.

    There *is* potential meaningfull interaction with a port-less
(Continue reading)

Permalink | Reply |
headers
Dave Robillard | 4 Apr 2007 16:36
Picon
Picon
Favicon

Re: [Jackit-devel] port and connection monitoring

On Wed, 2007-04-04 at 11:03 +0200, Fons Adriaensen wrote:
> On Wed, Apr 04, 2007 at 12:55:14AM -0400, Paul Davis wrote:
> > On Tue, 2007-04-03 at 23:33 -0400, Dave Robillard wrote:
> > 
> > > 
> > > Seems that:
> > > 
> > > - New client
> > > - Client removed
> > 
> > these seem unnecessary to me. there is no meaningful interaction with a
> > port-less client.
> > 
> > > - New port
> > > - Port removed
> > > - Connection
> > > - Disconnection
> > 
> > agreed.
> 
> But
> 
>  1. They do simplify the code of any qjackctl-like app: the client
>     will exists in the local data structures when it is first referred
>     to.
> 
>  2. I can easily imagine an application that would show the client
>     e.g. on a canvas and allow the user to interact with it.
>     The port creation could be the result of such interaction.
>
(Continue reading)

Permalink | Reply |

Gmane