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@xxxxxxxxxxxxxxxx | (785)233-9977 | http://ponderworthy.com <http://ponderworthy.com/> > _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
