QjackCtl

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

> > Have you thought about adding transport control buttons?  With the new
> > interfaces this is easy to do.  The jack_transport_start(), _stop()
> > and _query() functions can be called directly from GUI threads.

> Hmm, IIRC you were the one who kindly wrote some documention about this
> transport stuff, am I right? Can you point me to the latest version of
> that?

Yes, I wrote the documention, along with everything else.  :-)

The docs are included in the JACK reference manual, so it's on your
system.  If you have doxygen installed, look in...

 $PREFIX/share/jack-audio-connection-kit/reference/html/

$PREFIX is normally `/usr/local' unless you override it during the
JACK ./configure step.

If you don't have doxygen, the manual doesn't get built.  I see Antti
still hasn't updated the copy on the JACK web page.  But, there's
still a copy on my system you can look at: <www.joq.us/jack/refman>.

> What are your suggestions for the GUI? A couple of start/stop
> buttons and a status display? 

Yes, that sounds right.  Anything more would be appropriate for a
specific transport control client.  For status display, the transport
state and perhaps optionally the frame time in HH:MM:SS:DD format
could be useful.  Alternatively, you could display Bar, Beat, Time
information, but only if it's available.

There's code in JAMin CVS for this <http://jamin.sourceforge.net>.  It
supports both the old and new transport interfaces, which makes it a
lot more complex.  But, doing just the new stuff is easy.

Most of what you need is in these two relatively small source files...

  src/transport.c
  src/status_ui.c

I recommend compiling the transport control conditionally based on the
existence of jack_transport_query() in libjack.  That way, your code
still works with older versions of JACK, but with no transport
control.  There's code in JAMin `configure.in' for that, too.

> Regarding the transport clients relationship what should be the
> options for qjackctl taking the master role or just a watcher?

There's no reason for qjackctl to be a timebase master.  That is now
only required for generating extended time information, which you have
no reason to do.

Any JACK client can start and stop the transport.  No special
privilege is required.  It can be done from any thread.  I can't think
of any reason for you not to make those requests if the user presses
the appropriate buttons.  Since qjackctl is generally visible on the
user's display (or KDE panel), it seems like a convenient place to put
them.

Regards,
-- 
  *joq

Hi Jack,
>
> If you don't have doxygen, the manual doesn't get built.  I see Antti
> still hasn't updated the copy on the JACK web page.  But, there's
> still a copy on my system you can look at: <www.joq.us/jack/refman>.
>

No doxygen, gotta hit your site :)

>
> Yes, that sounds right.  Anything more would be appropriate for a
> specific transport control client.  For status display, the transport
> state and perhaps optionally the frame time in HH:MM:SS:DD format
> could be useful.  Alternatively, you could display Bar, Beat, Time
> information, but only if it's available.
>
> There's code in JAMin CVS for this <http://jamin.sourceforge.net>.  It
> supports both the old and new transport interfaces, which makes it a
> lot more complex.  But, doing just the new stuff is easy.
>
> Most of what you need is in these two relatively small source files...
>
>   src/transport.c
>   src/status_ui.c
>

By looking into those files, JAMin doesn't seem to have Bar:Beat:Time
display, or have I missed it close? But anyway, that's a minor.

>
> I recommend compiling the transport control conditionally based on the
> existence of jack_transport_query() in libjack.  That way, your code
> still works with older versions of JACK, but with no transport
> control.  There's code in JAMin `configure.in' for that, too.
>

I guess I can do it too, very easily. OTOH Isn't there any way to get the
JACK's version from some header file at compile time? Guess it should be
some #define ... like this example for 0.82.3:

    #define JACK_VERSION 0x008203

>
> There's no reason for qjackctl to be a timebase master.  That is now
> only required for generating extended time information, which you have
> no reason to do.
>
> Any JACK client can start and stop the transport.  No special
> privilege is required.  It can be done from any thread.  I can't think
> of any reason for you not to make those requests if the user presses
> the appropriate buttons.  Since qjackctl is generally visible on the
> user's display (or KDE panel), it seems like a convenient place to put
> them.
>

Fair enough.

I'll try to put this transport gadgets on qjackctl very soon. My doubts
lie in where in the GUI? That is, without disrupting a lot the layout
already there. The first place where I can think of putting the transport
buttons and state display is under the Statistics tab (which sould be
renamed to Status tab :)

A complete GUI redesign should be needed nevertheless, and that will be
for qjackctl 0.1.x release branch, in near future. Any suggestions will be
welcome, of course.

Bye.
-- 
rncbc aka Rui Nuno Capela
rncbc@...

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

> By looking into those files, JAMin doesn't seem to have Bar:Beat:Time
> display, or have I missed it close? But anyway, that's a minor.

No, I haven't gotten around to that yet.  I decided to wait a while,
then drop the old transport support, before getting into that.  It's
not that important for JAMin.

But, I think pretty much everything else we've discussed is there,
along with a bunch of irrelevant features.

> > I recommend compiling the transport control conditionally based on the
> > existence of jack_transport_query() in libjack.  That way, your code
> > still works with older versions of JACK, but with no transport
> > control.  There's code in JAMin `configure.in' for that, too.
> >
> 
> I guess I can do it too, very easily. OTOH Isn't there any way to get the
> JACK's version from some header file at compile time? Guess it should be
> some #define ... like this example for 0.82.3:
> 
>     #define JACK_VERSION 0x008203

Not a bad idea, but I don't think it exists.  You can check the JACK
version easily enough with autoconf, just use a different macro.  You
can then define your own <config.h> variables based on what you find.

> I'll try to put this transport gadgets on qjackctl very soon. My
> doubts lie in where in the GUI? That is, without disrupting a lot
> the layout already there. The first place where I can think of
> putting the transport buttons and state display is under the
> Statistics tab (which sould be renamed to Status tab :)
> 
> A complete GUI redesign should be needed nevertheless, and that will
> be for qjackctl 0.1.x release branch, in near future. Any
> suggestions will be welcome, of course.

I think you have a better feel for that stuff than I do.  I'm mostly a
left-brain kind of guy.  That is why I've spent most of my life doing
low-level services and not user interfaces.
-- 
  *joq

Jack,

>> some #define ... like this example for 0.82.3:
>>
>>     #define JACK_VERSION 0x008203
>
> Not a bad idea, but I don't think it exists.  You can check the JACK
> version easily enough with autoconf, just use a different macro.  You
> can then define your own <config.h> variables based on what you find.
>

Yep. Think that

    AC_CHECK_LIB(jack, jack_transport_query, ...)

will be all that I need for conditional compilation. Thanks.

>>
>> A complete GUI redesign should be needed nevertheless, and that will
>> be for qjackctl 0.1.x release branch, in near future. Any
>> suggestions will be welcome, of course.
>
> I think you have a better feel for that stuff than I do.  I'm mostly a
> left-brain kind of guy.  That is why I've spent most of my life doing
> low-level services and not user interfaces.

I'm not that right-minded also ;) so I'll stick with that bloating idea
for now, that's putting transport control and state on the
soon-to-be-renamed Statistics tab.

Hope it's fine with you and others, for the time beeing.

Bye.
-- 
rncbc aka Rui Nuno Capela
rncbc@...

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

> I'm not that right-minded also ;) so I'll stick with that bloating idea
> for now, that's putting transport control and state on the
> soon-to-be-renamed Statistics tab.
> 
> Hope it's fine with you and others, for the time beeing.

Sounds good.  It's often hard to tell with UI stuff until you have a
running prototype to play around with.
-- 
  *joq

> Jack O'Quin wrote:
>
> On my system, every time I try to restart JACK after stopping it,
> qjackctl hangs.  This seems to happen whether I use the `killall'
> startup option or not.  I have to kill qjackctl and restart it.
>
> Does anything like this happen for you?

In fact yes, strangely but only on my SuSE 8.1 machine, exactly as you
report. On Mandrake 9.1 and RedHat 9 Planet CCRMA boxes that don't happen
at all. All boxes are running the very same kernel compiled and patched
from source. Even on my laptop it run's fine (Mandrake), although audio
hardware is pure crap.

I've been worried about this too, since very early, but didn't find
anything that could lead to a cure. As my SuSE installation is the older
and most trashed of them all (is my lab :) I thought it was an insolated
problem of mine. Guess I was wrong :(

May the difference lie in between libc and/or libqt?

After my recent debian adventure (a failure ;) I'm trying to get into
gentoo, but you know what, I'm still emerging it :)

If you get the time for helping me debugging this issue I would appreciate
very much. I'm affraid not being proficient about gdb myself, are you?

Thankfully,
-- 
rncbc aka Rui Nuno Capela
rncbc@...

P.S. To build for debugging, you may try changing the qjackctl.pro file,
on the CONFIG entry replace 'release' by 'debug' and rebuild (make clean;
make).

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

> If you get the time for helping me debugging this issue I would
> appreciate very much. I'm affraid not being proficient about gdb
> myself, are you?

I can use it, but I don't consider myself particularly "proficient" at
it.  It's tricky to use gdb with JACK applications because of
multithreading and timeouts.  The -t option of jackd is helpful.  I
generally end up debugging the "old fashion" way, with printf().

I'll take a look at it when I have time.  Right now, I'm busy with the
buffer resizing work.  That project seems to have far too may
distractions built into it, already.  :-)

You might find it worthwhile to ask on the jackit-devel list.  If
others are seeing it, maybe there's some pattern to the failure.  It
would be interesting to know what OS, what QT, and what JACK they run.

Regards,
-- 
  *joq

Hi again,

>
> I'll take a look at it when I have time.  Right now, I'm busy with the
> buffer resizing work.  That project seems to have far too may
> distractions built into it, already.  :-)
>

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?

Sorry to bother you with so many (probably basic) questions.

>
> You might find it worthwhile to ask on the jackit-devel list.  If
> others are seeing it, maybe there's some pattern to the failure.  It
> would be interesting to know what OS, what QT, and what JACK they run.
>

Yep, I'll end do it sometime.


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

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.

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

Bye.
-- 
rncbc aka Rui Nuno Capela
rncbc@...

"Rui Nuno Capela" <rncbc@...> 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

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

Made it to CVS already. Exactly as you suggest. Many thanks.


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

OK. That explains it.


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

Seems all right with jack_transport. Gotta check it out with
jack_showtime,... yesss. Now for a real and practical app, ecasound...
oops, don't have it installed anywhere. It will have to wait, someday :)

Think it's ready, anyway.

Thanks again.
-- 
rncbc aka Rui Nuno Capela
rncbc@...