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@email-addr-hidden | (785)233-9977 |
http://ponderworthy.com <http://ponderworthy.com/>
>
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Sat Aug 30 00:15:03 2014
This archive was generated by hypermail 2.1.8 : Sat Aug 30 2014 - 00:15:03 EEST