Hi all,
The build of qjackctl included with jackdmp for windows is getting really
old.
The biggest problem is that the default "startup time" is set too low,
making it
seem like "jack crashes". (I"ve got many complains that "jack crashes").
Another problem is that you manually have to append "-S" to the "Server
Prefix".
So here:
https://github.com/kmatheussen/qjackctl
...I've cloned the official qjackctl repository, fixed these two problems,
and added some files to make it straight forward to build qjackctl under
mingw32.
(Building is just running the "build_mingw32.sh" script)
Windows binary: http://folk.uio.no/~ksvalast/qjackctl.zip
Perhaps this build, or something similar, can be included in the next
release of jack for windows?
Hey,
I was wondering, seeing as the latest distributed compiled package (on http://jackaudio.org/downloads/) for osx is version 0.90, and it is stated as beeing for Snow Leopard ; was wondering if i should try to compile it myself from the 1.9.10 tarball (or even the git repos ?) ; because i'm not very knowledgeable in coding so i'm afraid i have no idea how to compile it. Opening the xcode project in the git repo, then trying to compile it ; leads very fast to a critical " 'aften/aften.h' file not found" error ; and i don't see a "aften" file in the distribution.
In short, i do'nt know how stable is the 1.9.10 or Github version, but i'm not sure it is very wise either to use the maybe outdated 0.9 ? but for now, i don't know how i could do else...
Thanks in advance,
Victor
Hi there,
I am wanting to run jackd on low resourced/power embedded systems
(running Linux).
When I run jackd on these systems it tries to lock down way to much
memory ... much more then is available.
Is the amount of memory locked down by jackd configurable ? Or is it an
operating system set thing ?
Does anyone have any constructive ideas or suggestions for running jackd
on these low resource embedded systems ?
thanks
Matt
Hi all,
as in through the hottest of summers--as southerners can't even
wait--here comes part one:
QjackCtl 0.4.0 (summer'15) is out!
though aside that everybody knows this already,
QjackCtl is a (maybe not so any more but) simple Qt [3] application
to control the JACK [2] sound server, for the Linux Audio infrastructure.
website:
http://qjackctl.sourceforge.net
downloads:
http://sourceforge.net/projects/qjackctl/files
- source tarball:
http://download.sourceforge.net/qjackctl/qjackctl-0.4.0.tar.gz
- source package:
http://download.sourceforge.net/qjackctl/qjackctl-0.4.0-23.rncbc.suse132.sr…
- binary packages:
http://download.sourceforge.net/qjackctl/qjackctl-0.4.0-23.rncbc.suse132.i5…http://download.sourceforge.net/qjackctl/qjackctl-0.4.0-23.rncbc.suse132.x8…
Change-log:
- Some windows fixes added (patch by Kjetil Matheussen, thanks).
- Most advanced Setup/Settings are moved into new Setup/Advanced
settings tab; limit range for the real-time priority setting, now having
6 as absolute minimum valid value (after patches by Robin Gareus, thanks).
- A new top-level widget window geometry state save and restore
sub-routine is now in effect (EXPERIMENTAL)
- Delayed geometry setup for widget windows upon startup has been
deprecated and scrapped altogether.
- Setup/settings dialog tab is going into some layout changes; also got
rid of old patchbay auto-refresh timer cruft, which was previously
hidden/disabled.
- New socket names are now automatically inferred from selected client
names while on the Patchbay widget, Socket dialog.
- Fixed for some strict tests for Qt4 vs. Qt5 configure builds.
- German (de) translation update (by Guido Scholz, thanks).
License:
QjackCtl stands free, still open-source software, distributed under
the terms of the GNU General Public License (GPL [4]) version 2 or later.
Weblog (upstream support):
http://www.rncbc.org
See also:
http://www.rncbc.org/drupal/node/912
References:
[1] QjackCtl - A JACK Audio Connection Kit Qt GUI Interface
http://qjackctl.sourceforge.net
[2] JACK Audio Connection Kit
http://jackaudio.org
[3] Qt framework, C++ class library and tools for
cross-platform application and UI development
http://qt.io/
[4] GPL - GNU General Public License
http://www.gnu.org/copyleft/gpl.html
Enjoy && have a whole hot'ta Summer'15 fun!
--
rncbc aka. Rui Nuno Capela
--
rncbc aka. Rui Nuno Capela
I send a patch once on this list and this is a "patched" version.
I keep this, because it was very helpfull while testing and improve other apps ( like hydrogen , fsthost ), especially tempo change issues. Not perfect but better than "official", especially in low tempos ( like 30 BPM ).
.. so yes you are inconvincible ;-)
P.
Dnia Czwartek, 2 Lipca 2015 20:17 Paul Davis <paul(a)linuxaudiosystems.com> napisał(a)
> Was this the stuff you tried (unsuccessfully) to convince me need to
> go into the tools repo?
>
> On Thu, Jul 2, 2015 at 1:12 PM, Pawel <xj(a)wp.pl> wrote:
> > Hi,
> >
> > Tobias, you can check my slightly improved version of jack_transport:
> > https://sourceforge.net/p/nxjsm/code/HEAD/tree/trunk/tools/transport.c
> >
> > I'm also the author of new Hydrogen jack-master code. It's works much better , but probably not perfect ;-)
> >
> > P.
> >
> > Dnia Czwartek, 2 Lipca 2015 18:57 Paul Davis <paul(a)linuxaudiosystems.com> napisał(a)
> >> Frankly, computing BBT time has never been part of "how to use the
> >> JACK API". It should probably never have been included in the source
> >> code in the first place.
> >>
> >> Managing BBT time is *extremely* complex - we have worked on it for
> >> years in Ardour and it still has issues. I'd prefer to just rip it
> >> out.
> >>
> >> On Thu, Jul 2, 2015 at 12:47 PM, Tobias Hoffmann
> >> <lfile-list(a)thax.hardliners.org> wrote:
> >> > On 02/07/15 17:30, Tobias Hoffmann wrote:
> >> >>
> >> >> On 02/07/15 15:38, Paul Davis wrote:
> >> >>>
> >> >>> jack_transport is not intended to act as a the time master.
> >> >>
> >> >> Well, comparing example-clients/transport_client.c and tools/transport.c,
> >> >> I'd say the one big difference between the two is that tools/transport.c
> >> >> (aka jack_transport) can act as a *simple* timebase master...
> >> >
> >> >
> >> > Ok, I see now that the BBT update algorithm (in the "else" branch in
> >> > timebase()) in transport.c is quite broken, because it accumulates rounding
> >> > errors. However always using the first, recalculating branch (basically: if
> >> > (true)) seems to be stable -- or at least: better than Hydrogen's timebase
> >> > master, which updates the BBT only every few cycles... (I've read that
> >> > somewhere a completely rewritten Jack Master implementation for Hydrogen is
> >> > available, which I have not tested yet).
> >> >
> >> > I find it quite sad that even some code distributed in the jack tarball is
> >> > an example of how NOT to use the Jack API ...
> >> >
> >> > Tobias
> >> >
> >> >
> >> >
> >> >
> >> >
> >> _______________________________________________
> >> Jack-Devel mailing list
> >> Jack-Devel(a)lists.jackaudio.org
> >> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
> >
> >
> >
> > _______________________________________________
> > Jack-Devel mailing list
> > Jack-Devel(a)lists.jackaudio.org
> > http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Hi,
Tobias, you can check my slightly improved version of jack_transport:
https://sourceforge.net/p/nxjsm/code/HEAD/tree/trunk/tools/transport.c
I'm also the author of new Hydrogen jack-master code. It's works much better , but probably not perfect ;-)
P.
Dnia Czwartek, 2 Lipca 2015 18:57 Paul Davis <paul(a)linuxaudiosystems.com> napisał(a)
> Frankly, computing BBT time has never been part of "how to use the
> JACK API". It should probably never have been included in the source
> code in the first place.
>
> Managing BBT time is *extremely* complex - we have worked on it for
> years in Ardour and it still has issues. I'd prefer to just rip it
> out.
>
> On Thu, Jul 2, 2015 at 12:47 PM, Tobias Hoffmann
> <lfile-list(a)thax.hardliners.org> wrote:
> > On 02/07/15 17:30, Tobias Hoffmann wrote:
> >>
> >> On 02/07/15 15:38, Paul Davis wrote:
> >>>
> >>> jack_transport is not intended to act as a the time master.
> >>
> >> Well, comparing example-clients/transport_client.c and tools/transport.c,
> >> I'd say the one big difference between the two is that tools/transport.c
> >> (aka jack_transport) can act as a *simple* timebase master...
> >
> >
> > Ok, I see now that the BBT update algorithm (in the "else" branch in
> > timebase()) in transport.c is quite broken, because it accumulates rounding
> > errors. However always using the first, recalculating branch (basically: if
> > (true)) seems to be stable -- or at least: better than Hydrogen's timebase
> > master, which updates the BBT only every few cycles... (I've read that
> > somewhere a completely rewritten Jack Master implementation for Hydrogen is
> > available, which I have not tested yet).
> >
> > I find it quite sad that even some code distributed in the jack tarball is
> > an example of how NOT to use the Jack API ...
> >
> > Tobias
> >
> >
> >
> >
> >
> _______________________________________________
> Jack-Devel mailing list
> Jack-Devel(a)lists.jackaudio.org
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Hi,
I'm still using debian's jackd1/libjack0 package (0.124.1) and have not
tried to reproduce this with git master yet (at least, I haven't seen an
obvious fix in the commit log since 0.124.1).
In one terminal window I run jack_showtime.
In the other window I do:
jack_transport
> tempo 96 # just in case
> master
> play # does not
jack_showtime correctly shows the state, but no BBT information. From my
own client I know that jack_position_t::valid==0.
Some testing revealed that the timebase() callback in tools/transport.c
is *not called at all*, although jack_set_timebase_callback is called
and returns without error.
- But everything works fine when I switch to the jack2 stack...
And in some cases, when switching between/enabling/disabling different
Transport masters,
jack_position_t::valid retains the JackPositionBBT flag (and stale
information) -- but no-one updates them any more...
Maybe related: I've seen some strange values (*very* large negative
number) for bar_start_tick when using ardour4.1.
The very first time (and after rewind?) it contains 0.0 and is not
updated. A quick glance into the ardour source code reveals that this
field is not implemented yet. I could probably live with that.
BUT: After stopping+starting the playback, these strange values
appear... How can I know whether some value in this field is usable at
all -- except for some heuristics?
Back to the original topic... in both cases the jack_position_t struct
contains stale/random values, instead of starting from a "clean" base --
maybe memset(,0,) is all that is needed here?
Tobias