Results tagged “tutorial”

In this post I will describe the method for creating musical scores in Lilypond which incorporate a cover page and performance/technical notes at the start of a score. Let’s assume that the performance notes are pretty complicated and include a few musical examples from the score, some stage layout diagrams and a few examples of Pure Data patches from the live electronics part. To make things a little more interesting, we’ll insist that all graphics and score end up as scalable PDF for professional-quality print.

The approach we are going to take is to create the score and front pages as two separate PDF documents and join them together at the end. Let’s assume that the PDF for the actual Lilypond score is complete, and give that no further thought.

Latex template

The first thing we need to do is make the Latex document that will contain our performance notes, score excerpts diagrams etc. Let’s call this document preliminaries-book.lytex.

Firstly to get the book with a nice front cover, we need to use the document class ‘book’:

\documentclass[a4paper, landscape, twocolumn, 12pt]{book}

I use a two-column, a4 landscape layout with 12pt font size, but this can be customised.

Select the ‘graphicx’ package for including our PDFs:

\usepackage{graphicx}

Next we can optionally change the default typeface:

%% Use lmodern font
\usepackage[T1]{fontenc}
\usepackage{lmodern}
\renewcommand*\familydefault{\sfdefault}

We also want to suppress the automatic page numbering, because we want our numbering to start on the first page of the score proper:

%% Suppress page numbering
\usepackage{nopageno}

Now begin the document and make the title:

\begin{document}

\author{My Name}
\title{My Piece \\
    {\large {for \\ \textbf {Piano and Live Electronics}}}}
\date{2008}

\maketitle

\section* {Live electronics setup}

Notice that we use section* to suppress section numbering.

The rest of the document is standard LaTeX except for the Lilypond snippet (see below), and won’t be described any further.

Making the diagrams

Now let’s assume that we have some introductory text interspersed with four diagrams:

• A logical connection diagram for the live electronics made in dia
• A ‘screenshot’ of the Pd patch
• A physical layout diagram showing the Piano, microphone and stage positions made in Inkscape
• A short excerpt from the score

We are going to be using pdflatex to render our ‘.tex’ file, so we want all of our diagrams in PDF format. We also want them all to be scalable - not PNG, JPEG etc. We will be including each diagram as follows:

\begin{figure}
    \centering
    \includegraphics[scale=0.4]{pd_patch.pdf}
    \caption{PD patch}
    \label{fig:pd_patch}
\end{figure}

We will then reference the figures in the text as follows:

blah blah is in figure~\ref{fig:pd_patch}

Dia diagram

We can save our working Dia diagram in ‘.dia’ format, and do the necessary conversion to PDF in the build script. This way any changes to the diagram will automatically be incorporated into the score book when the script is run.

We convert from ‘.dia’ to PDF in two steps:

dia -t eps-pango -e diagram1.eps diagram1.dia

Then:

epstopdf diagram1.eps --outfile=diagram1.pdf

This requires the `epstopdf’ tool to be installed. There are other ways to convert epstopdf, but this method was found to give the best results.

Converting the PD patch to PDF

Any Pure Data patch can be ‘printed’ to Postscript, simply by selecting the ‘print’ option from Pd’s ‘file’ menu. However, it is often more convenient to script the process so that changes to the Pd patch are automatically incorporated into the final score when the build script is run.

Assuming that we have a Pd patch called ‘MAIN_PATCH.pd’ in a subdirectory called ‘pd-patches’, we can use this script along with this helper patch to print the patch to Postscript (note: this script was originally devised by Andy Farnell and Frank Barknecht - see this thread):

pdprint3.sh pd-patches/

This should give us a file called MAIN_Patch.pd.ps in the pd-patches subdirectory. This can now be converted to PDF using the command `ps2pdf’, however better results were achieved by using an intermediate SVG stage as follows:

pstoedit -f plot-svg pd-patches/MAIN_PATCH.pd.svg --export-pdf=MAIN_PATCH.pdf
inkscape MAIN_PATCH.pd.svg --export-pdf=MAIN_PATCH.pdf

Converting the Inkscape diagram to PDF

This is the easiest step since Inkscape natively exports PDF, and conveniently makes this functionality available via the command line:

inkscape diagram2.svg --export-pdf=diagram.pdf

Incorporating score fragments

If we preprocess the document with `lilypond-book’, score fragments can be incorporated into the LaTeX code e.g.:

Acciaccaturas are to be played quickly and on the beat.
\begin [quote,fragment,staffsize=16]{lilypond}
    \acciaccatura f'16 b'2
\end {lilypond}
Should be played:
\begin [fragment,staffsize=16]{lilypond}
    \stemUp f'32 b'8.. ~ b'4
\end {lilypond}

Putting it all together

First we convert our ‘.lytex’ file to standard LaTeX:

lilypond-book --pdf -o preliminaries-book preliminaries-book.lytex

Now render with pdflatex. Note: we can’t use latex, dvips etc because our diagrams are in PDF format.

cd preliminaries-book
pdflatex preliminaries-book.tex

Finally we join the rendered PDF to the actual score using ghostscript:

cd .. gs -dBATCH -dNOPAUSE -q -sDEVICE=pdfwrite -sOutputFile=finished.pdf preliminaries-book/preliminaries-book.pdf ../score.pdf

Replacing `score.pdf’ with the name of the lilypond score as appropriate.

…and finally:

evince finished.pdf

:-)

The Old Screenlets updated bundle available from here, contains a number of very useful screenlets including a calculator and a conversion utility. However, some of these screenlets won’t work correctly with recent versions of screenlets because event handling has been changed (improved). Below are some simple patches to get Calc and Convert working properly with Screenlets >=0.0.10-3.

Calc

46d45
<       self.window.connect("key-press-event", self.key_press)
417c416
<   def key_press(self, widget, event):
---
>   def on_key_down(self, code, key, event):
419,422c418
<       
<       key = gtk.gdk.keyval_name (event.keyval)
<       KPCONVERT = {'KP_Add': 'plus', 'KP_Subtract': 'minus', 'KP_Multiply': 'asterisk',
<                       'KP_Divide': 'slash', 'KP_Enter': 'Return'}
---
>       KPCONVERT = {'+': 'plus', '-': 'minus', '*': 'asterisk', '/': 'slash', '\r': 'Return'}

Convert

73,74d72
<       # connect additional event handlers
<       self.window.connect('key-press-event', self.key_press)
110c108
<   def key_press(self, widget, event):
---
>   def on_key_down(self, code, key, event):
112c110
<       if self.__converter.on_key_press(gtk.gdk.keyval_name(event.keyval)):
---
>       if self.__converter.on_key_press(key):

Applying the patches

1. Ensure that you have the patch utility installed
2. Copy the the diff data under the Calc heading above into a file called Calc.diff
3. Copy the data under the Convert heading to a file called Convert.diff
4. Copy Calc.diff to the directory containing CalcScreenlet.py, e.g. /usr/local/share/screenlets/Calc
5. Copy Convert.diff to the directory containing ConvertScreenlet.py
6. In the Calc/ directory type patch CalcScreenlet.py Calc.diff.
7. In the Convert/ directory type patch ConvertScreenlet.py Convert.diff.

What this fixes

This fixes a bug where for each keypress, the application receives and prints two characters, i.e. if you press the ‘0’ key ‘00’ will displayed.

I have recently been working on an object-oriented wrapper for the Python bindings to my [libxtract][1] feature extraction library. I used SWIG to auto-generate the bindings, and SWIG generally does a great job. The problem is that the functions it generates follow the original C code quite precisely, and aren’t very ‘Pythonic’. I wanted to create a nice Python class to hide some of the nastiness of the auto-generated functions, but became slightly daunted by having to hand-code every method of the new Xtract class with 50 very similar methods! Instead I decided to take advantage of Python’s support for [lexical closures][2] to auto-generate the methods from the libxtract function descriptors using a method factory. The concept works like this (I think this is a fairly common idiom in Python):

#!/usr/bin/python

class foo:
    '''Dummy class'''
    def __init__(self):
        for y in range(3):
            doc = "Returns the sum of a number and %.2f" % y
            name = 'add%d' % y
            adder = self.adder_factory(y)
            setattr(self, name, adder)
            # Set the docstring
            self.__dict__[name].__doc__ = doc

    @staticmethod
    def adder_factory(y):
        "Method for generating adder functions using a lexical closure"
        def adder(x):
            return x + y
        return adder

a = foo()
x = 3

print a.add0(x) # prints 3
print a.add1(x) # prints 4
print a.add2(x) # prints 5

I’m sure there are a number of ways to change a directory of files to lowercase including the mmv utility for ‘wildcard’ renaming and copying. However, this simple one-liner is likely to work on a wider range of systems without installing additional programs since it only requires bash and tr:

for file in `ls`; do mv -i $file `echo $file | tr '[A-Z]' '[a-z]'`; done;

This will match any lowercase character in a filename in the current directory and convert it to lowercase. We can convert the other way by changing the arguments to tr. Variants can be created by filtering the results from ls, or changing the regular expression strings for tr. For example, to change the first letter of every directory in the current directory to upper case do:

for file in `ls -l | grep ^d | awk '{print $8}'`;
do mv -i $file `echo ${file:0:1} | tr '[a-z]' '[A-Z]'`${file:1}; done;

Merry Christmas!

Using a SWIG-generated interface it’s straightforward to assign variables of type char * from a Python script to a C variable: the char * datatype is assumed to be a NULL terminated ASCII string and mapped accordingly. The situation is a little different for variables of type char **, commonly used for arrays of pointers to strings.

The SWIG documentation has a very useful typedef for converting a Python list to a char **. However, I found that it was fine for passing in lists of strings as arguments to functions, but not for simple variable assignments. For example I found that the following example didn’t work:

my_charpp = ["foo", "bar"]

…where my_charpp is declared in C as having type char **. After some experimentation with the typemap and a wrapper function, I found that I could achieve what I wanted by modifying the typemap, to only work on a named pointer, and providing a helper function to do the assignment.

Typemaps:

%typemap(in) (char **pylist){
    ...
}

%typemap(freearg) char **pylist {
    ...
}

Helper functions:

%inline %{

    char **set_list(char **pylist){

         int i = 0;
         char **l;
         int temp = 0;

        while(pylist[i] != NULL)
            i++;

        l = ntg_malloc(i * sizeof(char *));

        while(i--){
            temp = strlen(pylist[i]);
            l[i] = ntg_malloc((temp + 1) * sizeof(char));
            strcpy(l[i], pylist[i]);
        }

            return l;
    }


    void print_list(char **mlist, int n_items){

        while(n_items--)
            printf("%s\n", mlist[n_items]);

    }
%}

So from my Python script, I can do the following:

mylist = ["foo", "bar"]

my_charpp = set_list(mylist)

print_list(my_charpp, 2)

…and it works like a charm! Don’t forget that if you are going to use this code, you need to ‘manually’ free the out-of-place memory allocated by set_list().

1. Install Ubuntu 7.10 (Gutsy)
2. Enable [Compiz Fusion][1], by right clicking the Desktop, selecting Change Desktop Background->Visual Effects->Extra
3. Install the CompizConfig Settings Manager and customise to taste
4. Add a pinch of [screenlets][2] following the [instructions][4] in the screenlets FAQ
5. Setup screenlets to taste under System->Preferences->Screenlets
6. Stir into Compiz Fusion, by enabling widget layer in CCSM, and enabling Treat as widget under each screenlet’s options (right-click the screenlet to access)
7. Add a dash of [Avant Window Navigator][3] following the instructions [here][5]
8. Season with the [Ubuntu studio theme][6]

…leave to cool, and serve on a bed of Python snippets!

If you are a GNU/Linux user, and you have been working with a Mac user or Mac software, the chances are that you have received files in RTF format. This is because it’s the default format of the standard Mac ‘text’ editor: TextEdit. I have nothing against RTF as a format, it just annoys me when it is used for plain text documents that don’t have (or need) any formatting.

There are a number of ways to deal with RTF on your GNU/Linux system, you could open the document in a word processor such as OpenOffice writer, or AbiWord, or use the RTF editor Ted. However, if the document has no special formatting information in it or you don’t care about the formatting, you probably want to remove the RTF markup.

UnRTF

UnRTF an aptly-named GNU command-line application that will convert RTF files to a variety of useful output formats. These include HTML, plain text, text with VT100 codes, LaTeX, and PostScript. All but HTML are currently flagged as alpha, however for simple documents I have found them to be fine. To run UnRTF, you need to issue the following command from a shell prompt:

unrtf --text mydoc.rtf > mydoc.txt

This will convert the RTF file mydoc.rtf to plain text format. For complex documents one might wish to use HTML as a transitional format, and then make use of other tools. For example [htmldoc][5] could be used to convert to pdf:

unrtf mydoc.rtf |  htmldoc --webpage -f mydoc.pdf -

And maybe you could even use the wonderful [ImageMagick][6] convert utility to rasterize the data:

convert -density 196 mydoc.pdf mydoc.png

I’m not sure what the purpose of that would be, but I thought I’d throw it in for fun!

Despite the availability of check-as-you-type spellcheckers (even for vim, which I use for all text editing), I still prefer to write a document and spell check it afterwards. There are several reasons for this. The first is that when I am writing a document, I don’t want the flow of my writing, and my concentration broken every time I make a typing error. The second is that I use my editor for a variety of tasks including writing ‘normal’ documents, writing code in a variety of languages, and writing documents that contain code and a lot of technical acronyms. I don’t want the visual noise of seeing a lot of ‘mis-spellings’ that I want to ignore, or to have to keep training the spell checker to ignore them.

I therefore tend to write a document, and then spell check it afterwards. Aspell is perfect for this, it supports a variety of (spoken) languages and document encodings and run-together words. Most importantly, it supports a range of filters, which filter reserved words in specific documents so that they don’t get checked. Modes I often use are --mode=tex (filter latex keywords) --mode=sgml and --mode=ccpp.

Checking multiple documents

To check a selection of documents, the -exec flag of the find command is aspell’s friend. For example, to check every file in every directory in the current directory:

find ./ -exec aspell -d, --master=british -c '{}' \;

Here {} corresponds to the output of the find command, and we delimit it with single quotes to allow for filenames that contain spaces. ‘\;’ signifies the end of the command to be executed by find.

This can be further supplemented by find’s regex support to filter the search results, and of course, the aspell filters:

 find ./ -iregex '.*\.[hs][tg]ml' -exec aspell -d, --master=british --mode=sgml -c '{}' \;

This will recursively find all files in the current directory and the directories beneath it that have the extension ‘.html’ or ‘.sgml’ (case insensitive), and run aspell on them ignoring all HTML and SGML tags.

I have been using some form of GNU/Linux as my main operating system for the best part of 5 years now. In general, I am a very happy user - most of the software I use ‘just works’ and the time I need to spend doing system administration is minimal. However, very occasionally I end up succumbing to the temptation of bleeding edge, and my computer refuses to boot…

Don’t panic!

So the Linux heart has stopped beating, and you can no longer access your precious OS. What do you do? Well the first thing is to remain calm, don’t try anything crazy like doing a complete reinstall, I can almost guarantee you won’t need to.

Pull your bootstraps up

The first thing you need is another means by which to boot your machine so you can mount your hard drive and access your data. This process is known as bootstrapping. There are a number of dedicated rescue disks for this purpose, but most of the time your distribution CD will be just fine. I recently used an Xubuntu CD to rescue an Ubuntu system, because I couldn’t find my Ubuntu disk.

Basically you need to get yourself booted into a shell on your machine ASAP, so you can get to fixing your system. To do this, some disks provide a ‘boot into rescue mode’ option, others will give take you straight into a window manager from which you can launch a terminal. For older disks, you might have specify ‘linux single’ to the the ‘boot:’ prompt to boot into single-user mode.

The kiss of life

Booting into a shell from your CD isn’t in itself going to bring your system back to life. For this you need to switch to a chrooted environment, and I always forget the exact process, hence this blog post! (I recommend writing the following commands on the cover of your boot CD as a future aide-mémoire).

Firstly you need to mount your system disk at a mount point in the current shell’s virtual file system. Something like:

mkdir /mnt/mydisk
mount /dev/sda3 /mnt/mydisk

Where /dev/sda3 is the system disk partition you are recovering. If you can’t work out which partition holds your system, fdisk -l might give you some hints. If you can’t mount your system partition, you are probably in more serious trouble, perhaps try running fsck on the wounded partition e.g. fsck /dev/sda3.

Now we have a mounted system partition, we are half way to accessing it, but first we must bind to our current /dev tree. This means that when we perform the chroot, our new environment will still get access to the special /dev (device) file system:

mount --bind /dev /mnt/mydisk/dev

Now we are ready to chroot:

chroot /mnt/mydisk/dev

It’s alive!

If you’ve got this far, it’s good news, you have now successfully mounted your system partition, and are you are no longer in the boot CD shell, but instead inside a chrooted shell. This means that your system disk root is now your working root. To confirm this try ls -al.

More special file systems

With Linux (and other Unixes), from the Kernel’s perspective everything is a file. Before we did the chroot, we bound to the /dev filesystem, which provides access to devices such as the computer’s disks, sound card etc. We now need to mount the proc and sys file systems:

mount -t proc none /proc
mount -t sysfs none /sys

What to do next?

This article can help you no further! How to get your system back to a state where it boots depends on exactly what your problem is. In my most recent experience, I had corrupted my lilo configuration, and just needed to fix a symbolic link, and re-run lilo -b /dev/sda3. You’ve done the resuscitation, now for the surgery…

Well this might seem blindingly obvious to some, but I was stumped for half an hour this morning trying to figure out why ‘grep he+’ wasn’t finding the word ‘hello’ in a test file when it was obviously there. The answer was that I should have read the manpage very carefully. The all-important paragraph reads as follows:

grep understands three different versions of regular expression syntax: “basic,” “extended,” and “perl.” In GNU grep, there is no difference in available functionality using either of the first two syntaxes. In other implementations, basic regular expressions are less powerful. The following description applies to extended regular expressions; differences for basic regular expressions are summarized afterwards.

Confused? So was I until I read the Wikipedia article on regex, which states that:

The basic Unix regular expression syntax is now defined as obsolete by POSIX, but is still widely used for backwards compatibility. Many regular-expression-aware Unix utilities including grep and sed use it by default while providing support for extended regular expressions with command line arguments.

So, the moral of the story is: if you want to use the regular expression syntax you found on that cheat sheet you downloaded, use ‘grep -E’!