[qjackctl-devel] Re: qjackctl start, stop, start again

[Jack O'Q. <jo...@io...>]

"Rui Nuno Capela" <rn...@rn...> writes:

> Do have any suggestion about this buffer resize work that could be of
> impact on qjackctl? For example, what's or will be the meaning of the
> return value of jack_buffer_size?
> 
> Is it specific to a client or is a global value, identical for all clients
> in one given moment? In the later case, I could show that on qjackctl's
> status page, ain't I?

Yes, the value is global to the entire JACK graph.  Since it will be
changeable it makes sense for you to display it on your Statistics (or
Status) page.  

You could do that now, if you like.  Register a callback.  If it ever
runs, it can update the value displayed.  You *could* update the
display in-line, but it would probably be better and cleaner to update
a global variable and have one of your GUI threads actually display
it.

> Back to the transport scene. It's almost ready. But my worries are
> that I can't remember how to test it. I've been trying with Ardour
> 0.9beta3 but rolling a simple session, even as transport master,
> doesn't give any valid fields from jack_transport_query's position
> (neither timecode or bbt).

Ardour doesn't support the new interface yet.  Paul said it will soon.

> Am I missing something (of course I am :) or there's a any better way to
> harness this transport thing. Can't remember if there's any example code
> from JACK tarball.

The example clients jack_transport and jack_showtime are very useful
for testing, mainly because they are small and simple.  The latest
ecasound has full support for all the new features, including
slow-sync, which is hard.  I think hydrogen has released new transport
support, but I haven't tried it yet.

> Maybe you can give me a clue, O'tranport master :D

Any time.  Clues are cheap!  :-)
-- 
  *joq