Greetings, Len, and thanks for writing. Reponses below.
I was surprised that you include X and a wm at all. I would suggest
running screen from dbus-launch could do the same thing so long as all
your applications are CLI. I have set a box up this way and been able
to
run pulseaudio, jackdbus and other things (before I ran out of memory
on
the old P300). I would not suggest pulse in your case though. There are
some very good CLI tools for keeping track of jack connections.
It is a perennial question for me, whether or not to start going CLI.
So far every time I have begun to look there, I have found yet another
tweak I want to do NOW which is very easy in GUI and rather arcane in
CLI. One of the better examples is the use of Calfjackhost, most of my
patches use a single CJH with three plugins (usually EQ, reverb, and
compression), and I haven't found a way to handle that anywhere near as
easily in CLI, and the visualizations help. Similarly I use Yoshimi a
lot, three simultaneous instances in two different patches, and although
I could run it CLI, I could not easily configure it CLI. I have also
thought about setting up two different major modes, CLI and GUI, using
the same patchset items, but it seemed to me like a lot of
time-expenditure and complexity for minimal gain; the current hardware
is not very CPU- or RAM-limited, and it does seem best to use exactly
the same setup in production as on the bench. So I mix, CLI for some
things, GUI when it's just easier. And figuring out Jack connections is
a lot easier in GUI :-) I don't keep qjackctl or one of the newer ones
running all the time, but it sure is nice to have it one click away.
It is relatively easy using sys v init, upstart or systemd to run a
shell
script as a user that would start dbus and screen (or another cli
session
manager) with a number of screens open and running some predefined
program. Ssh login to the box and type:
screen -df
will connect you to the already running screen instance running as your
user. I have done this from an android phone, though the text was
really
too small :) but a tablet would be better. If you run out of buttons on
your keyboard, USB keyboards (qwerty) are cheap and the controller
inside
can be directly connected to stomp switches. Actkbd can assign keypress
to
CLI command or with the extension I am working on (it is far enough
along
to be useful to you I think) send a jack midi command to your midi
filter/combiner or direct to an app.
I have been wondering how much capacity I'm wasting keeping the desktop
manager up. I have a good graphics card so that isn't a limiter, but
obviously there is some motherboard bandwidth being taken. It may be
that I should do something like the Archbang default, which is just
enough.
There are also a number of MIDI control apps that send MIDI via
ethernet/wireless some of them for android. qmidinet should now be able
to
run headless too.
Just a note and you may already know this, you can stack commands with
jack_control. For example I start jackdbus like this:
jack_control ds $DRIVER dps device $DEV dps rate $RATE dps period
$FRAME \
dps nperiods $PERIOD start
From a script.
Wow, I had forgotten about that, although I think I saw it in a doc once
or twice.
I understand using 96k for this project, but in the case of pops and
such
have you tried setting 48k just to see if it goes away? Then setting
period 32 would give the same latency, but may still give cleaner
sound.
You can use jack_bufsize to change period on the fly, but note that
there
will be audiable artifacts and some applications (rakarrack for
example)
never recover and need to be restarted.
--
Len Ovens
www.ovenwerks.net
Aha, did not think of reducing to 48k for just the one patch, that
should work just fine, because I have found that to keep Jack completely
stable I have to kill the process and restart between patches anyhow.
I'll have to keep that one in the bag of tricks!
Jonathan E. Brickman
Ponderworthy Music | jeb(a)ponderworthy.com | (785)233-9977 |
http://ponderworthy.com <http://ponderworthy.com/>
>