Kaeru's Online Journal

A lot of users are probably familar with GNU Screen. I often need to run and see the output of multiple terminals. For example, you may want to see log output in one screen while editing a file in another.

Previously I would do this with multiple terminals, and then later with terminator to group them all together. The problem is that if I lost connection, or switch to working on a laptop, I have to recreate the environment again.

Wouldn't it be great, if I could detach and restore terminal windows (think virtual desktops), and panes easily and continue where I left off?

Enter tmux

For the server that hosts this blog, I wanted to do some application upgrades and I wanted to see with top what the server load was. So I have a window, with portmaster running and top in side by side panes.

On the same server, also I'd like to work on some Plone stuff and would like to edit a file, while viewing some stats from varnish. Instead of opening another terminal, I create another window in tmux, call it Zope and split it into two panes again.

So now when I detach and reattach tmux on this server, I get back to my working environment where I left of with both the portupgrade and Zope window setup as they were. You can do a lot more with tmux then just this of course, but this is the main reason for me to switch to it from GNU Screen.

A good intro can be found in a two part blog post at Hawk Host

The digital audio/music world is totally new to me, so I'm starting from basics and taking one baby step at a time. So I'm starting with the most basic setup with Jack first.

Line-out output from a synth keybaoard to line-in of my sound card. At this stage, you can't hear anything, until that line-in connection is plugged into a recording app and played back, much like what you do with standard desktop setup with pulseaudio. Unless the synth has speakers (most high-end ones don't), or another line-out is connected to a set of speakers, you're not going to know what's being recorded until it's played back.

To do this, you want to be able to monitor (hear) the input, by connecting it to some output. In this case, the line-out of my sound card (playback). You also want this to be in real time.

Jack provides the features to do this.

This sounds overly complicated to hear something, but there are a couple of things in play here.

• Keyboard synth being pressed, sends a signal to it's tone generator
• Tone generator converts it into audio signal, which is sent to line-out
• Line-out audio into line-in of sound card, which converts it into digital signal (Analog to Digital Converter)
• Digital signal gets converted and amplified into audio signal (Digital to Audio Converter) in sound card.

In future, all these things may be interchanged with other applications and devices. For example, the keyboard press will generate MIDI output, that will go to a software synth on the PC to generate a digital audio signal, which then goes to an effects processor before going into a recording app. Alternatively, a midi sequencer such as Rosegarden may be sending MIDI output to the synth keyboard to generate sounds.

Before it get's all complicated, let's get the basic connection working first.

Startup Jack Audio Control (qjackctl)

Jack Control will nicely suspend pulseaudio automatically first.

Once it's started, clicking on the Connect button will show under Audio tab, system (my Xonar sound card), and capture_1 and capture_2 (left and right, line-in) as an Output Port and system playback_1 and playback_2 as line-out left and right of the sound card.

You highlight it and click connect. You can of course do cross-overs or merge.

These connections are not saved, and system, capture_1 etc are not exactly intuitive names. As the setup gets more complicated, we're going to need to use the Patchbay, which you can access by clicking on the button.

With Patchbay, you can have aliase's for the devices so it makes more sense, and also be able to save and activate different setups.

Next I'll be learning on how to add basic MIDI support.

You can get a lot of what you need to do in Plone, simply using the built-in content management tools and web configuration options. This is why I like Plone, it empowers users who know more about the content, to organize and manage their own sites.

A case for example, in which a user would like to have a calendar of all events for their office, on a specific theme, with Plone does not require a technical person to accomplish.

For development, with Archgenxml combined with the content management features above, again, you don't really need much development skills to get what you need done (video).

As we FOSS developers know however, is that you need to develop the features that make it simple for users and that involves writing code, going through code from others and debugging.

Kagesenshi showed me how to debug with Zope debug shell. Unfortunately the shell is kinda painful with no auto completion or history. iPython is much nicer to use.

Luckily it's rather easy now using buildout

[ipzope]

# a IPython Shell for interactive use with zope running.
# you also need to put
# https://svn.plone.org/svn/collective/dotipython/trunk/ipy_profile_zope.py
# to your $HOME/.ipython directory for the following to work.

recipe = zc.recipe.egg
eggs =
                ipython
                ${instance1:eggs}
initialization =
                import sys, os
                os.environ["SOFTWARE_HOME"] = "${zope2:location}/lib/python"
                os.environ["INSTANCE_HOME"] = "${instance1:location}"
                sys.argv[1:1] = "-p zope".split()
extra-paths = ${zope2:location}/lib/python
scripts = ipython=ipzope

Follow the instructions in the comment, run buildout, and you've got yourself an ipzope script that will start up Zope debug with ipython shell with app bound to your Zope root instance already.

Thanks to the Seattle Plone Gathering for sharing the example. Lots of other useful buildout examples on that link too.