SØR-TRØNDELAG UNIVERSITY COLLEGE · SØR-TRØNDELAG UNIVERSITY COLLEGE Faculty of Technology Department of Electrical and Computer Engineering N-7004 TRONDHEIM Main project Project

Bachelor project: Sculpture with 3D Interactive Sound HiST 2007

-1-

SØR-TRØNDELAG UNIVERSITY COLLEGE

Faculty of Technology Department of Electrical and Computer Engineering N-7004 TRONDHEIM

Main project

Project title: Given date: 2007-01-16

Delivery date: 2007-05-11

Sculpture with 3D Interactive Sound Number of pages: 37 pages and 18 appendixes

Project group participants: Thomas Asphaug

Christina Bielsa

Even Martin Grytå

Einar Thorsrud

Thomas Tollefsen

Instructor: Håkon Grønning

E-mail: [email protected]

Phone: 73 55 95 90

Branch of study:

Telecommunication Engineering Project number: TT0703

Employer: Samir M’kadmi

Employer contact: Samir M’kadmi

E-mail: [email protected]

Phone: 64 94 20 98

Freely available

Available after appointment with the employer

Report made available after

X


-2-


-3-

Abstract

The artist Samir M’kadmi is assigned to decorate Blussuvoll School with a sculpture. The

sculpture sound system shall interact with the public through Bluetooth-technology. This

project concerns development of the interactive sound system for this sculpture. The public

will communicate with the sculpture by sending text, images or sound files. This media is

processed and converted into unrecognisable sound that is played through the seven speakers

in the artwork, giving a three dimensional effect. Music uploaded by contemporary artists is

played when playback of the Bluetooth files are completed.

The platform of the system is a server running GNU/Linux. The server provides a platform

for the sound processing software and hardware, and a web system.

Communication between the sculpture and the public is handled by a Bluetooth server from

Bluegiga Technologies. This comes with preinstalled software for file exchange, and

communicates with the main server over Ethernet.

The real time graphical programming environment, Pure Data, is used for sound processing.

Different audio effects are used to process the sound files to a various extent.

Images are converted to sound using GEM (Graphical Environment for Multimedia), which is

a plug-in for Pure Data. Images are analysed and the data is used as parameters in the sound

processing.

Text files are converted to speech using the Festival speech synthesis software. The resulting

sound files are processed further in Pure Data.

The web based file administration system File Thingie is used to manage art music files.

A program has been developed to take care of file management and conversion, and to control

playback of art music and Bluetooth files provided by the public. This program is developed

using the Python programming language.

As the sculpture is located outdoor, the loudspeakers have outdoor specifications. As the

distance between the amplifier and speakers is about 40 meters, it has been planned to use

100V line transformers to reduce signal loss.

The final system meets the requirements, and is fully functional and ready for installation on

the site.


-4-

Preface

This report documents the bachelor project “Sculpture with 3D Interactive Sound” by five

students at the Sør-Trøndelag University College. The report is meant to function as a user

manual, to be helpful during the installation and further development.

We found the project interesting because it was a mixture of art and technology. This project

was unique in the way that we were a part of the creative process, and had the opportunity to

influence how the sculpture should interact with the public.

A preface isn’t a preface without the usual round of thanks. We especially wish to thank

Håkon Grønning, our instructor at HiST, Jarmo Röksä at NTNU Midgard Media Lab and

Robin Støckert at HiST and Soundscape Studios.

The report is meant to be read in its entirety, but each chapter can be read independently. The

main chapters contain a discussion about different possibilities, and an overview of the chosen

solution. The details are left to the appendix. The report is written in English, as the project

group was international.

Each group member was responsible for different tasks:

Thomas Asphaug Main program “Spamalot”

Christina Bielsa Web system

Even Martin Grytå Conversion of image and text to sound

Einar Thorsrud Server and Bluetooth system

Thomas Tollefsen Sound processing and audio hardware

There was close collaboration throughout the project, and all group members are collectively

responsible for the result.

Trondheim, 2007-05-11

Thomas Asphaug

Christina Bielsa

Even Martin Grytå

Einar Thorsrud

Thomas Tollefsen


-5-

Content

1 Introduction .................................................................................................................... 7

1.1 Background .................................................................................................................. 7

1.2 Task ............................................................................................................................. 7

1.3 Task limitation ............................................................................................................. 7

1.4 Final requirements and goals ....................................................................................... 8

2 Methods .......................................................................................................................... 9

2.1 Previous knowledge ..................................................................................................... 9

2.2 Literature and resource persons ................................................................................... 9

2.3 Project work ................................................................................................................. 9

2.4 Development process ................................................................................................... 9

3 Server system ............................................................................................................... 10

3.1 Requirements ............................................................................................................. 10

3.2 Discussion of possible solutions ................................................................................ 10

3.3 Overview of the system ............................................................................................. 11

4 Bluetooth system .......................................................................................................... 14

4.1 Requirements of the Bluetooth system ...................................................................... 14

4.2 Bluetooth dongle ........................................................................................................ 14

4.3 Embedded Bluetooth server ....................................................................................... 15

4.4 Overview of the implemented Bluetooth system ...................................................... 15

5 Sound processing .......................................................................................................... 17

5.1 Requirements ............................................................................................................. 17

5.2 Pure Data or Max/MSP .............................................................................................. 17

5.3 Extending Pure Data .................................................................................................. 18

5.4 Pure Data main patch for 3D sculpture ..................................................................... 19

6 Image to sound ............................................................................................................. 22

6.1 Requirements ............................................................................................................. 22

6.2 Image to sound conversion ........................................................................................ 22

6.3 Implementation .......................................................................................................... 23

7 Text to sound conversion ............................................................................................. 24

7.1 Speech synthesises ..................................................................................................... 24

8 Web system .................................................................................................................. 25

8.1 Requirements ............................................................................................................. 25

8.2 Administration of art music ....................................................................................... 25

8.3 Guestbook .................................................................................................................. 26

8.4 Sound sample playback ............................................................................................. 26

8.5 Prototype of the website ............................................................................................ 26

9 Main Program ............................................................................................................... 28

9.1 Requirements ............................................................................................................. 28

9.2 Programming language .............................................................................................. 28

9.3 Python programming language .................................................................................. 28

9.4 Main program ............................................................................................................ 29

10 Audio hardware ............................................................................................................ 31

10.1 Requirements ......................................................................................................... 31

10.2 Soundcard .............................................................................................................. 31

10.3 Speakers ................................................................................................................. 32

10.4 Amplifier ................................................................................................................ 33

10.5 Speaker Cables ....................................................................................................... 33

11 Evaluation of the project work ..................................................................................... 34

11.1 Evaluation of the process goals .............................................................................. 34


-6-

11.2 Evaluation of the result goals ................................................................................. 34

11.3 Time use ................................................................................................................. 35

11.4 Budget .................................................................................................................... 36

12 Conclusion .................................................................................................................... 37

Appendixes

1 Appendix: References .................................................................................................. 38

2 Appendix: Term list ..................................................................................................... 41

3 Appendix: CD content .................................................................................................. 42

4 Appendix: Detailed configuration of the server ........................................................... 43

5 Appendix: Configuration of the Bluetooth system ...................................................... 56

6 Appendix: “copier” script – full listing ........................................................................ 61

7 Appendix: More about Pure Data ................................................................................. 62

8 Appendix: Details about the image patch .................................................................... 79

9 Appendix: Suggested structure of the web site ............................................................ 84

10 Appendix: Guestbook details and code ........................................................................ 86

11 Appendix: DewPlayer configuration ............................................................................ 88

12 Appendix: Main program – full listing ........................................................................ 89

13 Appendix: Main program – explanation ...................................................................... 91

14 Appendix: Functions “Funksjoner” – full listing ......................................................... 94

15 Appendix: Main program functions – explanation ...................................................... 97

16 Appendix: Installation guide main program ................................................................. 99

17 Appendix: Product sheets for sound components ...................................................... 102

18 Appendix: Gantt chart ................................................................................................ 107


-7-

1 Introduction

1.1 Background

Trondheim municipality wants to decorate Blussuvoll School with an interactive sculpture

(figure 1), and the artist Samir M’kadmi is assigned to realize this. NTNU Midgard Media

Lab arranged communication between M’kadmi and HiST. This resulted in a Bachelor project

at HiST. The student project concerns the development of sound system.

The sculpture also has a light system in the globe. The light changes depending on the

whether conditions. This project does not involve the light system.

This sculpture will hopefully give the pupils an interest in art, music and technology.

Figure 1. Sketch of the sculpture (Samir M'Kadmi)

1.2 Task

The sculpture should interact with the public through Bluetooth-technology. The public will

communicate with the sculpture by sending text, images or sound files. This media is

processed and converted into unrecognisable sound that will be played through speakers in the

artwork. The sculpture will have 7 loudspeakers, making it possible to give the sculpture its

3D sound effects. Music uploaded by contemporary artist is played when playback of the

Bluetooth files are completed.

1.3 Task limitation

In the beginning of the project, the task was relatively open, and the project group took an

active part in defining the specific functions of the sound system. Many ideas about

interesting features came up during the first meetings, and it was necessary to limit the task.

Although interesting, some ideas that came up was rejected because it did not seem possible

to implement them with the time and recourses available. These were:

Real time jamming

This seemed to be an immense challenge with regard to both Bluetooth and

real time programming.

Real time speech

Same problems as for real time jamming.


-8-

Audio streaming of the sculptures sound

Demands large server capacity.

1.4 Final requirements and goals

After limiting the task and deciding to focus on the features that seemed feasible, the project

was focused on the following problems:

Play art music in stand by mode

Send instructions to new Bluetooth units

Receive files from Bluetooth mobile phones

Process received files (image, text and sound)

Play the processed sound with 3D effects

Administrate art music through a web site

Audio hardware


-9-

2 Methods

2.1 Previous knowledge

The project group had no experience with similar projects, and the project in it self was also

quite extraordinary.

From previous studies there was some relevant knowledge:

Basic programming

Electronics

Project work

Web design

Signal processing

2.2 Literature and resource persons

It was difficult to find relevant and reliable literature, especially about the real time sound

processing. The Internet was the main source of information.

There were also some problems finding professional Bluetooth and audio equipment. In this

case it was helpful to be in contact with persons with relevant experience. They could refer to

interesting products and solutions. Unfortunately the project group did not get in contact with

the resource person on audio hardware until early March, after much time spent on

unnecessary research.

2.3 Project work

The first two weeks of the project period was dedicated to the pre-project research. This

resulted in defined goals and a framework for the system. In the light of this, plans for the

development process were made.

Every second week the project group made a report which documented the work that had been

done, possible deviations and plans for the next two weeks. Every report was presented in a

meeting in order to inform the employer and the instructor. These meetings were the arena for

making decisions and getting feedback from the employer.

Administrative tasks like being project leader, chairman of meetings and secretary circulated

between the group members.

2.4 Development process

As it was important to ensure the success of the project, the strategy was to focus on making a

basic but working prototype, and continue to improve it through the project period. It was

important to reuse other software, and always use the easiest possible solution, rather than

reinvent the wheel.


-10-

3 Server system The main server is the heart of the sculptures sound system. The server has to be a stable and

reliable platform for the sound system.

The configuration of the server is explained in detail in appendix 4. The appendix is meant to

be helpful when installing or modifying the system, and for future system administrators

3.1 Requirements

The main function of the server is to provide a platform for the 3D interactive sound system.

The tasks are:

Receive files from the embedded Bluetooth server.

Store art music files

Provide infrastructure for sound processing, including:

- Full support for a 8 channel professional sound card

- Platform for running the real time sound processing software.

- Multimedia software (decoders, speech synthesiser)

Provide a web server with PHP for the web system

MySQL-server for the web system

Remote administration

The server must be able to act as a development platform during the project period

- Programming environment

- Graphical user interface

The system must be as reliable and secure as possible

3.2 Discussion of possible solutions

Microsoft Windows and GNU/Linux was both considered as the server’s operating system.

The choice of OS depended on which sound processing system was chosen, as one of the

most relevant applications, Max/MSP, only works on Mac and Windows platforms (Cycling

’74 web site). The other alternative, Pure Data (PD), is also compatible with GNU/Linux

(Pure Data web site). The choice of sound software and operating systems was made at the

same time, because of the limitations of Max/MSP. Refer to chapter 5.2 for the discussion

about whether to use Max/MSP or PD.

The capability to handle many different file formats was an important issue, and was easier to

do with Linux, because of the many command line tools available, which is easy to execute

from within a program or a script. For the Windows platform on the other hand, not as much

text based software is available, making reuse of other software complicated.

An important aspect was the artist’s wishes to have a possibility to administrate the art music

over the World Wide Web. This lead to the need of a web server, and the most used web

server on the Internet is Apache running on GNU/Linux (Apache web site).

In this chapter follows a summary of the advantages and disadvantages of Linux and

Windows that led to the decision.


-11-

Alternative 1: Windows

Advantages:

Possibility to use Max/MSP.

All the students have experience with Windows.

Very good hardware support

Windows will probably be known to any future system administrator when the

sculpture is finished and requires maintenance.

Disadvantages:

Little text based multimedia tools that may be used in conjunction with software made

for this project.

There is no experience in the group with Windows as a server.

3.2.1 Alternative 2: GNU/Linux

Advantages:

GNU/Linux is free and Open Source

There is experience with Linux system administration in the project group

Linux is programmer friendly

- Many text based tools

- Highly customisable to the user’s needs

- All major programming languages are supported

Disadvantages:

Not as good hardware support as Windows

Several of the project group members has no experience with GNU/Linux

Future system administrators may not be experienced with GNU/Linux

3.3 Overview of the system

The decision to use GNU/Linux on the server was made early in the project. The server was

ordered shortly after the approval of the pre-project report.

3.3.1 Server hardware

To decide on the server hardware, the required computing power was estimated, and the

configuration decided. The main factors were:

A powerful CPU for real time audio processing

Enough storage space for the art music

The hardware must be compatible with Linux

Other hardware solution which was considered and may be added in the future includes:

Uninterruptible power supply

RAID hard drives

The chosen server was a regular personal computer. A PC was chosen for its low cost, and

because it met the projects needs. The key specifications are:

2 GB RAM

250 GB + 400 GB hard drives

AMD Athlon 64 X2 4200+ Dual core 64 bit CPU


-12-

Two Ethernet cards

3.3.2 Operating system

The operating system is Debian GNU/Linux (Debian web site). Debian was chosen because it

is compact, secure and highly configurable, allowing full control over the server. This is

important in order to insure high security and performance.

Debian has a slow release cycle, and after a new version has been released, security updates

will still be available for the old release at least a year, giving time for the administrator to

upgrade the system. Upgrade to a new release can be done without the need of reinstalling the

whole system. The latest release of Debian GNU/Linux is 4.0 “Etch”.

It was decided to install the system with Debian Etch while it was still “testing”, considering

that it would soon become the “stable” release. Using the APT system the server was and is

continually updated, so that the installed software always has the current Debian 4.0 system,

with all modifications and changes, including security updates.

The partitions are generally much larger than needed, but this is due to the fact that there is no

money to save on smaller disks. Several partitions are used to prevent logs or uploaded files

filling up the system disk, causing the system to crash.

3.3.3 Sound software

The sound system is built around Pure Data with some extensions, Festival for text to speech

synthesis, and audio software for decoding compressed audio files. The sound card

infrastructure is ALSA, which has support for M-Audio Delta 1010 (ALSA web site).

Software from debian-multimedia.org is used for decoding compressed sound formats that is

not supported by the standard Debian distribution due to copyright restrictions (Debian web

site).

3.3.4 Network services

The network services are:

HTTP for the web site and administration of art music

SSH for remote administration.

NFS for file sharing with the embedded Bluetooth server

Apache is used as web server. It is configured with support for PHP and MySQL. This is used

for file administration of the art music, in addition to presenting the sculpture on the World

Wide Web.

OpenSSH is used to provide encrypted remote login and file transfer.

3.3.5 Security

To insure the security of the system, the server is configured with the following in mind:

Only the needed services is available on the network (Web and SSH).

The server uses a firewall and only allows incoming connections to port 22 and 80

Only needed software is installed.

Unencrypted services like telnet, rsh, rlogin, vc and alike are disabled.


-13-

The communication between the Bluegiga embedded Bluetooth server and the main

server is on a separate network.

3.3.6 System administration

The server is running system information services accessible to the administrators using a web

browser. PhpSysInfo (phpSysInfo web site) is used to provide general system information,

and Webalizer (Eilertsen and Mikalsen, 2003:84) is used to display web server statistics. This

information is password protected.

During ordinary use, the server only needs the administrator to install security updates and

make backups. The system may have problems not discovered during the project period,

which makes it important for the administrator to monitor the system.

There has not been time to plan a backup system for the server. As the artist Samir

M’Kadmi’s main concern is losing the art music files, a USB hard drive may be used to

manually back up the files, until a full backup system is in place.


-14-

4 Bluetooth system The interactive part of the sculpture is based on the Bluetooth technology, which allows

spectators with mobile phones to communicate with the sculpture.

General configuration of the Bluegiga is described in the WRAP Access Servers User’s and

Developer’s Guide. The configuration of the Bluegiga WRAP Access Server specific for this

project is described in detail in appendix 5.

4.1 Requirements of the Bluetooth system

The Bluetooth systems main requirements are:

Send instructions to all new mobile phones in proximity of the sculpture

Receive files the users want to send to the sculpture

4.2 Bluetooth dongle

When the project group started investigating the possibilities for the Bluetooth system early in

the project period, there was no experience with professional Bluetooth equipment in the

group. Therefore, the first thing that came to mind was to use an ordinary Bluetooth USB

dongle.

4.2.1 Hardware solution

All Bluetooth radios are capable of 7 simultaneous connections (Nokia, 2003:7), which is

sufficient for this projects needs. The fact that most Bluetooth enabled devices has a range of

about 10 meters means that the Bluetooth radio must be located in the “globe” on top of the

sculpture, were as the server will be located inside a building close by.

By having the Bluetooth USB dongle in the sculpture, the range of USB becomes an issue.

The maximum length of a USB cable is 5 meters, which is too little for this project. However,

several USB range extenders exists, and by using Ethernet to transfer the USB signal, it is

possible to extend the range of USB 1.1 (12 Mbit) devises with up to 100 meters (DataPro

web site).

4.2.2 Software and programming

The discussion on which Bluetooth system to use was taking place at the same time as the

discussion about what operation system to use on the server. The main focus for this

investigation was the GNU/Linux platform, but investigation was also made on how to

implementation could be made using Microsoft Windows.

The Bluetooth specifications are immense, and the only feasible way to program the

Bluetooth system, is by using a wrapper around the Bluetooth system, which provides the

programmer with an easy to use API. This is available both on GNU/Linux and Windows.

The easiest way to develop Bluetooth software in Windows is by using the Windows Sockets

(Winsock) API. By using Winsock to program the Bluetooth system in the same manner as an

ordinary networking system (Microsoft web site), there will be relatively easy to find help and

information, as socket programming is common.

The GNU/Linux platform has several APIs which allows programmers to access the

Bluetooth interface. The most mature of these systems is BlueZ (Huang, 2005:41). BlueZ is a


-15-

C API, but there also exist a wrapper around BlueZ, named PyBlueZ, which allows Bluetooth

software to be written in the programming language Python (Huang, 2005:27).

4.3 Embedded Bluetooth server

By consulting Jarmo Röksä (Midgard Media Lab), the project group was told that it might be

interesting to evaluate the Bluegiga WRAP Access Server.

When investigating the possibilities, it became obvious that the Bluegiga embedded Bluetooth

server vas going to make the Bluetooth specific part of the project much easier that first

expected, as it came with preinstalled software for proximity marketing, using the Bluetooth

OBEX profile for file exchange. The Obexsender software is capable of sending a file to all

new mobile phones, and also accepts all incoming files (Bluegiga, 2006 a: 8).

Obexsender has more features which might be utilised if the project is to be developed

further. This includes the possibility to analyse incoming files, and send a response based on

the type or content of the file.

The Bluegiga embedded Bluetooth server has an Ethernet interface which makes it trivial to

place inside the sculpture while the main server resides in a building close by.

4.3.1 Transferring files from the Bluegiga to the server

In the early months of 2007, the documentation for the Bluegiga was password protected, and

it took several weeks to get access to the full documentation. At that point it was clear how to

use the Bluegiga to send and receive files, but not how the Bluegiga could pass received files

on to the server, so that they could be processed.

The only possibility for transferring files from the Bluegiga known to the project group was

FTP, but that was ruled out due to complexity. It was also known that the operating system of

the Bluegiga was a minimal Linux system, and that it was possible to program software in C.

As no good solution had been found at the time, it seemed necessary to write custom software

for transferring files. Much time was spent learning socket programming, and the Linux C

API in general, in order to implement the custom file transfer system. There was no

experience with socket programming in the group, which made this solution a considerable

challenge. This was later abolished when NFS arouse as a possibility.

4.4 Overview of the implemented Bluetooth system

After discovering the features of the Bluegiga with its Obexsender software, the choice of

Bluetooth system had to be the Bluegiga box. This comes in different configurations, and the

simplest configuration with one Bluetooth radio, enabling 7 simultaneous connections and no

encryption would be sufficient for this project. Because Jarmo Röksä was able to get a very

good prize, the top model with 3 Bluetooth radios was ordered.

The Bluetooth system is completely separate from the rest of the system, and consists of the

Bluegiga and the server. The server needs to run a NFS server in order to share parts of its

storage with the Bluegiga. This allows the Bluegiga to mount that share as a networked disk,

and copy all incoming files to the hard drive of the server.


-16-

4.4.1 Sending instructions

Obexsender is utilised for sending a file to new units and logging there address, so that they

only receives the file ones. This is done by using Obexsender out of the box, with only small

changes in the configuration file.

4.4.2 Transferring files with NFS

The Bluegiga box is capable of mounting remote NFS shares (Bluegiga, 2006 b: 46), and thus

the problem of transferring files between the Bluegiga and the server is reduced to a problem

of getting the file copied to the correct folder, renamed and permissions set correctly.

The use of NFS was the obvious solution, as it is simple and effective, thereby increasing the

projects chance of success.

A shell script (appendix 6) for copying files to the mounted NFS share, is started

automatically on the Bluegiga ones a Bluetooth file has arrived.

Because NFS is an insecure service, as it is unencrypted (Smith, 2006), the communication

between the Bluegiga and the server is on a dedicated network, using a separate network

interface in the server, and a cross-over Ethernet cable.

4.4.3 Physical protection

To protect the Bluegiga against frost and condensation, it is placed in a waterproof container,

and fitted with a small heater. This insures stable temperatures, and prevents the formation of

condense.

A Bluegiga Bluetooth server with the protective casing described has been ordered, but has

not arrived by the end of this project.

4.4.4 Stability issues with the Bluegiga

There have been incidences during testing when the Bluegiga stopped responding. It was then

impossible to log in using SSH and the only way to get it up and running again was to unplug

and reinsert the power cable. This raises the issue of stability, especially sins the globe of the

sculpture is difficult to reach. It is therefore important with a system which makes it relatively

easy to cut the power from within a building to reboot the Bluegiga.

Cron (a time based scheduling service) is used to automatically reboot the Bluegiga every

night. This has been tested, and turned out to be effective.


-17-

5 Sound processing This chapter gives a short introduction of Max/MSP, and also a comparison of its “semi-rival”

Pure data. Since PD has been used in this project, an introduction of PD’s manner of

operation is presented in appendix 7. An overview of this project’s PD main program is

particularly described in appendix 7.3.

It is worth mention that the presentation of PD in this report is only an introduction to the

functions and terms that has been used in this project. PD is a huge program, with many

possibilities beside the 3D sculpture’s sound processing system. For a further details on PD

manner of operation see PD manual written by Miller S. Puckette (Pure Data web site).

5.1 Requirements

For this project we first of all needed a program that was a real-time program for audio and

capable of handling 7 channels or more. Also all channels had to be handled one by one, to

have full control of each channel. It was desirable to have a sound processing tool that was

flexible and relatively easy to learn.

5.2 Pure Data or Max/MSP

Since the project group had no experience with real-time audio processing we had to do a lot

of research on what solutions the marked offered. Already on the first project meeting we got

a tip of a program called Max/MSP from one of our resources. This program is mutual to our

final solution, Pure Data, and was a good starting point for our research.

5.2.1 Max/MSP

Max is a graphical development environment for music and multimedia developed and

maintained by San Francisco-based software company Cycling '74 (Cycling ’74 web site).

It has been used for over fifteen years by composers, performers, software designers,

researchers and artists interested in creating interactive software. Max was originally written

by Miller Puckette as the Patcher editor for the Macintosh.

MAX has a number of extensions, most notably, a set of audio extensions to the software

appeared in 1997, ported from Pure Data, called MSP (Max Signal Processing or the initials

of Miller S. Puckette, the author of both Max and PD). This "add-on" package for Max

allowed for the manipulation of digital audio signals in real-time, allowing users to create

their own synthesizers and effects processors. Max/MSP is a cross-platform system

compatible with both Mac OS X and Windows XP.

5.2.2 Pure Data

When the project group started to do research on Max/MSP they got linked to a program

called Pure Data. Pure Data is a real-time graphical programming environment for audio,

video, and graphical processing. It is an open source program, and it is compatible with most

operation systems.

The core of Pure Data is written and maintained by Miller Puckette and includes the work of

many developers, making the whole package very much a community effort. Pure Data is

very similar in scope and design to Miller Puckette’s original Max program.

http://en.wikipedia.org/wiki/Development_environment

http://en.wikipedia.org/wiki/Music

http://en.wikipedia.org/wiki/Multimedia

http://en.wikipedia.org/wiki/San_Francisco

http://en.wikipedia.org/w/index.php?title=Cycling_%2774&action=edit

http://en.wikipedia.org/wiki/Interaction

http://en.wikipedia.org/wiki/Miller_Puckette

http://en.wikipedia.org/wiki/Apple_Macintosh

http://en.wikipedia.org/wiki/Pure_Data

http://en.wikipedia.org/wiki/Sound


-18-

5.2.3 Evaluating possibilities

The decision on whether to use Max/MSP or Pure Data had to be settled early in the process.

Not only because the project group had to start learning and exploring the program, but also

since this choice depended on the operation system that we were going to use. As mentioned

Max/MSP is not compatible with Linux, on the other hand Pure Data is. We wanted to use

Linux for different reasons (see 3.2 for details).

Both PD and Max/MSP use a similar interface, allowing building custom music, video, and

multimedia applications by visually interconnecting objects. It is a language where functions

("objects") are linked ("patched") together in a graphical environment which models the flow

of the control and audio.

PD is free and open source, and Max/MSP/Jitter costs about US $850 (Cycling ’74 online

store). The Jitter package can be compared with GEM package for Pure Data, used for image

to sound conversion (see chapter 6).

Pure Data was chosen as it was desirable to use Linux, and Pure Data does not have any

disadvantages compared to Max/MSP.

5.3 Extending Pure Data

PD comes with an extensive library and objects. PD has two classes of objects; these are

internals and externals. Internals are built in PD objects. External has to be loaded at runtime.

Once the external has been loaded they cannot be distinguished from internals anymore. A

library is a collection of externals compiled into a single binary file.

PD is a powerful tool for real time sound processing, but lacks flexibility when it comes to

file handling and open and play other sound file format than .wav. An important part of this

project is to be able to handle files, both the incoming Bluetooth files and the art music files,

in various file formats. PD had to be able to do this, and writing externals or find already

written externals seemed like the only way to achieve this.

In principal PD externals has to be written in the C programming language since Pd is written

in C. PD is an object-oriented system due to its graphical nature. Unfortunately C is not an

object oriented programming language. The resulting source code will not be as elegant and

simple as C++ code would be, for instance.

It became clear that the task of writing externals in C would be time consuming and not

within the time limit of this project. Other ways to program these externals had to be found.

At the Pure Data forum pages examples were found on how to write externals in C++ using a

program called Flext. Flext is a cross platform C++ layer for writing PD externals (Grill,

2003) and also for Max/MSP. This means that externals can be written in C++ with a lot of

advantages compared to C. Cross platform also meant that externals originally written for

Max/MSP could be used. This increased the possibilities of finding already written externals

that could suit this project needs.

"readanysf~" was one of these externals. The reason why this external was so interesting was

that it was made to get PD to play mp3 files and other music files directly (readanysf~ web

site). This was interesting since mp3 files are widely in use on mobile phones.


-19-

External modules such as Flext need to communicate with the respective hosting real-time-

system, in this case PD, through a well-defined programming interface. In PD’s case this

means one or more C language header files that contain these definitions. These header files

doesn’t come with the standard distribution of PD, but have be downloaded as a source code

package.

When PD was correct installed on the server, the current Flext released was downloaded and

installed according to the readme.txt and config.txt files to suit the platform (Linux).

"readanysf~" was installed and tried out in PD, but it did not work as it was supposed to. We

got error messages when we tried to open and play mp3 files. The C++ code of the

"readanysf~" external was looked over; trying to discover what was causing the problem. The

code was large and complex and it became clear that there wasn’t time to go through it. The

problem was also posted on forums on the Internet but no answer to the problem was replied.

Since file handling was an important part of getting the whole system working, the project

group was forced to look for other solutions. A possibility was to use a dedicated program to

control PD, and perform the tasks PD was not able to do.

Library packages, like GEM, don’t need Flext since these packages are already compiled into

a PD binary file.

5.4 Pure Data main patch for 3D sculpture

Pure Data is used for 3 different purposes:

Playing art music

Sound process and play Bluetooth sound files

Sound process image files and play them (chapter 6)

Although Pure Data is also used for playing art music, these files are not processed in any

way.

The chapter deals with the sound processing of sound files sent from mobile phones.

5.4.1 Main patch

The PD main patch in figure 2 is the window where all the audio effects and I/O are managed.

All boxes, except the volume control and "dac~" (digital to analogue converter), are PD sub

patches. The main patch gives options for routing through or outside any audio effect.


-20-

Figure 2. 3D sculpture’s main patch

The project group have made 20 different main PD patches (appendix 7.5), and when the

system is running they will be opened in random (See chapter 9 for details about the main

program).

5.4.2 PD sub patches

The following sub patches are used in this system:

Audio effects:

Reverb

Fast Fourier transform (used as an audio effect in the time domain)

Multiplying oscillator

Delay

Added art music

Pitch shifter

Timbre stamp

For controlling output volume and filter:

Volume and filter control patch

Channel changer


-21-

5.4.3 Copyright issues

After a conversation with TONO the project group was a little worried about the processing of

copyrighted audio files. It is not even clarified at this writing point whether the sending of

copyrighted file to the system, store-and-forward operate it, sound process it and play it in a

public place is a legal action. At this moment TONO is looking into it, because, as their

representative said; it’s a very unusual situation. In worst case the artist may need to use his

lawyers in a debate with TONO. From the artist point of view, at this moment, the sculpture

has to be seen as an instrument, with no function unless someone sends a sound file to it.

When a sound file is sent, the instrument gets activated, and it is the sender responsibility to

have a copyrighted file.


-22-

6 Image to sound Modern cell phones are capable of taking photographs, and thus it would be interesting for the

users of the sculpture to send photographs to the sculpture in order to influence the sound

output. The user should be able to feel the relation between the image and the sound.

6.1 Requirements

For this part of the project we needed a programming library that is able to deal with image

processing. The file format that should be supported is JPEG since this file format is the most

common image format on cell phones today. There was a need for a way to handle the images

in a way so that we could convert the images into listenable and interesting sound.

6.2 Image to sound conversion

The most common image format on cell phones is JPEG, so this is the format that will be

supported. To make this conversion, some values have to be extracted from the image. The

easiest values to extract are the RGB values. There are many ways to extract these values.

After a discussion with Håkon Grønning, he suggested to look into the Imagemagick library.

The project group also got a tip from Samir M’Kadmi that there was a package for Max/MSP

called Jitter which could handle pictures, and he thought there might be a similar library for

PD. After some research, a package called GEM which is a graphical programming library for

PD was discovered.

6.2.1 Custom software using the Imagemagick library

Imagemagick is a free software suite that can be used to edit, create and compose bitmap

images of many formats. The Imagemagick library may be used to develop other software for

image processing. This makes it possible to modify images automatically and dynamically.

Imagemagick has support for all major programming languages (Imagemagick web site).

6.2.2 Using Pure Data with GEM

GEM (Graphical Environment for Multimedia) is a loadable library for PD. GEM provides

many objects for use with Pure Data (GEM manual: Introduction), extending PD with the

capability to process graphics. GEM is published under the GNU General Public Licence.

6.2.3 Discussion

It was considered to develop software using the Imagemagick library to extract the RGB

values, and generate sound based on those. It would take a lot of time to develop this

software. To develop software using the Imagemagick library is more complicated and would

take more time than using GEM. On the other hand, by using Imagemagick, the system will

be more adapted to the projects needs.

By using GEM, the image processing system will be fully implemented in PD. This allows

the image system to be seamlessly integrated with the sound processing system.

It was decided to use a combination of PD with GEM and the Imagemagick command line

tools. (See 6.3).


-23-

6.3 Implementation

First the picture is resized to a 320x200 image by a command line tool in Imagemagick to a

JPEG image. As the Imagemagick command line tool returns an error value if the image file

that comes in is corrupted and PD does not start. Then the picture is loaded into PD with the

GEM library tools. The next step is to load the given position of the counter and send it out to

the main patch. In the end the patch checks if the position is at the maximum of the image and

if it is PD quits, and if it’s not then it loads the next position of the image. This is

demonstrated in figure 3.

Figure 3. Data flow chart for extracting the pixel values

When the values are sent to the main PD patch they are used as parameters to the reverb and

pitch shifter for manipulating pre selected art music. The colour values give more or less

reverb and pitch shifting depending on the value in.

The most important improvement is to enhance the users’ perception of the relation between

the image and the sound.

Refer to appendix 8 for details about the image patch.


-24-

7 Text to sound conversion The artist wanted the sculpture to be able to play text files as sound. It was uncertain how this

was to be accomplished. The project group came up with two alternatives; use a speech

synthesises system, or to give each character a distinct sound or tone.

7.1 Speech synthesises

Samir M’Kadmi thought speech synthesis was interesting, thus it was decided to use this

solution. The other possibility was discarded early in the process.

There are open source speech synthesis programs available, such as Festival. Festival is

developed at the University of Edinburgh (Festival web site). Festival does not have support

for Norwegian, but English may be used, as the sound will be processed by PD.

The advantage of using Festival is that it is a command line tool that can be easily

implemented in the main program.

The system is implemented using text2wave, which is a Festival script that converts the text

into a wave file.


-25-

8 Web system The web provides a communication channel between the sculpture and the public.

8.1 Requirements

The requirements are:

Remote administration of art music

A system to listen to sample sound files

A guestbook

Developing a dynamic web system requires a programming language in addition to HTML.

PHP is a open source programming language designed for developing dynamic web pages

(PHP web site), and is widely used. The Apache web server integrates well with PHP. It was

natural to choose PHP.

A guest book is most elegantly implemented using a database, and on GNU/Linux the open

source MySQL database server is the obvious choice.

8.2 Administration of art music

The system must allow selected users to upload and manage there own art music. This system

must only be available for trusted persons, in order to insure that no copyrighted material is

uploaded.

A simple system was designed from scratch, but to develop this system with all the necessary

features would be too time-demanding.

There exists free software for such purposes, and the most interesting was File Thingie (See

figure 4). It is a small file manager developed by Andreas Haugstrup Pedersen (File Thingie

web site).

File Thingie is capable of:

Upload multiple files.

Create subdirectories.

Rename, move, delete and copy files and folders.

Search for file and folder names.

Easy customization of the CSS based layout.

Multiple user accounts


-26-

Figure 4. File Thingie interface

8.2.1 Add new users

New users are added by creating a new folder in /home/skulptur/kunstmusikk/brukerN (N is a

integer), and adding this code in the users zone in the File Thingie code:

# userN # $users['userN']['password'] = "********"; $users['userN']['dir'] = "/home/skulptur/kunstmusikk/brukeriN";

8.3 Guestbook

The guestbook have been designed using PHP and MySQL. The data for the guestbook is

stored in a SQL database.

Appendix 10 contains the code listing and some details about the guestbook.

8.4 Sound sample playback

To enable the sound samples to be played easily, a sound player is embedded in the web site.

This project uses DewPlayer, because it is a functional and light weight flash based player,

capable of playing MP3 files (DewPlayer web site).

The configuration of DewPlayer is explained in appendix 11.

8.5 Prototype of the website

An outline of the web site as it was planned by this project group is displayed in figure 5.

There was also produced a draft of the design, but the artist wanted to do his own design.


-27-

Figure 5. Block diagram of the structure of the website

The suggested structure of the web site is explained in detail in appendix 9.


-28-

9 Main Program Chapter 5.3 demonstrates PD’s lack of flexibility in file handling, and also Flext’s

complexity. This forced another solution to these problems upon the project group.

The idea of making a program that could run in the background, performing all these tasks

came up. This way, PD only needed to be used for the things it does best: sound processing.

This chapter will explain the development of this program. That would be all the way from

deciding which programming language to use, the programming part, to the finished program.

9.1 Requirements

The main function for this program is to run in the background performing these tasks:

File handling.

File conversion.

PD control.

The file handling part have to be able to detect when new Bluetooth files are available, and

also have an overview of the stored art music files on the server. It would also have to be able

to rename and move the files. This way PD only had to relate to a single location and

filename. The software has to be able to convert several file formats to wav files. This is

because WAV is the only file format PD can open and play, along with AIFF. The program is

used to start and stop PD when needed.

9.2 Programming language

It was important to find a programming language which enabled rapid development. The

language that the project group was most familiar with was C++, but it is complicated to do

the things that where needed in this project, for example file handling. This would take to

much time.

Python is another programming language that the project group found suitable for this task. It

seemed to have many of the functions that we needed built in, and is easy to learn. It could

also be seen as a good opportunity to learn a new programming language.

In this project, the 2.4 version of Python was used since this version came with the

distribution of Debian used on the server.

9.3 Python programming language

Python is a dynamic high level object-oriented programming language that can be used for

many kinds of software development. It offers strong support for integration with other

languages and tools, and comes with extensive standard libraries (Python web site).

Python is indentation dependent, which means that the program code use indentation on code

lines that belongs together, i.e. if- else statement. This is different from i.e. C++ which uses

curly brackets. This is smart because you are forced to write a very readable code. This is time

saving for debugging.

Python does not need to be compiled; it can run directly as source code. This saves a lot of

time during writing, testing and debugging, and it was perfect in a programming/learning


-29-

process like in this project when extensive testing was necessary. First time run of the

program will compile the libraries that are made, in this project “funksjoner” was compiled to

machine readable code, but the libraries will also work uncompiled. The fact that you do not

have to compile the program will increase the execution time.

Python has a small core library but comes with an extensive standard library package which

providing tools suited for many different tasks.

The integrated development environment Dr Python was used during the development.

Python’s web pages have a lot of documentation that was useful during the development.

On the funny side, Python is named after The Monty Python’s Flying Circus. The

documentation very often refers to Monty Python jokes and names. You are also encouraged

to use Monty Python in the same way in your program code as a kind of tribute. This makes

programming a lot funnier. To honour this tradition, the main program is named “Spamalot”,

from the musical with the same name (Spamalot musical web site).

9.4 Main program

The program needed to be able to start PD with different files and patches, depending on

whether Bluetooth files where available, or if art music is going to be played. It was also

necessary for the program to know if PD was already running and if it was playing a

Bluetooth file or art music file.

An incoming Bluetooth file should not be played before the previous Bluetooth file was

finished. Bluetooth files should have priority over art music files. This means that if PD was

playing art music, it would have to be closed down if a new Bluetooth file was ready to be

played. Figure 6 shows the block schematic of the main program.

Python support both object oriented and structured programming, in Spamalot, structured

programming has been used.

Different command line tools have been used for the file conversion and decoding.


-30-

Figure 6. Main program block diagram

For more information, refer to:

Appendix 12 for a full listing of the main program source code

Appendix 13 for a detailed description of the main program

Appendix 14 for a full listing of the “funksjoner” library

Appendix 15 for a description of the “funksjoner” library

Appendix 16 for information about installation of the main program “Spamalot”


-31-

10 Audio hardware The sound system of the 3D sculpture had a bigger aspect than the project group expected.

Not only because the speakers had to have certain design, but also because there is a lot of

acoustics and performance factors to consider in an outdoor installation. This chapter deals

with the process of deciding on which sound hardware to use.

10.1 Requirements

The artist wanted the project group to do a thorough research on the sound system, since the

installation is meant to be operational for many years, thus the speakers must have these

minimum requirements:

• Outdoor specification

• Robust and discrete design

Good sound quality

The amplifier and soundcard had to have 8 channels, as it was uncertain whether the sculpture

would need seven or eight speakers. The speaker cables had to be calculated to a certain

dimension.

10.2 Soundcard

It was not difficult to find soundcards with 8 channels, but to find a card that was supported

by Linux was a bigger challenge.

10.2.1 M-audio Delta 1010

M-audio Delta 1010 (figure 7) is an 8 channel sound card with good support for Linux. The

PCI host card is mounted in the computer and connected to an external rack with a 25-pin D-

sub host cable.

Figure 7. M-audio Delta 1010 (M-audio web site)

The advantage with a rack mounted card is that the audio is not compromised by the

computer’s internal noise, as all the Delta 1010’s converters are inside the external rack. It is

also tidy and more robust regarding cable connections, since ¼” jack connectors are used on

external rack for all analogue I/O connections.


-32-

10.2.2 M-audio Delta 1010LT

M-audio delta 1010LT is the light version of Delta 1010. It also has 8 x 8 analogue I/O

connections. One of the biggest disadvantages compared to the Delta 1010, is the cable

connections. As shown in figure 8, it gets untidy with many connectors directly on the PCI

card. In addition it uses RCA connectors, which are less robust.

Figure 8. M-audio Delta 1010LT (M-audio web site)

10.2.3 Solution

Because of the advantages of the M-audio Delta 1010 external rack, this card was chosen.

Due to delivery problems with the Delta 1010, other alternatives were investigated. M-audio

Delta 1010 turned out to be on the way out of production, but with some luck, the project

group got there hands on one.

10.3 Speakers

The speakers were the biggest challenge during the hardware research. At first the speakers

was going to be inserted into the tubes of the sculpture. When using the tubes in the sculptures

as a cabinet there are a lot of acoustics considerations to think about, and the project group

had no experience in this area. As time went on the artist decided to use speakers with a

cabinet.

10.3.1 Evaluating MD-40 and CAP-15(T)

The artist was particularly interested in two models from the Norwegian manufacturer called

DNH, specialising in loudspeakers for hostile environments. These were MD-40 and CAP-

15(T), see appendix 17.3 and 17.4 for specifications.

The MD-40 speakers have better sound quality, since CAP-15(T) is mainly designed for

speech and emergency signals. The project group was also able to test the MD-40 speakers

and demonstrate them to the artist. The artist liked them, but he was missing reproduction of

the lower frequencies.

A suggestion was to use either MD-40 or CAP-15(T), supplied with a subwoofer. This

subwoofer could be berried in the ground, in the middle of the sculpture. The artist thought

this was too expensive at this moment.

Comparing the frequency response of MD-40 and CAP-15(T), MD-40 effective frequency

range is 60 - 20000 Hz, and CAP-15(T) is 150 – 20000 Hz. This means that none of them

could fully represent the low frequencies.


-33-

With these considerations, the artist started to look at the design of the two speaker models.

Since the CAP-15(T) speaker is enclosed in an aluminium cabinet, it is probably more

difficult to damage, compared with the MD-40 which is enclosed in a hard plastic (ABS)

cabinet. The CAP-15(T) also has a more discrete and mountable design, from the artist point

of view.

It was decided to order 7 CAP-15(T) speakers with transformers to test them out. Both MD-

40 and CAP-15(T) are available with transformer (40W) on request. This means that it is

possible to use 100 V transmission lines. By using 100 V transmission lines, the cable loss is

decreased, which means it is possible to use thinner cables over larger distances. The

connection of the transformers is described in appendix 17.5.

10.4 Amplifier

High operational reliability is very important on a “static” sound system (with no frequently

surveillance) which is meant to be running for many years.

The amplifier used in the project is an 8 channel power amplifier with 160 watts (RMS)

output per channel in 4 ohms, called IMG STA-1508. It provides more power than needed for

the 15 Watt 7 CAP-15(T) speakers. Refer to appendix 17.6 for specifications.

10.5 Speaker Cables

When using 100 V transmission lines, Robin Støckert (AV responsible at HiST),

recommended to use 0.75 mm2 or bigger. After consulting Nexans, it was suggested to use a

PFSP 2 x 1.5 mm2

cable. The distance from the control room (where the amplifier will be

placed) to the sculpture is about 40 metres.

All CAP-15(T) have PG-nipples on the cable input, to prevent intrusion of humidity. To get

this as tight as possible it is recommended to use cables with a circular design.

10.5.1 Further possibilities (sub woofer)

At the end of the project period, the artist decided to use a subwoofer. This is going to be

placed in the middle of the sculpture. The project group did not have time to implement this

into the system, but it is possible with regard to both the hardware and the software, with

minor changes in the PD sound processing patches. It was decided to use TIC GS50 omni sub

woofer (TIC Corporation web site).


-34-

11 Evaluation of the project work Throughout the project period, the cooperation was very good, and all group members was

committed to open and honest discussions. There was no need for strict organisation as

everybody showed responsibility and initiative.

Using English for all documentation and meetings have been a challenge, as it is a foreign

language for all group members. Because of this, the written documentation may not be as

fluent as it would if it was written in the mother tongue. On the positive side, the group

members have gained more experience with the English language.

11.1 Evaluation of the process goals

The process goals were described in the pre-project report, and are what the group expected to

gain from the process of working with the project. During the evaluation of the goals, it

became clear that some of the goals were inaccurate and difficult to measure.

This section discusses each goal, and the level of fulfilment.

Get a good grade and finish our project in time.

The project was delivered on time, and hopefully all group members will get a good

grade.

Learn more about how to run a project.

This goal was achieved through working in a project group, meetings and reports.

Each of the group members were project leader for a period of time. Also the task of

leading meetings and taking notes was taken in turn.

Become better programmers.

This goal was achieved by programming in Pure Data, Python and PHP.

Learn more about applied signal processing.

This goal have not been achieved, other that what is covered by goal 5. This goal

turned out to be irrelevant for the solutions which were used in this project.

Get an understanding of sound processing and acoustics.

The group members gained knowledge about applied audio signal processing in a

graphical programming language (PD). We have gained a minor knowledge of

acoustics, and have learned that there are many acoustic factors to take in to

consideration, especially in an outdoor installation.

Become better at creative thinking.

Especially the sound and image processing part of the project demanded creative

thinking, but also solving the technical problems required creativity.

11.2 Evaluation of the result goals

Communication with the sculptures sound system through Bluetooth technology in

mobile units for transmitting files (sound, images, text) and real time conversation.

This goal was fulfilled, except for the real time conversation part, which was discarded

early in the process.


-35-

Transmit media files to the sculptures sound system through a webpage.

It was decided that it was not desirable to allow ordinary users to send files to the

sculpture over Internet, but a web system for uploading and administrating art music

has been implemented.

Transmitted data will be converted and processed to unrecognizable sound files

Later in the process the artist decided that the sound processing also could leave the

sound files partially recognisable. It has been made solutions for both purposes.

Therefore, this goal has been fully achieved.

Processed sound files will be amplified and then played through the sculptures 3D-

loudspeaker system.

A 3D sound system with seven speakers has been installed in a lab, and gave a result

which pleased the artist. Thus the goal was fulfilled.

11.3 Time use

For planning expected time use and what tasks that should be done in certain deadlines, an

estimated time use table and a Gantt diagram (appendix 18) was made in the pre-project. All

group members kept hour lists and this could be compared with the estimated hour use. At

project end the actual hour use was slightly above the estimated 1751 hours.

The progress was mainly according to the Gantt chart, though with some substantial

deviations:

Delayed soundcard delivery

It was ordered according to schedule, but was delayed because of circumstances

beyond the project group’s control.

Speakers and amplifier was not ordered on schedule

It was up to the artist to decide on speakers, and the project group did not come up

with any satisfying alternatives. Later in the project period the group got in contact

with Robin Støckert1 who could introduce some good solutions.

The most important consequence of this was that the group did not get much time to

test the system with sound on 7 channels. Thereby it was not as much time as desirable

to test and refine the 3D effect.

1 Robin Støckert is experienced with professional sound hardware.


-36-

11.4 Budget

In the pre-project report it was made a budget which estimated the cost. The total estimated

cost was 28 000 NOK.

The actual costs are calculated in table 1.

Table 1. Budget

Speakers 7 000 NOK

Amplifier 13 000 NOK

Soundcard 5 000 NOK

Bluetooth server* 2 000 NOK

Speaker cables** 4 000 NOK

Server 8 000 NOK

Transformers

3 000 NOK

Total 42 000 NOK * The Bluetooth server was ordered through Midgard Media Lab which has signed a non disclosure agreement

regarding the price. Therefore it is just an estimate. **

This is an estimated price as they have not been ordered.

The cause of deviation from the original budget is mainly that professional equipment is more

expensive than the consumer electronics that was used in the pre-project calculations.


-37-

12 Conclusion An interactive sound system has been developed, with the basic functionality as outlined in

the introduction (chapter 1.4). This includes the Bluetooth system, sound processing, audio

hardware and web system.

The system is built around the sound processing software Pure Data running on GNU/Linux.

The Bluegiga embedded Bluetooth server is used to communicate with the public. A program

to control the system, named “Spamalot”, has been developed in Python.

The Bluetooth implementation was trivial when it was discovered that the Bluegiga had built

in support for Bluetooth file exchange and access to network file systems. However, this

system is not easily extendable for real time applications.

The decision to use Pure Data allowed the use of GNU/Linux as the development platform.

Pure Data turned out to have the functionality that was required, but was not capable of other

programming tasks, like file processing. This resulted in the need for a control system, which

was developed in Python. The combination of Pure Data and Python turned out to provide a

functional and well working system. Although Spamalot is fully functioning it could use some

redesign to be more clear and flexible.

The sound is processed to be unrecognisable in a various degree. The perception of the sound

depends on the listener, but from the project groups point of view, there are potential for

improvements. Because of late decision and arrival of the speakers, there was too little time to

test and develop the sound system to its full potential.

The image processing is implemented using the GEM library for Pure Data. It may be

difficult to sense the relation between the image and the sound. There is a potential for

improvements.

Text files are converted to speech using the Festival speech synthesis system, and processed

further in Pure Data.

Administration of art music is implemented using a web based file manager. There has also

been developed a guestbook and a system to play sample sounds. The artist is working on the

graphical layout of the web site.

The system meets the minimum requirements, and is fully functional and ready for

installation on the site. The product will be delivered to the artist, Samir M’Kadmi, at the end

of the project period.


-38-

1 Appendix: References

1.1 Literature references

(Bluegiga, 2006 a)

Bluegiga: Obexsender User Guide, version 1.4. 2006

http://www.bluegiga.com/default.asp?file=286

(Bluegiga, 2006 b)

Bluegiga:WRAP Access Server User’s and Developer’s Guide. Version 2-2. 2006

http://bluegiga.com/as/current/doc/Users_and_Developers_Guide.pdf

(Eilertsen and Mikalsen, 2003)

Eilertsen, Mats E. and Mikalsen, Arne Bjørn: Linux tjenestedrift. 1st ed. Gyldendal akademisk,

ISBN: 9788205311466. 2003.

(Grill, 2003)

Grill, Thomas: flext, An introduction. PDF.

http://www.parasitaere-kapazitaeten.net/ext/flext/flext-intro.pdf

(Huang, 2005)

Albert Huang: The Use of Bluetooth in Linux and Location Aware Computing. Massachusetts

Institute of Technology, 2005

http://people.csail.mit.edu/albert/pubs/2005-ashuang-sm-thesis.pdf

(Nokia 2003)

Nokia: Bluetooth Technology Overview. Forum Nokia. 2003

http://sw.nokia.com/id/98f61174-e3fc-499f-be81-

7ce66c0a99aa/Bluetooth_Technology_Overview_v1_0_en.pdf

1.2 Internet references

(ALSA web site)

ALSA web site, 2007-05-05: http://www.alsa-project.org/alsa-doc/doc-

php/template.php?company=Midiman%2FMAudio&card=Delta+1010.&chip=ICE1712+%2

8Envy24%29&module=ice1712

(Apache web site)

Apache web site, 2007-05-05: http://apache.org/

(Cycling ’74 web site)

Cycling ’74 web site, 2007-05-05: http://www.cycling74.com/products/maxmsp

(Cycling ’74 online store)

Cycling ’74 online store, 2007-05-05:

http://shopping.netsuite.com/s.nl/c.365211/it.A/id.327/.f

(DataPro web site)

DataPro web site, 2007-05-05: http://www.datapro.net/products/USE-350.html


-39-

(Debian web site)

Debian web site, 2007-05-05: http://www.debian.org/

(DewPlayer web site)

DewPlayer web site, 2007-05-06: http://www.alsacreations.fr/mp3-dewplayer.html

(Festival web site)

Festival web site, 2007-05-06: http://www.cstr.ed.ac.uk/projects/festival/

(File Thingie web site)

File Thingie web site, 2007-05-06: http://www.solitude.dk/filethingie/

(GEM manual)

GEM manual, 2007-05-05: http://gem.iem.at/manual/

(Imagemagick web site)

Imagemacick web site, 2007-05-05: http://www.imagemagick.org

(M-audio web site)

M-audio web site, 2007-05-07: http://www.m-audio.com/

(Microsoft web site)

Microsoft web site, 2007-05-05: http://msdn2.microsoft.com/en-us/library/aa362928.aspx

(PHP web site)

PHP web site, 2007-05-06: http://www.php.net/

(phpSysInfo web site)

phpSysInfo web site, 2007-05-05: http://phpsysinfo.sourceforge.net/

(Pure Data web site)

Pure Data web site, 2007-05-05: http://puredata.info/

(Python web site)

Python web site, 2007-05-06: http://python.org/

(Readanysf~ web site)

Readanysf~ web site, 2007-05-05: http://aug.ment.org/readanysf/

(Spamalot musical web site)

Spamalot musical web site, 2007-05-06: http://www.montypythonsspamalot.com/

(Smith, 2006)

Smith, 2006:Linux NFS-HOWTO, 2007-05-09: http://nfs.sourceforge.net/nfs-howto/

(TIC Corporation web site)

TIC Corporation web site, 2007-05-07:

http://www.ticcorp.com/Omni%20Sub%20Woofer%20GS50.htm


-40-

1.3 Supplementary reading

Johnson, Michael K. And Troan, Erik W.: Linux Application Development. Addison-Wesley.

ISBN: 0321219147. 2004

Lutz, Mark: Programming Python. 3rd

ed. O’Reily. ISBN: 9780596009250. 2006

Lutz, Mark and Ascher, David: Learning Python. 2nd

ed. O’Reilly. ISBN: 0596002815. 2004

Martelli, Alex: Python in a Nutshell. 2nd

ed. O’Reilly. ISBN: 0-596100469. 2006


-41-

2 Appendix: Term list This list provides an overview of terms and abbreviations used in the report.

Table 2. Term list

Term/abbreviation Explanation

Debian A distribution of GNU/Linux

NFS Network File System, a system developed allowing a client computer

to access files over a network. (RFC 3010)

ALSA Advanced Linux Sound Architecture, Linux kernel component

providing device drivers for sound cards.

MySQL SQL database server

Apache HTTP (web) server

RAID Redundant array of inexpensive/independent drives – data storage

scheme using multiple hard drives to store or multiply data among the

drives

APT Advanced Packaging Tool, or APT, is a package management system

used by Debian GNU/Linux and its derivatives. Enables easy and

automated installation and configuration of software.

GPL GNU General Public Licence, the most common Open Source license.

Bluegiga In this report Bluegiga is used as a short term for the WRAP Access

embedded Bluetooth server from the company Bluegiga Technologies

API Application Programming Interface

Python High level object oriented programming language, which emphasises

on ease of use and readability rather than execution time

Obexsender Preinstalled software on the Bluegiga WRAP Access Server for

Bluetooth OBEX profile file exchange

cron Time based scheduling system in UNIX-like operating systems

Pure Data (PD) A real-time graphical programming environment for audio processing

Max/MSP Max is a graphical development environment for music and multimedia

Flext C++ layer for cross platform development of externals for Max/MSP

and Pure Data

TONO A company that manage the performance rights for music work in

Norway

GEM Graphical environment for Multimedia. Object library for the sound

processing software Pure Data

Imagemagick A free software suit for image manipulation, display, supporting a wide

variety of formats.

PHP Programming language for developing dynamic web pages

CSS Cascading Style Sheets is used to describe the presentation of a markup

language (like HTML and XML)

http://en.wikipedia.org/wiki/Development_environment

http://en.wikipedia.org/wiki/Music

http://en.wikipedia.org/wiki/Multimedia


-42-

3 Appendix: CD content There has been made a CD which follows this report, and contains material relevant for the

project. This appendix lists all the content on the CD.

3.1 Software

The main program “Spamalot”

All the PD patches that have been created for use with Spamalot

Sound files for mixing.

The “copier” script used on the Bluegiga

Web site content

- File Thingie

- Guest book

- DewPlayer

3.2 Documentation

This report

Obexsender User Guide

WRAP Access Server User’s and Developer’s Guide


-43-

4 Appendix: Detailed configuration of the server This section focuses on the detailed configuration of the operating system and services.

4.1 General OS configuration

4.1.1 Partitions

The server is installed with a 400 GB hard drive for data, and a 250 GB for system files. The

system partition table is summarized below:

Disk 1 (250 GB):

Swap: 2 GB (Virtual memory)

/ 74 GB (System critical files, top most directory)

/tmp 37 GB (Temporary files)

/usr 28 GB (Non critical system files)

/srv 26 GB (Web site, NFS share)

/var 65 GB (logs, system files, web sites, and databases)

Disk 2 (400 GB):

Swap 2 GB (Virtual memory)

/home 365 GB (Data, user data)

The /home partition is to be used for the sound system (running as a dedicated user) and other

users of the system. The website is located in /srv/www.

4.1.2 Debian specific configuration of the system

The system was installed using the standard Debian installer with the X.Org X Window

System and the GNOME desktop environment. All needed software and services was

installed using the package managers aptitude or synaptic, which automatically downloads

and installs new software which is in the Debian repositories.

4.1.3 Installing software using DPKG and APT

The Debian package management system depends on DPGK, which is the system that allows

software to be put in packages, and contains information about what other software

(packages) each package depend on, and how to automatically configure it. The DPKG

system also asks the user to make decisions if needed.

The high level APT is used in conjunction with DPGK to manage the software on a Debian

system. APT maintains a list of all available software in the repositories it is configures to use

in the /etc/apt/sources.list file. APT also maintains a list of all software installed on the

system. This allows apt to automatically decide if the installed software is the newest, and if

not, download and install updates and upgrades. (APT is even capable of upgrading to new

major releases of the operating system, so that in many cases a Debian system may be

upgraded to a new major release without the need of rebooting.)

APT is used for installing and removing new software from the internet, using the database of

all available software. The traditional way of installing software with APT is by using the apt-

get system tool. This is now deprecated, and new tools like the text based aptitude or the

graphical Synaptic is used instead, but with the same functionality. Aptitude also supports the


-44-

same commands as apt-get, so that it may be used as a stand in replacement in many cases, in

addition to providing many new features.

If the package specified requires other packages, APT will automatically resolve which

packages is needed, and suggest to install those in addition to the one specified by the user.

Examples of use:

Installing a package (The text editor Vim in this example):

aptitude install vim

Installing several packages at the same time, by adding new packages to the line:

aptitude install vim xbill falconseye planetpenguin-racer

Removing a package

aptitude remove falconseye

Updating the APT database

aptitude update

Updating the system:

aptitude upgrade

Making a full upgrade of the system, including removing deprecated packages:

aptitude dist-upgrade

It is also possible to use already downloaded packages by installing them using the dpkg

software. This is also used to reconfigure a package. Details about APT, DPKG and all other

consol software and commands are available using the standard UNIX manual system (e.g.

“man aptitude” to learn how to use aptitude).

When discussing installation of other software later in this chapter, it is assumed that the

reader is familiar with software installation using aptitude after reading this section.

4.1.3.1 Non standard multimedia repositories for APT

Debian GNU/Linux has a strict policy on the license on the software that is included. It only

comes with software that is fully open source, and uses standards with no copy right issues

attached to it, like e.g. MP32. To allow better multimedia support, including windows codecs

and codecs which may be copyrighted, repositories from http://debian-multimedia.org/ vas

added.

Adding the new repositories is done by editing the /etc/apt/sources.list, and adding a line for

the new repositories. To allow packages from debian-multimedia.org, the following line is

added:

deb http://www.debian-multimedia.org etch main

In this line, “deb” specifies that this is compiled Debian packages, and not the other

alternative “source”, which is source code packages. The next part is the URL address of the

server. Then comes “etch” which is the name of the current version of Debian. This may be

any version that the server has packages for, or also relative names like “stable”, “testing” and

“unstable”. The last word “main” refers to the section the package is in. A server can separate

different packages into different sections. This is mainly used for the official Debian

packages; where main is the main repository which contains the standard packages. In

2 http://www.digi.no/php/art.php?id=371933


-45-

addition there are sections called “contrib” for unofficial packages, “nonfree” for non GPL

compatible licensed software and more.

To be able to confirm the integrity of the packages from debian-multimedia.org, the GPG key

package debian-multimedia-keyring must be installed. (“aptitude install debian-multimedia-

keyring”)

4.1.4 Network configuration

The server has two Ethernet network interface cards. One of the cards is used for connection

to the Internet, and the other is connected to the Bluegiga embedded Bluetooth server using a

crossover cable.

The 1 Gbps card on the main board is used for Internet connection. By choosing this as eth0

during the installation, this was configured to use DHCP. The other card, a Realtek PCI card,

is addressed as eth1. This order depends what is defined as the default card, and it is possible

to alter the order.

The configuration for eth0 in the configuration file /etc/network/interfaces looks like this:

# The primary network interface allow-hotplug eth0 iface eth0 inet dhcp

This specifies that hotplug of the cable is allowed; alternatively “auto” may be used before

eth0. The next line specifies to use DHCP for dynamic configuration of IP address, netmask

and DNS servers.

The card which is connected to the Bluegiga is configured with static IP settings by editing

/etc/network/interfaces, and adding the needed configuration lines:

# Dette grensesnittet er koblet til Bluegiga wrap allow-hotplug eth1 iface eth1 inet static address 192.168.1.1 netmask 255.255.255.0

This is the standard way of configuring network interfaces on Linux. In short, the first line is a

comment; the second line is identical with the second line in the configuration of eth0. The

third line specifies that the interface uses a static configuration, and configuration, and the last

two lines specifies the IP address and netmask.

It is also possible to configure the Network interfaces easily using the Network settings tool

provided by the GNOME desktop (Desktop -> Administration -> Networking).

4.2 Apache web server and PHP

4.2.1 Installation of Apace and PHP

Apache 2 and PHP 5 are installed from the default Debian repositories using aptitude. The

necessary packages are “apache2” and “php5”. These packages depend on all other necessary

packages, and thus by issuing e.g. “aptitude install apache2 php5”, all the needed packages for

Apache 2 and PHP 5 are installed.


-46-

4.2.2 Configuration of Apache

The main source of information about Apache configuration is (Eilertsen and Mikalsen,

2003).

The default configuration of Apache yields a working system. For this project the changes

needed is common configuration, like administrator e-mail, default page when the requested

document does not exist and so on. In addition the default server root for Apache on Debian is

/var/www, where as for this project it was decided to have all the network server files located

in /srv, thus the Apache document root will be /srv/www.

Also, there is a password protected directory in the document root folder, /srv/www/admin

(<address>/admin to the outside world), to contain system information and administration

tools.

4.2.2.1 Configuration of /etc/apache2/apache2.conf

The file /etc/apache2/apace2.conf is the mail configuration file of the Apache 2 web server.

By default this file has include statements that includes the virtual host configurations

(discussed later in this chapter) and the httpd.conf file which is for user configuration that one

might want to have in a separate file to distinguish between local adjustments and the standard

configuration. For this project the httpd.conf file is not used, as only minor configuration is

needed in the apace2.conf file.

To allow the information page that is displayed when a user requests a file which is not on the

server to have the same design as the rest of the web site, it is possible to specify the name of

the file in the apache2.conf file. This is done by commenting out a line in the file, so that it

reads:

ErrorDocument 404 /missing.html

This tells Apache to send the file specified to the client browser when the requested file is not

available. The path of the file is relative to the Apache document root.

The ServerToken option is used to specify the amount of information Apache supplies to the

clients in the HTTP response header. There are six levels of information, stretching from

“Full” which sends information about OS type and compiled in modules to “Prod” which send

no unnecessary information at all. The Apache default is “Full”, but for security reasons, the

server is configured with the “Minor” option. This is achieved by editing the line starting with

ServerToken, so that it reads:

ServerTokens Minor

4.2.2.2 Configuration of the sites-enabled files

To allow different addresses (e.g. domains or sub-domains) to point to different folders in

under the document root, Apache uses virtual hosts. It is necessary with at least one virtual

host. Different Linux distributions have slightly different approaches to this configuration.

Debian uses two folders under /etc/apache2/, one of which is “sites-available” and the other

“sites-enabled”.

To add a virtual host, a file for the virtual host is created in the sites-available directory. There

is one by that name by default, and this can easily be modified to fit with the wanted


-47-

configuration. The sites-available directory may contain many different virtual host, also

virtual hosts not in use. To enable a virtual host a symbolic link is created in the sites-enabled

folder, that point to the actual virtual host configuration file in the sites-available folder. (“ln –

s /etc/apache2/sites-available/default /etc/apache2/sites-enabled/000-default” creates a

symbolic link named 000-default that points to the corresponding file “default” in the sites-

available directory.)

The default file for the default virtual hosts is used as a starting point for configuring the

virtual hosts for the server. By editing the upper half of the file, the lower half may be used as

it is (from “ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/” and below).

The upper part of the configuration file is presented here, and the explanation of what is does

follows after the snippet.

NameVirtualHost * <VirtualHost *> ServerAdmin [email protected] DocumentRoot /srv/www/ <Directory /> Options FollowSymLinks AllowOverride AuthConfig Limit DirectoryIndex index.htm index.html index.HTML index.HTM index.php index.PHP </Directory> <Directory /srv/www/> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all # This directive allows us to have apache2's default start page # in /apache2-default/, but still have / go to the right place # RedirectMatch ^/$ /apache2-default/ </Directory> <Directory /srv/www/admin/> AllowOverride None Options FollowSymLinks AuthName "Beskyttet side for statistikk og administrativ informasjon" AuthType Basic AuthUserFile /etc/htpasswd Require user admin </Directory>

“NameVirtualHost *” specifies which address the virtual host in this file will accept

connections to. If all of the server addresses (may be one or many) is to be used, the wild card

* is used, as it is in this configuration. There are more alternatives here if name based virtual

hosts are used, but as this is not used in this project, it is not explained here. “<VirtualHost

*>” is linked to the same problem as the above setting, and also her, if no other virtual hot is

used, the wild card * which accepts connections to all of the servers addresses is used.

The “ServerAdmin” option is used to specify the Email address of the administrator; this is

supplied by Apache to clients if an error occurs.


-48-

With the “DocumentRoot” option, the path to the document root is specified, in this project

/srv/www/ is used.

Beneath the virtual host block, comes three Directory blocks. The first specifies the general

configuration and permissions.

The “Options” field contains only “FolloSymLinks”, which allows apache to send clients files

outside the document root folder, if there are symbolic links that points to those files in the

document root folder or subfolders.

“AllowOwerride” specifies what configuration may be put in a file named “.htaccess”, which

is read by Apache and its settings applies to the folder it is located in, and all sub folders. This

file is used for much of the same configuration as in the Directory block of the virtual host

configuration, but is possible to change by the users, and does not require Apache to restart in

order to apply changes. There is many options available here, refer to the Apache

documentation for details, but in essential, the options stretches from “All” to “None”.

The “DirectoryIndex” option specifies what files are to be sent to users when no file is

supplied. E.g. when one types the URL www.hekta.org in the address bar, the client does not

specify what file it wants, and the server then checks whether any of the files listed after the

“DirectoryIndex” option is present, and if so, the first file is sent back to the users. By

practice, this is usually index.php, index.html or alike. To allow PHP pages to be sent

automatically, “index.php index.PHP” was added to the end of the line.

The next indented block specifies the settings and permission of the document root folder.

This specifies a few more options, “Indexes” and “MultiViews”. These Indexes options

allows the server to return a formatted list of the files and directories in the directory specified

by the user, if none of the files specified under the “DirectoryIndex” option is found in the

specified folder.

No override is allowed (no use of .htaccess). The rest of this sub section is default, but the

three last lines are commented out, in order to allow the server to operate ordinary. These

lines are includes by default so that whenever someone connects to the Apache server before

it is configures, they will see a default information page by Apache. (Only the last line

performs this, the two lines above the last line is just comments)

The last section is for configuring the password protected directory in /srv/www/admin. The

“AuthName” is the text that appears in the box users has to type in username and password on

the client browser to access this folder. “AuthType” specifies the authentication type. This

option is left “Basic”, and there is only one other alternative (“Digest”). The “AuthUserFile”

option specifies the file where the encrypted password is stored, and the last line, containing

“Require user admin”, specifies that the username is admin. It is possible to add several users

with different passwords in the password file specified above.

The htpasswd command is used on the command line to create a password for the user. The

syntax is “htpasswd –c <password file> <username>”. When the command is issued, the

password is entered twice at the prompt. In this project the password file is /etc/htpasswd.


-49-

4.2.3 Configuration of PHP

The standard configuration of PHP 5 is working fine for this project, and no change in the

configuration is needed. Apache 2 is automatically configured to use PHP by APT when PHP

is installed.

The PHP 5 installation is very sparse, and any modules that are not part of the basic Debian

PHP system have to be installed separately. This is also fully automatic, and is handled by the

APT package management system.

4.3 Web based system information and administration tools

To allow easy access to system information and web server statistics, two system information

tools are installed and located in the password protected admin directory (/usr/www/admin/).

In addition, phpMyAdmin is used to provide graphical configuration and maintenance of the

MySQL server and databases.

There are tree useful web based software packages that is utilized by this project:

phpSysInfo – Displays detailed system information

Webalizer – Generates graphs and statistics about based on the Apache logs

phpMyAdmin – Web based administration tools for MySQL databases

4.3.1 Installation and configuration of phpSysInfo

phpSysInfo is installed by simply installing the phpsysinfo package. The default configuration

places phpSysInfo in /var/www, and not /srv/www which is in use by this projects server.

To change the configuration, remove the symbolic link named phpsysinfo in /var/www, and

add a new symbolic link by the same name in /srv/www/admin, and pointing it to

/usr/share/phpsysinfo. (This is outside the document root, and will only work when “Options

FollowSymlinks” is added in the virtual host configuration, as described in 4.2.2.2)

4.3.2 Installation and configuration of Webalizer

Webalizer is a single Debian package, and is obtained by installing the webalizer package.

Like with phpSysInfo, Webalizer by default assumes that /var/www is the document root.

To change this, /var/www/webalizer is moved to /srv/www/admin/webalizer. In adition, one

line the configuration file /etc/webalizer/webalizer.conf must be edited, so that webalizer

points to the correct directory. The line starting with “OutputDir” must be modified so that it

points to the correct output directory, thus looking like:

OutputDir /srv/www/admin/webalizer

With this configuration, Webalizer will automatically update the statistics, so that the

administrator always gets up to date statistics from Apache presented in a user friendly

manner.

4.3.3 Installation and configuration of phpMyAdmin

Like the other two web based tools, phpMyAdmin is installed and automatically configured

by using aptitude to install the phpmyadmin package.


-50-

To adapt it to this project, the only needed configuration is to ad a symbolic link in

/srv/www/admin (named e.g. phpmyadmin) that points to /usr/share/phpmyadmin/.

4.4 Network File System (NFS)

The source for this chapter is (Smith, 2006).

To allow the Bluegiga to copy files to the server, a NFS server must be installed.

4.4.1 Overview of the NFS system on the server

This part explains the system using the settings chosen by this project group, including user

name and location of files and directories, but much of this is optional, and can be changed

within the code of the main program and copier script.

Because of the insecure nature of NFS, the server has a separate network interface card

dedicated to the Bluegiga, using a cross over Twisted Pair Ethernet cable to connect them

together.

The following configuration is used:

Server IP-address: 192.168.1.1 (The network interface card that is connected to the Bluegiga)

Bluegiga IP-address: 192.168.1.2

Bluetooth file folder on server: /srv/bluetooth

Username for the user running the sound software: skulptur

4.4.2 Installation and configuration of the NFS server

The following section describes the configuration of the NFS server which is necessary to

allow Bluegiga to upload files.

Both the Bluegiga and the server are configured to be on the same network. E.g. using IP

addresses 192.168.1.1 for the server and 12.168.1.2 for the Bluegiga.

The server uses an ordinary out of the box configuration of the NFS kernel server (e.g.

installed with “aptitude install nfs-kernel-server”)

The folder for received files is located in /srv/bluetooth, and is owned by the user ownig the

Spamalot process. (“chown skulptur.skulptur /srv/Bluetooth” when “skulptur” is the

username.)

The following line is added to /etc/exports to share /srv/bluetooth:

/srv/bluetooth 192.168.1.2(rw,no_root_squash,sync,no_subtree_check)

This shares /srv/bluetooth with the specified IP address (the Bluegiga), and explicitly allows

the root user to connect. This is not the default behaviour, but it necessary to allow the wrap

box to write files and change permissions.

Generally with NFS it is best to disable connections from everybody, this is achieved by

adding the following lines to the /etc/hosts.deny file:

portmap:ALL lockd:ALL


-51-

mountd:ALL rquotad:ALL statd:ALL

To explicitly allow the Bluegiga box with IP 192.168.1.2, these lines is added to

/etc/hosts.allow:

portmap: 192.168.1.2 lockd: 192.168.1.2 rquotad: 192.168.1.2 mountd: 192.168.1.2 statd: 192.168.1.2

With this configuration the server only accepts connections from the IP address of the

Bluegiga, but the Bluegiga will have the needed root permissions on the shared directory.

4.5 MySQL database server

The MySQL database server is used for the web site guest book, and may also have other

usages in the future. MySQL have no need for configuration after installing the “mysql-

server” package, other than some simple security settings.

By default, the MySQL server requires no password for the root user. Of security reasons, a

password should be used. This is accomplished by logging in to MySQL as root by typing

“mysql –u root” on the command line, and then typing the following two lines

(“newpassword” must be substituted with the actual new password and host_name with the

server hostname):

mysql> SET PASSWORD FOR ''@'localhost' = PASSWORD('newpwd'); mysql> SET PASSWORD FOR ''@'host_name' = PASSWORD('newpwd');

4.6 Firestarter firewall

To block inbound traffic to all ports except those used by SSH and HTTP, the server uses a

firewall. At the core of the system, is the standard Linux framework for filtering packages

Netfilter. To allow easy a flexible configuration, all configurations is performed using the

graphical software Firestarter. Firestarter provides a graphical interface for setting firewall

rules and monitoring the network traffic.

To confirm that the firewall is working properly, the system has been port scanned from a

computer on the Internet using the nessus vulnerability scanner.

4.7 ALSA – Advanced Linux Sound Architecture

The source of information for this chapter is (ALSA web site).

GNU/Linux has good support for professional sound cards using ALSA - the Advanced Linux

Sound Architecture. Few hardware producers release official drivers for Linux, but the free

software community is continuously releasing well working drivers for all types of hardware.

Sound cards are no exception, but FireWire based sound cards are not supported by the time

this project was carried out.

This limited the options in sound cards, and left the project group with quite few alternatives.

In the end the M-Audio delta 1010 was chosen, because it was an old card which is perfectly


-52-

supported by ALSA, and with many success stories on the Internet, which gave confidence to

the choice.

4.7.1 Configuration of M-Audio Delta 1010 with ALSA

The M-Audio Delta 1010 sound card uses the ICE1712 (Envy24) chipset, and is fully

supported by the snd-ice1712 ALSA Linux kernel module.

ALSA is installed automatically on most new GNU/Linux distributions if a sound card is

detected. The needed packages are alsa-base, alsa-oss, alsa-utils, alsa-tools, and some other

library packages which is automatically installed by APT when selecting those three.

In addition the alsa-tools-gui is very useful as it contains the envy24control graphical mixer

developed for cards based on the ICE1712 chipset used by M-Audio Delta 1010. This mixer

is designed to resemble the official M-Audio mixer for Mac OS and Microsoft Windows in

look and functionality.

The configuration of Delta 1010 in Debian is covered in detail at the official ALSA web site,

and the sound card is configured exactly as described there.

After installing the needed ALSA packages, the needed kernel modules are loaded by issuing

the following command as root: “modprobe snd-ice1712;modprobe snd-pcm-oss;modprobe

snd-mixer-oss;modprobe snd-seq-oss”

To make the correct ALSA kernel modules load automatically on every boot, this

configuration should be made in a separate file in the /etc/modutils/ directory on Debian

system. This project has created a file /etc/modutils/alsa, which contains the following:

# ALSA portion alias char-major-116 snd alias snd-card-0 snd-ice1712 # module options should go here # OSS/Free portion alias char-major-14 soundcore alias sound-slot-0 snd-card-0 # card #1 alias sound-service-0-0 snd-mixer-oss alias sound-service-0-1 snd-seq-oss alias sound-service-0-3 snd-pcm-oss alias sound-service-0-8 snd-seq-oss alias sound-service-0-12 snd-pcm-oss

This configuration also sets up ALSA’s OSS (Open Sound System) emulation to allow

software which is written to use the simpler OSS API to play sound, in addition to specify

which modules is to be used for the sound card.

With the above configuration, the sound card has the basic functionality working, but the

channels will not work separately as they have to do for this project. It is possible to configure

ALSA in extreme details by creating a file named “asoundrc” in the /etc/ directory. The

asaoundrc file should consist of a list of every available sound card on the system, and setting

and configuration options for the cards. This file is disregarded by ALSA if the users have put


-53-

a file named “.asoundrc” in there home directory, where the different users may put there own

setting.

The following file is used to allow the use of Delta 1010 with just a simple configuration:

pcm.ice1712 { type hw card 0 } ctl.ice1712 { type hw card 0 }

This setting does not use software mixing by default, making it impossible to use more than

one sound producing application at a time. This is no problem for this project, and therfor the

configuration is kept as simple as possible.

4.7.2 User configuration

It is possible to work around the problem with only one application being able to use the

sound card at the same time using a software sound mixer like ESD – the Enlightenment

Sound Daemon, which is used by several desktop systems, including GNOME which is in use

on the server. This feature is mainly designed to be used with simple sound cards without

these possibilities in hardware, but is widely used also with modern sound cards because of its

hardware neutrality, which makes it easy to use and configure. However, ESD is not desirable

in this project, as it is desirable that the sound processing software to relate to ALSA directly.

To avoid problems it is vitally important that ESD or other software mixers are disabled. In

many GNOME installations ESD is enabled by default. Disabling this is easily done by

removing the mark for “Enable software sound mixing (ESD)” under the Desktop ->

Preferences -> Sound menu when logged in graphically.

4.8 Other software

This section lists up other important software packages used by the project, mainly the

software that is needed by the main program “Spamalot” and the rest of the sound processing

system. A lot of other software is also installed for different reasons, but it would neither be

interesting nor environmental friendly to use paper to list all the software that is installed.

The list is organised so that the Debian package name is listed first. The package names are

similar to the name of the program. The use of the software is explained in a short manner.

Software used for real time audio processing:

puredata – The Pure Data real-time sound processing software

pd-zexy – Addon objects for PD

pd-aubio – PD objects for sound processing (e.g. vocoder, pitch detection and more)

gem – Graphics Environment for Multimedia, a loadable library for PD

Software used by the main program “Spamalot”:

python – The Python programming language runtime files


-54-

lame – MP3 encoder and decoder used to decode MP3 files

vorbies-tools – Contains oggdec which is used to decode OGG Vorbies files

faad – Free Advanced Audio Decoder used for decoding MP4/AAC files

ffmpeg – Used to decode AMR files (used by mobile phone Dictaphones)

mplayer – Multimediaplayer, used to decode WMA files using:

w32codecs – Windows codec’s used by mplayer to decode WMA files (and more)

festival – Speech synthesis system, includes the text2wave Festival script

flac – Decoder for FLAC audio files

imagemagick – Image processing tool used by Spamalot to convert and resize images.

Other software, like DrPython, have been used during the development process, but is not

needed to use or maintain the system.

4.9 Maintenance

During ordinary use, the server only needs the administrator to install security updates and

make backups. In addition all the regular maintenance routines apply for this server. The

system may have problems not discovered during the project period testing, which makes it

important for the administrator to check the system ones in a while to see if everything is

working as it should.

4.9.1 Security updates

The system may be updated graphically using the Update manager (on the GNOME desktop:

Desktop - > Administration -> Update manager), or by using aptitude. See 4.1.3 for details

about package management.

When logged in to GNOME, the Update manager will regularly check for updates, and inform

the users about new updates in the status field to the left of the clock in the menu bar on top of

the screen.

If aptitude is used, which is most handy when administrating the server from a remote

location over SSH, the procedure is to first update the local APT database using “aptitude

update”, and then installing updates with “aptitude upgrade”. If some packages are left out

because of compatibility issues, it may be necessary to use “aptitude dist-upgrade”.

4.9.2 Backup

There has not been made a backup system for the server. The reason for this is partly because

of time issues, but also because it is difficult for the project group to know what type of

backup system is wanted where the sculpture is going to be placed, as this may depend on the

rest of the backup system at the location, and the preferences of the future administrator.

The artist Samir M’Kadmi’s main concern is losing the art music files that are uploaded by

users using the web interface. These files are located under /home/skulptur/kunstmusikk. The

project group suggests that a USB hard drive is used to back up the files, by manually copying

them over. This may be easily done graphically on the GNOME desktop by the administrator.

Another possibility is for the administrator to back up the files over the network manually by

using FTP over SSH (SFTP). This however is a manual system and yields no easy way of

backing up the rest of the system. It would be preferable with a backup system for the whole

file system, including system files, but that was considered to be out the scope for this project.


-55-

The following list explains the process of backup with USB disks in detail:

1. Log in graphically as the user “skulptur”

2. Insert the USB drive in the USB connection in the front panel of the server

3. After a few seconds a icon for the USB drive appears on the desktop, and a windows

with the content of the files on the USB drive

4. Make a new folder by right clicking inside the window of the USB hard drive and

selecting “Create Folder”.

5. Open the home folder by double clicking on “skulptur’s Home” on the desktop. Use

the mouse to drag the art music folder named “kunstmusikk” from that window over

to the newly created folder on the USB drive.

6. Wait until all the files are copied, and unmount the USB drive by right clicking on its

icon on the desktop, and selecting “Unmount Volume”

7. Now it is safe to remove the cable, and the backup is stored on the USB drive.


-56-

5 Appendix: Configuration of the Bluetooth system To allow the Bluegiga to copy files to the server, a NFS server must be installed. In this

appendix the installation and configuration of the NFS server is explained. See (Smith, 2006)

for details. The following part is written as documentation of the system, but is also intended

to be helpful as a “sandwich list” on how to get the system up and running.

This part explains the system using the settings chosen by this project group, including user

name and location of files and directories, but this is optional and can be changed within the

code of the main program and copier script. The configuration is in the upper section of the

two programs, and is self explainable.

The following configuration is used:

Server IP-address: 192.168.1.1 (This applies for the NIC that is connected to the Bluegiga)

Bluegiga IP-address: 192.168.1.2

The NFS configuration of the server is described in detail in appendix 4.4.

5.1 Configuration of the Bluegiga WRAP Access Server

The general configuration of the Bluegiga is not documented in this report, as is completely

documented in (Bluegiga, 2006 b). By following the documentation, the Bluegiga is

configured with most applications not necessary turned off, but with Bluetooth object transfer

(OBEX), Obexsender and administrative services such as SSH and web server enabled. The

guide also describes how to configure the network interface, change passwords and other

administrative tasks. Configuration of Bluetooth friendly name and other Obexsender specific

options is covered in the Obexsender User Guide.

The rest of this section focuses on the more customised parts of the configuration. This

includes configuration of the Obexsender and a file transfer script.

5.1.1 Obexsender

Obexsender is configured to automatically send a file to all new Bluetooth units in proximity.

This is done by adding a “file /usr/local/obexsender/instruksjoner.txt” on a separate line in the

configuration file, /etc/obexsender.conf. This then pushes the specified file to all new units.

The list of units that have received the file can be stored ones in a while, so that the unit

remembers it even if it is rebooted, and this is done by adding a line with:

“dumpdelay 86400”

The number specifies the interval in seconds between each time the file is saved. This number

must be quite large in order to avoid burning the Flash memory by repeatedly writing to the

same memory blocks (Bluegiga, 2006 a).

There are also other options like “tester” and “ignore” which are used to specify units to be

ignored and units that should receive files even if it has received the same file in the past.

It is possible to specify the folder where incoming files are stored, but for the current version

of the firmware this is ignored, and the default location is always used even if the

configuration says otherwise. Or else this could have been used to save the files directly to the

shared drive on the server. The option for this is obexdir, and it is by default set to /tmp/obex.


-57-

The rest of the configuration is identical with the default obexsender.conf file. The file has a

lot of comments and is self explainable. There are several other features that may be

interesting if the project is carried on, like the possibilities to analyse files and send a response

back to the user based on the content or type of the received file.

With the Obexsender system configured advertisement is being sent and files are received to

the /tmp/obex directory. This is within the /tmp partition, which have about 18 MB of free

space. If the file being received is too big, either because other are uploading files at the same

time, or one file itself exceeds the amount of free space, the file will be rejected at ones when

someone tries to push the file.

5.2 Access to the server file system

Configuration of NFS on the Bluegiga is done in standard Linux manner, adding a line for the

NFS share on the server in /etc/fstab. If the server goes down and get up again there is no

problem. If the server is down while Bluegiga is booted the system is not mounted however,

and the easiest way to get it up again is to reboot the Bluegiga after the server is back on track

using the “reboot” command from the command line, or the web interface.

To mount the NFS drive the following line is located in /etc/fstab:

192.168.1.1:/srv/bluetooth /mnt/nfs nfs nolock 0 0

The “nolock” option is not necessary but is added for clarity. The minimalist Linux system

running on the Bluegiga does not support some of the newest features NFS has to offer, such

as file locking. This is in fact a problem, making the server unable to determine whether a file

is still being written or not. To compensate for this, the software controlling the sound system

have to wait a small amount of time before reading the file, so that it has been transferred

completely.

The NFS partition is mounted on every boot by a line in /etc/rc.d/rc.local. This is described in

5.2.2.

5.2.1 Transfer script

A script has been created to rename, time stamp and copy the files to the server, in addition to

changing permissions of the files transferred (appendix 6). This is located in /usr/local/bin/

and is named “copier”. (The script is made executable which “chmod +x

/usr/local/bin/copier”)

The script is executed every time a file is received, this is done by configuring the Bluetooth

system to do so, by adding the following line in /etc/Bluetooth.conf (Bluegiga, 2006 a):

SET BLUETOOTH LISTEN 3 "/usr/sbin/obexserver --bdaddr $b --prefix $b-$P- --fork /usr/local/bin/copier" 110

In essence the line causes the Obexsender software to start the copier script with the filename,

Bluetooth address of the sender and some more information as parameters. At the moment,

only the filename is relevant for the copier script, but it may be interesting to have the

Bluetooth address to be able to add new features in the future.

The copier script mainly performs the following tasks:


-58-

Extracts the suffix from the file name

Ads a time stamp to the file

Copies the file with filename <UNIX-time>.<suffix> to the specified output folder,

renaming the file by adding an additional number if a file with the same name exists.

Changes the owner of the file to the one specified in the script

The copier script is configured in the top of the file, and has options for output folder, user ID

and group ID of the user that is going to be owner of the file. This must be the same user that

is used for running the main program. The copier script, and also the main program Spamalot,

are written with variable names and comments in Norwegian (The variable names listed in the

list refer to the output folder, user ID and group ID).

The configuration used is listed below:

UTMAPPE="/mnt/nfs" BRUKER="1005" # Bruker ID til den man ønsker skal bli eier av filen GRUPPE="1005" # Gruppe ID til den man ønsker skal bli eier av filen

The output folder is the folder where the NFS share from the server is mounted, which in

reality means that copying to that folder is equivalent to transferring the file to the server’s

hard drive.

If the server is down, or by some reason is not connected to the Bluegiga over the Ethernet

cable, the Bluegiga will not be able to mount the NFS share. If so happens, the Bluegiga

should be rebooted (by typing “reboot” using SSH) when the server is up again, alternatively

the NFS partition may be mounted by issuing “mount /mnt/nfs” on the command line.

If however, the server is rebooted while it is connected to the Bluegiga, the Bluegiga stores

the files locally, and when connection is established, automatically transfers the files to the

server, so that no manual interference is required.

5.2.1.1 Details about the “copier” script

The copier script is a UNIX shell script. The shell used on the Bluegiga, as most other modern

GNU/Linux distributions is Bash, but the script is written to be compatible with the older

Bourn Shell (sh) as well.

A shell script is used because it provides easy access to all the tools needed to transfer the

files, as it may be used to control all consol based tools. Linux comes with many tools by

default, one of which is sed, a stream based text editor for automatically manipulating text,

which is used by the copier script.

Shell scripts are well suited for small tasks, but the ease of development comes at the cost of

execution time. In addition, being a scripting language and not a real programming language,

the features are somewhat limited. But for the task in hand, shell scripts were the obvious

choice.

The whole copier script is appendix 6, but a few lines will be explained here, to provide some

information about how the script is functioning.


-59-

5.2.1.2 Syntax of the “copier” script

The syntax of a Linux shell script has more in common with an ordinary programming

language, than e.g. DOS BAT-files. This is exploited in the copier script. Below is a small

section of the copier script code:

while [ $EKSISTERER == 0 ] && [ $I -le 5 ]; do I=$(( $I + 1 )) if [ ! -e "${UTMAPPE}/${UTFIL}" ]; then EKSISTERER=1 /bin/cp "$1" "${UTMAPPE}/${UTFIL}" /bin/chown "${BRUKER}.${GRUPPE}" "${UTMAPPE}/${UTFIL}" else

This snippet is from the code which copies the file to the destination directory if a file with

the same name does not exist (only parts of the code is showed here as an example). If a file

with the same name exists, the file name is changes by adding a number (1, 2, 3…) to the end

of the file name, but before the suffix. The script only tries with 5 different names, if a file

still exists with the same name, the file is deleted, and nothing is done.

5.2.1.3 Filtering text with sed

The suffix of the file name is extracted from the information provided by the Bluetooth

system when calling the copier script by these two lines:

ETTERNAVN=ècho $1 | sed 's/^.*\.//'` ETTERNAVN=ècho $ETTERNAVN | /bin/sed 's/-....$//'`

The resulting string consists of only the suffix of the file name. (E.g. if the starting string is

“picture.jpeg” the result is “jpeg”)

5.2.2 Automated tasks on every boot

In order to clean up the Obexsender folder if it is filled up with files before turning off or

rebooting the Bluegiga, all files in the folder is deleted on every boot by adding a few lines in

/etc/rc.d/rc.local which is executed on every boot. This file is also used to mount the NFS

share from the main server. The lines doing this job are listed below, and are self explainable.

# Sletter alle filer i /tmp/obex tilfelle det har blitt liggende # noen igjen ved en feil: rm /tmp/obex/* rm /tmp/obex/.* # Her kopieres "visittkortet" tilbake til obex-mappen # viktig: heav forstås at ønsket vcf-fil må ligge i /usr/local/obexsender cp /usr/local/obexsender/default.vcf /tmp/obex/ # Monterer NSF partisjonen mount /mnt/nfs

There is also a line to copy a vCard file to the obex directory on every boot. This file is

provided to all Bluetooth devices that specifically requests it. The full path of the file is

/usr/local/obexsender/default.vcf, and it should be updated with the address of the web site

and contact information of the administrator.


-60-

5.2.3 Automatic reboot

It is possible to reboot the Bluegiga every night at a specific time using cron, the standard

UNIX daemon for scheduling tasks. This is trivial to configure, and have been tested in the

lab, and found effective. (The Bluegiga is able to reboot when not responding, and when it

comes up again, it is working as it should).

cron is activated by default on the Bluegiga, but may be turned on or off by using the web

interface.

Using the command “crontab -e -u root” will open the VI editor allowing new tasks to be

scheduled. By inserting the line below a reboot is scheduled for every night at 04:00.

0 4 * * * reboot > /tmp/reboot.out 2>/tmp/reboot.err

This report will not explain cron in details. Basically there are five fields in front of the

command that is to be executed, which is used to specify at which date and time the job is

scheduled:

1 minute (0-59)

2 hour (0-23)

3 day of month (1-31)

4 month (1-12, or name such as jan, feb, etc)

5 day of week ( 0-6(6 = Sunday) or name such as mon, tue, etc)

By using the wildcard * every instance is matched. E.g. the example above, used for rebooting

the Bluegiga will be executed at every time the minutes is 0, hours are 4, but for all instances

of day and month.

By the end of the project, cron was configured to automatically reboot the Bluegiga every 24

hours.


-61-

6 Appendix: “copier” script – full listing #!/bin/bash # Skal kalles fra obexsender: --fork /usr/local/bin/copier # Dette kan gjoeres med kommandoen under som skrives inn i /etc/bluetooth.conf: # SET BLUETOOTH LISTEN 3 "/usr/sbin/obexserver --bdaddr $b --prefix $b-$P- --fork /usr/local/bin/copier" 110 # Velg utmappe her, denne maa eksistere pÃ¥ forhÃ¥nd UTMAPPE="/mnt/nfs" BRUKER="1005" # Bruker ID til den man ønsker skal bli eier av filen GRUPPE="1005" # Gruppe ID til den man ønsker skal bli eier av filen # Filtrerer ut filtypen (.etternavn) ETTERNAVN=ècho $1 | sed 's/^.*\.//'` ETTERNAVN=ècho $ETTERNAVN | /bin/sed 's/-....$//'` # Fjerner noe rart etter navnet DATOSTEMPEL=`/bin/date "+%s"` # Antall sekunder etter 1. januar 1970 UTFIL="${DATOSTEMPEL}.${ETTERNAVN}" EKSISTERER=0 # Settes lik null I=0 # Tellevariabel while [ $EKSISTERER == 0 ] && [ $I -le 5 ]; # Fortsett sÃ¥ lenge $EKSISTERER er null, men maks 5 ganger. do I=$(( $I + 1 )) # Inkrimenterer I if [ ! -e "${UTMAPPE}/${UTFIL}" ]; then EKSISTERER=1 /bin/cp "$1" "${UTMAPPE}/${UTFIL}" /bin/chown "${BRUKER}.${GRUPPE}" "${UTMAPPE}/${UTFIL}" else if [ $I == 1 ]; then FORNAVN="${FORNAVN}_1" # Legger nummeret til UTFIL UTFIL="${FORNAVN}.${ETTERNAVN}" else FORNAVN=ècho $FORNAVN | sed 's/..$//'` # Fjerner de to siste tegnene i UTFIL FORNAVN="${FORNAVN}_${I}" # Legger nummeret til UTFILet UTFIL="${FORNAVN}.${ETTERNAVN}" fi fi done /bin/rm "$1" # Sletter den orginale filen (rydder opp)


-62-

7 Appendix: More about Pure Data

7.1 Manner of operation in Pure Data

7.1.1 PD main window

When Pure Data is running, the PD main window will show as in

figure 9, and possibly one or more "patches" (Pure Data web site). Each open document has

one main window and any number of sub-windows. The sub-windows can be opened and

closed but are always running whether it is visible or not.

Figure 9. Pd main window

In the PD main window there are peak level and clip indicators for audio input and output;

these report peak levels over all input and all output channels. The peak meters can be turned

on and off using the control at lower left. At lower right is a control that turns audio

processing on and off globally. Turning audio off stops the computation and relinquishes any

audio devices PD is using. When audio is on, PD is computing audio samples in real time

according to whatever patches you have open (whether they are visible or not). The DIO

(Digital I/O) error indicator flashes if there is a synchronization error for audio input or

output. When clicking the "DIO errors" button a list of recent errors will be displayed. This

indicator should turn red whenever the computation runs late. The bottom part of the Pd

window is an area for printout from objects in patches, and/or for messages from Pd itself.

7.2 Pd patches

Figure 10 is an example of a simple patch.


-63-

Figure 10. PD patch

Pd patches can have four types of boxes: object, message, GUI, and comment. Figure 10

shows, from the top, a message box, an object box and a number box. Also, pointing at these

boxes, three comments.

7.2.1 Object boxes

Objects are made by typing text into the object boxes. The text is divided into atoms separated

by white space. The first atom specifies what type of object PD will make, and the other

atoms, called creation arguments, tell PD how to initialize the object. In the example in Figure

10 the object box with "+ 13" in it, is a simple addition of the number 13 to the number 21, as

displayed in the message box. The message box, when clicked, sends the message "21" to an

object box which adds 13 to it, and the result, "34" will be displayed in the number box.

The text typed into an object box determines how many and what kinds of inlets and outlets

the object will have, since all objects has a certain function. If you right-click on your mouse

in any PD patch a complete list of all objects will pop up. These objects can be anything from

a simple addition as in figure 10 or more complex functions, like for instance a fast Fourier

transform. If you retype the text in an object box, the old one is discarded and a new one is

created, using the new creation arguments.

7.2.2 Message boxes

Message boxes interpret the text as a message to send whenever the box is activated (by an

incoming message or with the mouse.) The message may be sent many times while the patch

is running (as opposed to object boxes whose message is used once to create the object).

Instead of going straight to PD, the message box's message (or messages) goes either to the

box's outlet or to other specified receiving objects. A special type of "content-less" message

called a bang is used to initiate events and push data into flowing, much like pushing a button.

7.2.3 GUI boxes

The third box shown in figure 10 is a GUI ("graphical user interface") box. GUI boxes come

in many forms including number boxes (as in this example), toggles, sliders, and so on.

Whereas the appearance of an object or message box is static when a patch is running, a

number box's contents (the text) changes to reflect the current value held by the box. The

number boxes can also be used as a control by clicking and dragging up and down, or by

typing values in it.

7.2.4 Playing audio in PD

Pure Data’s native objects range from the basic mathematical, logical, and bitwise operators

found in every programming language, to general and specialized audio-rate DSP functions.

The DSP functions (audio functions) are always designated by a tilde (~) symbol. This means

that whenever an object box is designated with a tilde, the audio signal can connect directly,

given that the object is an actual object. In example there is an object called "inlet", and also

one called "inlet~", where the first one is an object for mathematical, logical or bitwise

operations, and the second one is for audio signals.

http://en.wikipedia.org/wiki/Mathematical_operator

http://en.wikipedia.org/wiki/Logical_operator

http://en.wikipedia.org/wiki/Bitwise_operator


-64-

Other typical "audio objects" in PD is for instance wavetable oscillators, the fft~ (fast Fourier

transform), and a range of standard filters.

7.3 PD main program sub patches

In this section all the sub patches and controls in the 3D sculpture’s main patch are described.

7.3.1 Open audio file patch

The open audio file patch at the top of the main patch is a sub patch where the Bluetooth file

is opened. The path for the Bluetooth files has to be /tmp/lydfil.wav since all the incoming

files from mobile phones will be placed her after conversion.

Figure 11. Open audio file sub patch

In figure 11 the open file patch is shown. The "loadbang" object is much like a "bang"

message (used to initiate events and push data into flowing, much like pushing a button)

except that gives a "bang" whenever the patch is loaded. The "loadbang" object is connected

to 4 boxes, and the first to connections (from the left) with the intention of open the Bluetooth

file. The "del 500" box is a delay of 500 ms before the signal push a "1" into the "readsf~"

object. There have to be a delay on the "loadbang" object to get PD to comprehend that the

"1" message was pushed after the "open" message. This is a usual procedure for opening a

sound file.

The third connection from the "loadbang" object goes to a message box which includes 4

preset values;

"pd dsp 1" turn on audio globally – the "compute audio" function in the main window

(see 7.1.1) is switched on.

"start bang" sends a band to the channel changer sub patch, this will be particularly

described in 7.3.10 (Channel changer patch).

"rolloff 500" presets the rolloff frequency on the high pass filters in the filter control

patch (see 7.3.11).

"volume 80" presets the volume control (0 minimum and 100 is maximum) to 80%

(see 7.3.11)

The fourth connection from the "loadbang" object connects to a delay object with 60000 mili-

seconds (1 minute) delay. This is the box that specifies the playback time before PD closes

http://en.wikipedia.org/wiki/Fast_Fourier_Transform

http://en.wikipedia.org/wiki/Filter_design


-65-

down, and can be changed by varying the number after "del". If the sound file is shorter than

one minute PD will run out when the file ends, because of the connection between the

"readsf~" object and the "pd quit 0" message.

7.3.2 “outlet~” and “inlet~” objects

The "outlet~" and "inlet~" (which will show up later) objects, are as the names are saying

input and output connections for audio. In this systems case they are mostly used as I/O from

sub patches. If for instance two "outlet~" objects are placed in a sub patch, the sub patch box

(designated with "pd subpatch") will get two output connections at the bottom. To control

which output is which output, Pure Data assign the connections from where the boxes are

placed in the sub patch window. This means that if there is to outlets, the one at the left will

correspond to the left output on the sub patch box.

7.3.3 Reverb patch

Reverberation is the persistence of sound in a particular space after the original sound is

removed. When sound is produced in a space, a large number of echoes build up and then

slowly decay as the sound is absorbed by the walls and air, creating reverberation, or reverb.

Figure 12. Reverb sub patch

The reverb patch is a much used audio effect in this project, since it is a very usable effect.

There is only to parameters to adjust; reverb and decay. The reverb adjusts the amount of

"roomsize" and the decay indicates how long the reverb can be heard after the input stop.

The parameters can be changed in many ways. In figure 12 the decay is static at 0.6. Value 6

is sent to the "r decay" ("r" stands for read from "decay") when the patch is loaded

("loadbang" push the message "decay 6" to "r decay"). Since the decay parameter is very

sensitive it is multiplied with "0.1", and that is also why this parameter is static. It should not

be adjusted higher than 0.8, to avoid that the sound processing gets very noisy. The number

http://en.wikipedia.org/wiki/Sound

http://en.wikipedia.org/wiki/Echo


-66-

box for the decay is actually restricted between 0 and 0.8, so this should not be a problem.

After some experimentation static decay showed off to give better sound result then varying

decay.

On the other hand the reverb parameter is dynamic. As shown in figure 12, this has been

solved by using a metronome, "metro 6000", which "bangs" every sixth second (creation

argument initializes rate in msec). The metronome push a "bang" to an object called

"random", which counts between 0 and 500 (by using creation argument 500). From there on

the "random" object sends a random number between 0 and 500 to the reverb parameter.

The "delwrite~" and "delread~" objects are described in 7.3.6 (Delay patch)

7.3.4 Fast Fourier transform patch

The Fast Fourier transform patch is maybe the simplest patch, although it should have been

modified and explored further if there had been time left.

Figure 13. Fast Fourier transform patch

The FFT object analysis the input signal (audio file) to find the spectral components. The

spectral components form a vector which is sent to its output. This vector can be played out

directly. In this system it is more or less used as a noise source which follows the beat in the

sound file. To reduce some of the high frequencies a one-pole low pass filter is used before

the outlet.

7.3.5 Multiplying oscillator patch

The multiplying oscillator patch was not highly prioritized during the exploration, but it

showed off to give a pretty good, or at least, special effect in the sound picture.


-67-

Figure 14. Multiplying oscillator sub patch

As shown in figure 14 it is a saw-tooth oscillator ("phasor~") multiplied with the Bluetooth

file, which comes from the "inlet~". In this example the frequency of the saw-tooth oscillator

is varying between 1000 Hz and 7000 Hz. The metronome acts like the one described in 7.3.3

(Reverb patch), except that to force the frequency from 1000 Hz and higher, an addition of

1000 has been implied.

Another oscillators also usable is the sine oscillator ("osc~").

7.3.6 Delay patch

The delay patch is a simple delay of 1 second between every channel. As shown in figure 15

channel 1 starts with 1 second delay, channel 2 starts with 2 seconds delay and so on.

Figure 15. Delay sub patch

"delwrite~" allocates memory for a delay line and writes an audio signal into it. "delread~"

objects with the same name read from the delay line. First argument is the name of delay line,

and the second argument is the length of delay line in msec (maximum delay time).

It is possible to use only some of the delay channels, simply by only routing the wanted delay

channels to the output (either a channel changer or filter control) of the 3D sculpture’s main

patch. For instance if a 3 second delay is wanted between channel 1 and channel 6, draw a

connection (in the main patch) between the third output (from the bottom left) on the "pd

DELAY" box to the sixth input (from the top left) on the "pd FILTER_CONTROL") box.


-68-

Also route, from the "pd OPEN_FILE" output to the delay box input, and also to the first

input on the "pd FILTER_CONTROL".

7.3.7 Add art music patch

The add art music patch is not an audio effect on the original Bluetooth file. This is a patch

mutual to the open audio file patch and it adds art music, approved by the artist, to the file

sent from Bluetooth. This art music has the same options as the Bluetooth file, except that it

has not been implemented to route this through the pitch shifter (can easy be implemented at a

later point).

Figure 16. Add art music sub patch

All these mixing files are placed in the catalogue /home/skulptur/blandelyder. Some of the

patches are made with an even more dominant art file, in the sound picture, then the Bluetooth

file itself. The manner of operation in this patch is the same as described in 7.3.1 (Open audio

file patch).

7.3.8 Pitch shifter patch

The pitch shifter is a more complicated sub patch that showed off to be a very important audio

effect, with lot of opportunities.


-69-

Figure 17. Pitch shifter sub patch

The pitch shifter was an example that was in the PD standard package, and following are

some details that were in the example:

This is a classic rotating-tape-head style pitch shifter using the vd~ variable delay

object. There are two moving tape heads, each of which is loudest at the middle of its

trajectory, and enveloped out at the moment it has to jump back (or forward) to start

another scratch. Most of the brain work is in computing how fast the tape heads have

to move to get the desired transposition.

The "window size" is the total trajectory of the read points in the delay line, in

milliseconds. The delay times are controlled by a phasor~ object. The second delay

time, 180 degrees out of phase from the first one, is computed using the "wrap" object.

The cos~ objects compute the fadein and fadeout of the two delay line outputs. They

each traverse the positive half of the cosine waveform (phase -0.25 to +0.25) over the

time the phase goes from one end to the other.

Parameters adjusted in the 20 patches are the "transposition", "window size" and "delay". In

figure 17 these parameters are preset with a "loadbang" (lower right). There has also been

some experimenting of using a random varying pitch, with a "metro" object. This hasn’t been

used in any of the patches. Instead, a counter has been made that like in Figure 18.


-70-

Figure 18. PD counter sub patch

The "pd counter" sub patch counts from 0 to 1 and back, in 20 seconds. After 5 seconds it

starts again. To adjust this to the "transposition" (pitch) parameter it is multiplied with 50. As

shown in figure 17 the counter is not connected to the "transposition", but it is available, and

has been used in some of the final 20 patches.

The pitch shifter got even one more sub patch in it. This is a patch where a limited piece of

the sound file is read into an array, with the use of an object called "soundfiler". Compared

with the "readsf~" in the "OPEN_FILE" sub patch, which reads a sound file into its signal

output. So, the pitch shifter itself needs to open the Bluetooth file and this file is specified in

the "test-input" sub patch, as shown in figure 19.

Figure 19. Pitch shifter reads sound file into an array

As shown, the path of this file is the same as the path in the open audio file patch. One of the

benefits with reading an audio file into an array is that it is possible to change its sample rate.


-71-

Like in figure 19 the sample rate is varied by changing the number in the message box (See

change sample rate).

The "soundfiler" object only reads 4000 000 samples of the sound file. When using sample

rate 44100 Hz the playback time will be ca. 90 seconds. This means that if the sample rate is

decreased, the play back time will increase. The pitch shifter plays in a loop, which means

that when the playback time has ended, it starts all over again.

7.3.9 Timbre stamp patch

The timbre stamp patch can be very much compared with the add art music patch, since the

sound that it produces sounds more or less like the "control source" file (art music file), unless

that it is melted together with the Bluetooth file. This means that if for instance the "control

source" is a talking voice, it is possible to hear the melody of the Bluetooth file in it.

Figure 20. Timbre stamp sub patch

The timbre stamp is a Fourier-based "vocoder"3, that was found in the audio examples that

follows the PD download package. It is a very complex example, and got even 5 sub patches

in it. Like the pitch shifter, the timbre stamp also reads the sound files into arrays. "pd

insample1" and "pd insample2" sub patches (in figure 20) does this. Because of this, the

Bluetooth file also needs to be specified here, with the path /tmp/lydfil.wav in the "filter

input" box. The "control source" could be any wav-file wanted, but at this point all art music

files (addable sounds) are placed in the directory /home/skulptur/blandelyder.

From figure 20 the "control source" is analyzed to get its spectral envelope, which is then

stamped onto the "filter input" by adjusting the amplitudes of its Fourier transform. The "filter

input" is first whitened by the compression algorithm from the previous patch in this series.

The best value of "squelch" to use depends critically on what kind of sounds are used for the

filter input and the control source.

The timbre stamp also uses the "soundfiler" object, which means it only plays 4000000

samples of the sound file.

3 A vocoder is an audio processor that captures the characteristic elements of an audio signal and then uses this

characteristic signal to affect other audio signals. The technology behind the vocoder effect was initially used in

attempts to synthesize speech.


-72-

7.3.10 Channel changer patch

This chapter describes how the channel changer in PD’s main patch is built up. In the end of

the chapter two examples are shown on how to expand/ develop the channel changer further

to create other types of sound output patterns.

In order to be able to create a 3 dimensional sound effect, there was need for controlling all

the 7 channels separately. Controlling these channels means that they would have be turned

on and off in different patterns to be able to create the desired 3 dimensional effect.

In the first versions of these channel changers, the 7 output channels where just turned on and

off. This resulted in a clicking noise in the speakers, not friendly to the ear. In an attempt to

avoid this clicking noise, the channel changer was made with a fading between the output

channels instead of just turning them on and off. This solved the problem. The time of fading

on and off the different output channels can easily be changed to create different effects. In

the same way the pattern of the changer can be changed, also to create different effects to the

resulting sound output of the sculpture.

Figure 21 show how the channel changer is implemented in the output part of PD main patch.

The audio from the sound processing is connected to the changers upper left corner. The 7

channels are then routed through the filter control before they end up at the "dac~".

Figure 21. Channel changer in PD's output

Figure 22 show how the channel changer is built up in detail. The value from the fade object

on each of the 7 channels is multiplied (the "*~" object) with the audio signal connected to the

"inlet~" object. This means that the value of the audio signal sent to the "outlet~" is constantly

changing resulting in changing volume output. The "r start" object receives a "bang" from the

open audio file patch. This is sent by using the "loadband" object on a message box which

contains "start bang". Data can be inputted to the "receive"("r") object using the "send"("s")

object or by creating a Pd "send" command in a message box.

Figure 22. Channel changer in detail


-73-

Figure 23 show how the "pd fade~" sub patch is built up. The "vline~" object counts from 0 to

1 in 200ms, the "del 200" object is a delay before the "vline~" count down to 0 again. When it

starts to count down the channel 2 is starting to count up via the outlet object. This runs

through all the channels before it starts over. By changing the values, in this case 200ms, the

time it takes to count up and down changes and also the time before the next channel is

started.

Figure 23. Fade object

7.3.10.1 Expanding possibilities/ further development:

Figure 24 show an easy way to just change the direction of the changer in figure 21. Like this

the changer will output the sound counter clockwise instead of clockwise. This setup is also

used in some of the patches in use on the sculpture. Of course, the connections between the

changer and the filter control can be connected in many other ways.

Figure 24. Changer 1, changing direction.

Figure 25 shows another example of how to expand the possibilities for the channel changer.

In this example two cannel changers of the type used in figure 24, with on one of them

connected to filter control like in figure 24 is used together with a sub patch called "pd

metro", shown in figure 26. The "pd metro" sub patch is used to get the output to always

change direction. This example plays first clockwise and then back counter clockwise before

starting over. Building new patches like this is easy by just using copy and paste from other

patches used.


-74-

Figure 25. Example of how to expand the possibilities

Figure 26 show how the "pd metro" sub patch is built up. The "del 6500" waits 6500ms before

turning the direction of the output. Like in the other patches the time can be changed to set it

to go faster or slower.

Figure 26. Contents of the pd metro object

These two examples show that there is only the fantasy limiting the ways to expand the

changer, to control the 7 outputs in different ways. Using copy and paste also reduce the

knowledge of PD to a minimum.

7.3.11 Volume and filter control patch

To ensure that the volume on the different patches is about the same, a volume control has

been added. The initial value of the volume is specified in the Open audio file patch and sent

to the "r volume" on the top of the red slider in the PD main patch.


-75-

Figure 27. Volume and filter control sub patch

From there on the value is sent to "inlet" which is shown in figure 27. To give the volume

control a more “realistic” function the "dbtorms" objects is used. This converts dB to linear

units. 100 dB is normalized to one, and zero dB artificially outputs a true 0.

There is also high pass filters on each channel in the volume and filter control patch, to avoid

distortion of the speakers. The filters roll off frequency is specified in the open audio file

patch (see 7.3.1), and this ought to be remained, since it has been tested.

7.4 Setting parameters and paths

The most important and effective parameter, almost no matter how much the patches are

adjusted, is the audio file itself. The artist actually preferred that all patches were tested with

the same audio file, with the intention of getting the patches most possible unequal.

When it comes to the parameters for the audio effects the easiest way was to set the

parameters in each individual audio effect patch. This means that if the pitch shifter’s

parameters have to be change, its sub patch has to be opened and the parameters are change as

described in section 7.3.8 (Pitch shifter patch).

Still, there are some parameters that are set in a less logical place. These are the volume

control, as described in section 7.3.11 (Volume and filter control patch) and the PD playback

time. To control the playback time there is a timer which can be set to any value wanted

before PD closes down. To change this see chapter 7.3.1 (Open audio file patch).

7.4.1 Setting paths

To sum up the Bluetooth and art music files (addable files) needs to be specified in 4 different

places:

In the "OPEN_FILE" sub patch, described in 7.3.1 (Open audio file patch)

In the "ADD_ART_MUSIC" sub patch (if a secondary sound file is wanted),

described in 0 (Add art music).

In the "PITCH_SHIFTER" sub patch, described in 7.3.8 (Pitch shifter patch)

In the "TIMBRE_STAMP" sub patch, described in 0 (Timbre stamp patch)

Notice that the Bluetooth file’s path is always /tmp/lydfil.


-76-

7.5 The 20 PD patches

This chapter is meant to give an overview of what effects used on the 20 patches. The patches

are suggestions, and will be demonstrated to the artist after the project has been delivered.

Patch 1:

Pitch shifter using sample rate 60000 Hz. Counter on "transpose" using 10 seconds up

to 50, and 10 seconds back to 0. 5 seconds waiting before it starts again. Pitch shifter

is connected to channel changer 1 (ring)

Patch 2:

Pitch shifter with sample rate 60000 Hz. Counter on "transpose" using 10 seconds up


is connected to directly to the filter control (no channel changer)

Patch 3:


to 50, and 10 seconds back to 0. Counter starts every 7th

second. Pitch shifter is

connected to directly to channel changer 4.

Timbre stamp on channel changer 4

Patch 4:

Pitch shifter using sample rate 20000 Hz. "transpose" = -1, "window" = 924, "delay" =

50. Pitch shifter is connected to random reverb and then to channel changer 1.

Timbre stamp on channel 3 and 6.

Patch 5:

Pitch shifter using sample rate 20000 Hz. "transpose" = -1, "window" = 924, "delay" =

50. Pitch shifter is connected to random reverb and then to channel changer 4.

Added art music connected to channel changer 4.

Timbre stamp on channel 3 and 6.

Patch 6:

Pitch shifter using sample rate 20000 Hz. "transpose" = 6, "window" = 924, "delay" =

50. Pitch shifter is connected to static reverb (1500) and then to channel changer 1.

Timbre stamp on channel 1,5 and 6, and also to channel changer 1

Patch 7:

Pitch shifter with sample rate 20000 Hz. "transpose" = -15, "window" = 924, "delay" =

50. Pitch shifter is connected to static reverb (1500) and then to channel 1,2,4,5 and 6.

Added art music connected to channel changer 1

Patch 8:


50. Pitch shifter is connected to random reverb and then to channel changer 1. Also

connected from reverb patch to 1,3,5 and 7 seconds delay and then to channel changer

1.

Added art music connected to channel changer 1

Patch 9:


-77-


50. Pitch shifter is connected to all delay channels, and then to channel changer 1.


Patch 10:

Pitch shifter using sample rate 60000 Hz. "transpose" = -10, "window" = 924, "delay"

= 50. Pitch shifter is connected to a random multiplying oscillator and then to channel

changer 1.

Timbre stamp on channel changer 1.

Patch 11:



is connected to channel changer 1

Double added art music. First file connected through all delay channels and then to

channel changer 1. Second file connected directly to channel 1 and 4.

Patch 12:



is connected to channel changer 1


Patch 13:


to 50, and then jumping directly back to 0. 15 seconds waiting before it starts again.

Pitch shifter is connected to channel changer 1

Added art music connected to channel changer 1. Also connected directly to channel 3

and 5.

Patch 14:


= 50. Pitch shifter is connected to channel changer 3.


Patch 15:


= 50. Pitch shifter is connected to FFT and then to channel changer 3. Also connected

through random reverb and then directly to channel 3 and 6.

Timbre stamp on channel 5

Patch 16:


= 50. Pitch shifter is connected to channel changer 3. Also connected through random

reverb and then directly to channel 3 and 6.

Timbre stamp on channel changer 3

Patch 17:

Timbre stamp connected to channel changer 4.


-78-

Patch 18:

Timbre stamp connected to random reverb and the to a random channel changer.

Patch 19:

Timbre stamp connected to random reverb and the to a random channel changer.

Patch 20:

Timbre stamp through channel changer 1.


-79-

8 Appendix: Details about the image patch The source of information in this chapter is the GEM help files.

The idea of the patch is to use the RGB values that come out of the picture as parameters in

the main patch. The effects that the values are used on are reverb and pitch shifter.

The greyscale value controls the reverb and the RGB values controls the pitch shifter.

Red controls the transposition of the pitch shifter, Green controls the window size (msec),

Blue controls the delay (msec). For explanation of the reverb and pitch shifter patch se

(appendix 7.3)

8.1 Explanation of used GEM objects

Figure 28 shows the main sub patch. The following sub chapters give an explanation of the

used GEM objects.

Figure 28. Main sub patch

8.1.1 pix_image

Refer to figure 29.

This block loads an image file to be used as a texture, bitblit, or something else.

This block can load TIFF images, JPG images and PNG images.

The TIFF files are loaded using Sam Leffler’s libtiff library, which is a portable image

file reading, and processing package.

The image can either be drawn directly using pix_draw or applied as a texture.

In the program this block is used to load the image into the patch.

Figure 29. pix_image


-80-

8.1.2 pix_data

Refer to figure 30.

Is a block were you can get the colour of a specific pixel within an image when

triggered with a bang.

The coordinates within the image (x-pos, y-pos) range from (0.0f, 0.0f) which is the

left bottom and goes to (1.0f, 1.0f) which is the right top.

When the first inlet is triggered with a bang the colour of the specified pixels is output

both as gray-value and as RGB-triplet.

In the main patch this block is used to get the pixel values of the loaded image.

Figure 30. pix_data

8.1.3 pix_draw

Refer to figure 31.

pix_draw draws the pixels on the screen without doing any texture mapping.

Since this block is just blasting pixels, rotations and translations in the z-dimension

won’t do anything.

This block is used in the program to se the picture that the program scans through. The

pix_data block needs this block to work.

Figure 31. pix_draw

8.1.4 gemList

Gemlist is a group of connected gem objects starting with gemhead. The gemhead is

not necessary a part of the gemlist. See 8.1.2. (Used in figure 28).

8.1.5 Gemhead

Gemhead is the start of a render sub-chain (logical unit in 3D space, like a “model”)

like the one in 8.1.3. (used in figure 28).

8.2 Explanation of the main patch

Refer to figure 28.

As we can see the patch is built upon the object pix_data object. The reason for using this

object is because it writes out the pixel values very easily without any trouble. The image is

loaded into the memory with the block pix_image. Then the output signal from this block is


-81-

sent into the second right inlet of the pix_data block. The two inlets on the left is the x and y

position in the picture. These values come from the counter.

The rightmost inlet is the trigger. When this inlet gets a bang the specific value of a position is

outputted as a RGB triplet and a grey scale value. The RGB values are extracted with the

object unpack and routed to it’s respectively outlets. Now the RGB and greyscale values are

free to use as parameters for the main program.

There has been made 13 different patches with different sound files that the values of the

received picture can control. Each of these patches is opened randomly after request from

Samir.

To add more patches simply open one already made patch. Click on the pitch shifter. Then

click on the pd test input and then put the location of the file you want to mix with the image

values in the read file box. The location of the new mix sound must be

/home/skulptur/blandelyder/filename.wav.

8.3 Counter sub patch

Refer to Figure 32.

The counter patch is built upon the Gem object counter which is a counter that counts from

the low value argument to the high value argument. It counts the number of bangs that it

receives on the firs inlet. The second inlet is the counting argument. This argument states if it

is going to count up, down or up and down (1=up, 2=down, 3=up and down). If you send a

clear message to the left inlet the counter will clear the counter and set it back to its initial

conditions. A reset message will at the left inlet clear the counter back to its starting

conditions and send the value to the left outlet. This is the main object of the counter patch.

The x-positions on the picture are controlled by the left outlet on the counter. The metro on

the left inlet controls the speed on the counting. Every time when the counter has counted

from 0 to 10 it outputs a bang on the right outlet. This bang is used to count the y-positions.

To count the y-positions a float object is used. It is a kind of memory which stores the value it

gets on the right inlet and outputs it when it receives a bang. If the input on the right inlet is a

[+ 1] object the stored value on the float object will increase by one for every bang that comes

out of the counter object.

To check when the counter patch has counted through all the values a select object is used.

This object outputs a bang when the value on the right inlet is the same as the argument of the

object. This bang is then sent to the PD quit message and Pd quits.


-82-

Figure 32. Counter main

8.3.1 Dataflow chart on the counter

Figure 33. Dataflow chart on counter

Figure 33 show the dataflow chart on the counter. First the counter starts to increment the x

position until it is 1. Y is 0 until X has counted to 1 for the first time. When both X and Y

have reached their maximum value. A signal is sent to the quit PD block and the program

quit. It has now scanned through 100 of the pixel values.

8.4 RGB-values

RGB stands for the colours Red, Green and Blue and is an additive model. An additive model

is a model which the combined effect of several factors is the sum of the effect produced by

each of the factors. Ex. In the RGB model it is the sum of the three values that creates the

colour out. In design for web pages and computer monitors the colours are defined as a

combination of these three colours. It is a model that is represented numerically.

As said earlier the most common usage of these values is in televisions and computers. The

computer values are then converted into intensities before it is viewed on the screen.

The most common now is to use up to 24bit per pixel. This gives 8bit per colour giving a

range of possible 256 values for each colour.


-83-

The intensity of a colour output on a computer display is not normally proportional with the

RGB value. If the intensity is 0.5 it is half of 1.0 but the light intensity of showing (0.5, 0.5,

0.5) is normally 18% of the light intensity of (1.0, 1.0, 1.0) .

There are three most common ways to represent the these numbers

As a number from 0.0 to 1.0 with zero as minimum a 1.0 as maximum colour value.

As a number from 0 to 255. To get these numbers you simply adding 255 to the range

from 0.0 to 1.0. This is the 24bit representation with 8 bit per colour.

The same range can also be written on a fixed to digit format (hexadecimal numbers)

with ff as maximum and 00 as minimum.

There is also a 32bit representation of the pixel. It is almost identical to the 24bit

representation since there are still 8bits per colour, and 8 bits that are rarely used. The reason

to extend the model is to make it faster to access the data in the pixels. The most advanced is

the 48bit representation. This gives each colour 16bits. From this we can see that we can

represent each colour a value from 0 to 65535 instead of from 0 to 255. The primary usage of

this is in professional image editing with for example Photoshop. The use of the RGB model

for presentation of colours on the internet has its roots in the 1953 RCA colour TV standard

and Edwin Land’s use of a RGB standard for the Polaroid camera.


-84-

9 Appendix: Suggested structure of the web site Table 3. Structure of the web site

Active Options

Code. Options Destination Description Content Documents for the prototype

P0

The Idea Website’s

presentation

Document:

1 flash

animation

or image +

1 text

text3dsculpture.doc /

The Idea

introduction.fla or

introduction.jpg

P1 The

Project

Submenu Destination Information

about where the

sculpture is

located

Document:

1 text + 1

map


Location

map.jpg

SM_1.1 Location

SM_1.2 Hardware Information

about the

hardware used.

Document:

1 text


Hardware

SM_1.3 Software Information

about the

software used

Document:

1 text


Software

SM_1.4 Operation Information

about the

operation of the

system

Document:

1 text + 1

image


Operation

system.jpg

P2 Persons

Involved

Information

about the

persons

involved in the

project.

Document:

7 photo +

7 texts


Persons Involved

Thomast.jpg,

Tomasa.jpg, Einar.jpg,

Even.jpg, Håkon.jpg,


-85-

Samir.jpg & Cris.jpg

P3 Listen

Samples

Different

samples that

allow listening

2 of each kind

of supported

files (sound,

image and text)

Document:

3 text + 2

images +

sound

players


Listen Samples

ex1.jpg & ex2.jpg

Dewplayer.swf

P4 Guestbook System to store

the messages of

the users

Document:

1 text + 1

form


Guestbook

PHP scripts:

guestbook.php &

paginator.php

P1 Members

Zone

Private area

where the

members can

administrate art

music

File Thingie


-86-

10 Appendix: Guestbook details and code

10.1 Table created in the database

It is nessesayr to create the database before use. This is easily accomplished using

phpMyAdmin. Then execute the next SQL sentence to create the table to store messages:

CREATE TABLE menssage ( id int(9) NOT NULL auto_increment, name varchar(50) NOT NULL, email varchar(50) NOT NULL, date int(10), sugestion text, PRIMARY KEY (id) );

10.2 Guestbook code listing <?php $link = mysql_connect("localhost","root","password");// conexion with MySQL mysql_select_db("guestbook",$link);//conexion with the database // Check if name and sugestion fields are full or not. If it is , then the message is sended to the Server. if($_POST['nombre']!="" && $_POST['comentario']!="") { $fecha = time(); $_pagi_sql = "INSERT INTO mensajes (nombre, correo, fecha, comentario) VALUES ('$_POST[nombre]','$_POST[correo]','$fecha','$_POST[comentario]')"; mysql_query ($_pagi_sql, $link) or die (mysql_error()); header("Location: http://158.38.120.61/guestbook/libro.php?_pagi_pg=1"); } ?> //Form with 3 fields <center> <form method="POST" action="<?=$PHP_SELF?>"> Name: <input type="text" name="nombre" size="20"> E-mail: <input type="text" name="correo" size="20"><br> Comment:<br> <textarea rows="17" name="comentario" cols="58"></textarea><br> <input type="submit" value="Send!!" name="B1"> </form> </center> <br><br> <center> <?php $_pagi_sql = "SELECT * FROM mensajes ORDER BY fecha DESC";//SQL petition. $result = mysql_query ($_pagi_sql) or die (mysql_error()); //variables used with paginator $_pagi_cuantos = 4; $_pagi_nav_anterior="Previus"; $_pagi_nav_siguiente="Next"; $_pagi_nav_primera="First"; $_pagi_nav_ultima="Last"; include("paginator.inc.php"); //print all messages in the screen if(mysql_num_rows($result)!=0) {


-87-

print '<table border="1" cellpadding="0" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="446" height="90">'; $i=0; while ($row = mysql_fetch_array($_pagi_result)) { if($i % 2) { $color = "#DBDBDB"; }else{ $color = "#E9E9E9"; } $i++; if($row[correo]!="") { $nombre = '<a href="mailto:'.$row[correo].'">'.$row[nombre].'</a>'; }else{ $nombre = $row[nombre]; } print' <tr> <td width="130" height="14" valign="top" bgcolor="'.$color.'">'.$nombre.' ('.date("d/m/Y",$row[fecha]).')</td> <td width="310" height="90" valign="top" rowspan="2" bgcolor="'.$color.'">Comment:<br>'.nl2br($row[comentario]).'</td> </tr> <tr> <td width="130" height="72" valign="top" bgcolor="'.$color.'"></td> </tr>'; } print '</table>'; } echo"<p>".$_pagi_navegacion."</p>"; ?>

Figure 34. Guestbook' interface


-88-

11 Appendix: DewPlayer configuration The files are located in the directory /srv/www/sounds.

The second step is put a copy of the sound player in the server; it is in the directory

/srv/www/dew.

The third step is to add the sound player at HTML code and configure it.

To add it to the page following the recommendation of W3C is necessary to use this

code:

<object type="application/x-shockwave-flash" data="http://158.38.120.61/dew/dewplayer.swf?mp3=http://158.38.120.61/sounds/eso.mp3&bgcolor=FFFFFF" width="200" height="20"><param name="wmode" value="transparent"> <param name="movie" value="http://158.38.120.61/dew/dewplayer.swf?mp3=http://158.38.120.61/sounds/eso.mp3&bgcolor=FFFFFF" />

It is possible to change the size of the player and the background colour. The arguments of

“value” and “mp3” need to be changed to the location of the sound player in the server, and

the sound, respectively.


-89-

12 Appendix: Main program – full listing #!/usr/bin/env python #-*- coding: utf-8 -*- ############################################################# # "Spamalot" - Programvare for styring av lydsystemet # Versjon 0.9.7, 3. mai 2007 # Distribueres etter betingelsene i GNU GPL versjon 2 # # Skrevet av: # Einar Thorsrud <[email protected]> # Thomas Asphaug <[email protected]> # # Se LESMEG.TXT for mer informasjon ############################################################# import os, subprocess, time, os.path, shutil, signal import funksjoner # Funksjoner skrevet spesifikt for dette programmet def main(): # Gammel vane, kjekt for å inkludere i andre programmer # Blandefiler ligger i /home/skulptur/blandefiler - Må ligge her (jall) # Setter banen til lokasjojen for kunstmusikk, BT-filer og install.-mappe bluetoothmappe = "/home/et/bluetooth" # Må anngis uten / til slutt! (Absolutt bane) kunstmusikkmappe = "/home/et/kunstmusikk" # Må anngis uten / til slutt! installmappe = "/usr/local/spamalot" # Anngir hvor programmet er installert, VIKTIG! # Anngir absolutt plassering for midlertidig lydfil # Dersom denne forandres må alle PD-patchene forandres også # Det må også forandres i funksjoner.onSignal (ikke forandr!) utfil = "/tmp/lydfil.wav" # Anngir midlertidig plassering for bilde-utfil. Må ikke forandres bildeUtfil = "/tmp/bildefil.jpg" # Anngir absolutt plassering til mappen programmet er installert (Kommenter ut for testing) os.chdir(installmappe) # Signal-fanger som behandler alle kill-signaler likt; # sørger for at programmet avslutter pent og ryddig når det får beksjed om det signal.signal(signal.SIGTERM, funksjoner.onSignal) signal.signal(signal.SIGHUP, funksjoner.onSignal) signal.signal(signal.SIGPIPE, funksjoner.onSignal) signal.signal(signal.SIGALRM, funksjoner.onSignal) signal.signal(signal.SIGINT, funksjoner.onSignal) signal.signal(signal.SIGQUIT, funksjoner.onSignal) # Starter kunstmusikken for første gang # Genererer liste over alle filene i undermapper: filListe = funksjoner.listFiler(kunstmusikkmappe) I = len(filListe) if I > 0: # Sann hvis det finnes minst 1 fil I = I - 1 fil = filListe[I] # Dekoder filen til wav: returkode, type = funksjoner.konvFil(fil, utfil, 'kunst', bildeUtfil) if returkode is 0: kunstmusikk = subprocess.Popen('pd -nogui pdPatcher/kunstmusikk.pd', shell=True) # Starter PD btmappe = bluetoothmappe + '/' while 1: # Evig løkke filer = os.listdir(btmappe) # Finner filene i bluetooth-mappen # Prøver å velge en fil fra listen. try: btfil = filer[len(filer)-1] # Velger den siste filen i listen # Utføres dersom det ikke finnes noen Bluetooth-filer


-90-

except: # Meget skitten busemekking, nødvendig pga. zombieprosess. Bør fjernes! shrubbery = subprocess.Popen('date 1>/dev/null', shell=True) # Busemekking shrubbery.wait() # Busemekking forts... # Her bruker try for å takle situasjonen dersom kunstmusikk-objektet ikke eksisterer try: # Vil bare finne ut om kunstmusikk eksisterer, kan sikkert gjøres mer elegant if kunstmusikk.returncode is not None: pass except: pass # Nødvendig pga. syntaks else: # Kjøres dersom det ikke oppsto et unntak (except); dvs når kunstmusikk eksisterer if kunstmusikk.returncode is not None: # Sann bare når kunstmusikk er ferdig avspilt if I == 0: # Må generere ny fil-liste (har kommet til bunnen) filListe = funksjoner.listFiler(kunstmusikkmappe) # Lister ut alle filene i kunstmusikkmappen I = len(filListe) if I > 0: I = I - 1 fil = filListe[I] returkode = 'None' # Bare det er noe annet enn 0 går det bra if os.path.exists(fil): returkode, type = funksjoner.konvFil(fil, utfil, 'kunst', bildeUtfil) if returkode is 0 and os.path.exists(utfil): kunstmusikk = subprocess.Popen('pd -nogui pdPatcher/kunstmusikk.pd', shell=True) # Starter PD time.sleep(0.2) # Venter en liten stund før løkka begynner igjen continue # Går tilbake til starten av løkka # Denne delen spiller Bluetooth-musikk... (resten av programmet) time.sleep(1) # Venter for å være sikker på at filen er ferdig skrevet btfil = btmappe + btfil returkode, type = funksjoner.konvFil(btfil, utfil, 'bluetooth', bildeUtfil) if returkode == 0: # Stopper kunstmusikker hvis konverteringen var vellykket try: os.kill(kunstmusikk.pid, 15) # Prøver å drepe kunstmusikken except: pass # Nødvendig pga. syntaks if type.endswith('musikk') and os.path.exists(utfil): funksjoner.spillBtMusikk() # Behandles som musikk (høyere samplingsrate) elif type.endswith('tale') and os.path.exists(utfil): funksjoner.spillBtTale() # Behandles som tale (lavere samplingsrate) elif type.endswith('bilde') and os.path.exists(utfil): funksjoner.spillBtBilde() # Behandles som bilde (konverteres med GEM) # Rydder opp if os.path.exists(btfil): # Bare hvis ikke filen er slettet i mellomtiden if os.path.isfile(btfil): os.remove(btfil) # Sletter bluetooth-fila etter bruk else: shutil.rmtree(btfil) # Anntar at hvis det ikke er en fil, må det være en mappe; slett i vei :) main() # Kaller main slik at programmet kan kjøres uten å bli kalt av et annet program


-91-

13 Appendix: Main program – explanation The entire program code is listed in appendix 12.

13.1 Initialize

The following code is the initialization part of the main program. Line 1 imports all the extra

modules/ libraries that are used in the program. Line 2 imports the module funksjoner. This

module contains all the functions written specially for this program.

Line 4 through 7 sets different location for files and folders used by the program. Line 8

changes the current working directory to installmappe.

Line 9 through 14 calls the function “onSignal” to take care of different kill signals so that the

program ends without any trouble.

1 import os, subprocess, time, os.path, shutil, signal 2 import funksjoner 3 def main(): 4 bluetoothmappe = "/srv/bluetooth" 5 kunstmusikkmappe = "/home/skulptur/kunstmusikk" 6 installmappe = "/usr/local/spamalot" 7 utfil = "/tmp/lydfil.wav" 8 os.chdir(installmappe) 9 signal.signal(signal.SIGTERM, funksjoner.onSignal) 10 signal.signal(signal.SIGHUP, funksjoner.onSignal) 11 signal.signal(signal.SIGPIPE, funksjoner.onSignal) 12 signal.signal(signal.SIGALRM, funksjoner.onSignal) 13 signal.signal(signal.SIGINT, funksjoner.onSignal) 14 signal.signal(signal.SIGQUIT, funksjoner.onSignal)

13.2 Generating art music list, converting music file and starts PD

Line 1 makes a list of all the files in art music folder “kunstmusikkmappe” by using the

listFiler function. The variable “I” is set to the same value as the number of files. If there are

no files in the art music folder this is taken care of by the if statement in line 3. In line 5 the

variable “fil” is set to the first file in the art music file list. Line 6 calls the function konvFil

which converts the art music file to wav. If the conversion is ok (line 7), line 8 starts PD with

the art music patch.

1 filListe = funksjoner.listFiler(kunstmusikkmappe) 2 I = len(filListe) 3 if I > 0: 4 I = I - 1 5 fil = filListe[I] 6 returkode, type = funksjoner.konvFil(fil, utfil, 'kunst') 7 if returkode is 0: 8 kunstmusikk = subprocess.Popen('pd -nogui pdPatcher/kunstmusikk.pd', shell=True)


-92-

13.3 Bluetooth file available

The next part of the code is a never ending while statement, checking if there are any

Bluetooth files in Bluetooth folder “btmappe”. If so the variable “btfil” is set to last file in the

Bluetooth folder in line 4.

1 while 1: 2 filer = os.listdir(btmappe) 3 try: 4 btfil = filer[len(filer)-1]

13.4 No, play art music file

If there are no Bluetooth files, the next part of the code plays art music files. Line 1 is

checking if art music is already playing. If its not, line 2 checks if all the art music files have

been played, if that’s so, line 3 and 4 creates a new list of the art music files. If the list of art

music files is not played through completely line 5 through 9 sets the variable “fil” to the next

file on the list. Line 9 is only true if the file exists. Line 10 converts the file to wav with the

function “konvFil”. If the conversion went ok, line 12 starts PD with the art music patch.

1 if kunstmusikk.returncode is not None: 2 if I == 0: 3 filListe = funksjoner.listFiler(kunstmusikkmappe) 4 I = len(filListe) 5 if I > 0: 6 I = I - 1 7 fil = filListe[I] 8 returkode = 'None' 9 if os.path.exists(fil): 10 returkode, type = funksjoner.konvFil(fil, utfil, 'kunst') 11 if returkode is 0 and os.path.exists(utfil): 12 kunstmusikk = subprocess.Popen('pd -nogui pdPatcher/kunstmusikk.pd', shell=True)

13.5 Yes, convert and play Bluetooth file

If there was a Bluetooth file in the Bluetooth folder, this next part of the code is made to take

care of that. Line 1 puts together the path and filename. Line 2 converts the file to wav. Line 5

stops the playback of art music. Depending of whether the file is music or speech. If music

file, line 9 calls the function “spillBtMusikk” or if its speech line 11 calls the function

“spillBtTale”. Line 12 through 16, deletes the played Bluetooth file from the Bluetooth folder.

1 btfil = btmappe + btfil 2 returkode, type = funksjoner.konvFil(btfil, utfil, 'bluetooth') 3 if returkode == 0: 4 try: 5 os.kill(kunstmusikk.pid, 15) 6 except: 7 pass 8 if type.endswith('musikk') and os.path.exists(utfil): 9 Funksjoner.spillBtMusikk()


-93-

10 elif type.endswith('tale') and os.path.exists(utfil): 11 funksjoner.spillBtTale() 12 if os.path.exists(btfil): 13 if os.path.isfile(btfil): 14 os.remove(btfil) 15 else: 16 shutil.rmtree(btfil)


-94-

14 Appendix: Functions “Funksjoner” – full listing #!/usr/bin/env python #-*- coding: utf-8 -*- ############################################################# # Funksjoner til "Spamalot" # # Skrevet av: # Einar Thorsrud <[email protected]> # Thomas Asphaug <[email protected]> ############################################################# import os, sys, subprocess, shutil, random def spillBtMusikk(): # Spiller av / konverterer ved hjelp av PD # Bruker samplingsfrekvensen 22100 på innleste filer # Returnerer tibake returkoden fra PD btMusikk = os.listdir('pdPatcher/musikk/') # Anngis med / til slutt, men ikke i begynnelsen btPdPatch = btMusikk[random.randrange(len(btMusikk))] # Velger en tilfeldig PD patch, 44100 kHz blueSpill = subprocess.Popen('pd -r 44100 -nogui pdPatcher/musikk/' + btPdPatch, shell=True) blueSpill.wait() return blueSpill.returncode def spillBtTale(): # Spiller av / konverterer ved hjelp av PD # Bruker samplingsfrekvensen 8000 på innleste filer # Returnerer tibake returkoden fra PD btTale = os.listdir('pdPatcher/tale/') # Anngis med / til slutt, men ikke i begynnelsen btPdPatch = btTale[random.randrange(len(btTale))] # Velger en tilfeldig PD patch, 8000 kHz blueSpill = subprocess.Popen('pd -r 8000 -nogui pdPatcher/musikk/' + btPdPatch, shell=True) blueSpill.wait() return blueSpill.returncode def spillBtBilde(): # Spiller av / konverterer ved hjelp av PD # Bruker samplingsfrekvensen 8000 på innleste filer # Returnerer tibake returkoden fra PD btBilde = os.listdir('pdPatcher/bilde/') # Anngis med / til slutt, men ikke i begynnelsen btPdPatch = btBilde[random.randrange(len(btBilde))] # Velger en tilfeldig PD patch for bilder (med GEM) blueSpill = subprocess.Popen('pd -lib Gem -r 44100 -nogui pdPatcher/bilde/' + btPdPatch, shell=True) blueSpill.wait() return blueSpill.returncode def konvMp3(innfil, utfil): # Konverterer mp3 til wav konvProg = subprocess.Popen('lame --decode \"' + innfil + '\" ' + utfil + ' --silent', shell=True) konvProg.wait() return konvProg.returncode def konvOgg(innfil, utfil): # Konverterer ogg til wav konvProg = subprocess.Popen('oggdec \"' + innfil + '\" -o ' + utfil + ' -Q', shell=True) konvProg.wait() return konvProg.returncode def konvMp4(innfil, utfil): # Konverterer mp4 til wav konvProg = subprocess.Popen('faad \"' + innfil + '\" -o ' + utfil + ' -q', shell=True) konvProg.wait() return konvProg.returncode def konvAmr(innfil, utfil): # Konverterer amr til wav, her må det gjøres noe med samplingsraten! konvProg = subprocess.Popen('ffmpeg -y -i \"' + innfil + '\" ' + utfil + ' 2>/dev/null', shell=True) konvProg.wait() return konvProg.returncode


-95-

def konvWma(innfil, utfil): # Konverterer wma til wav konvProg = subprocess.Popen('mplayer \"' + innfil + '\" -ao pcm -ao pcm:file=' + utfil + ' 1>/dev/null 2>/dev/null', shell=True) konvProg.wait() return konvProg.returncode def konvTxt(innfil, utfil): # Syntetiserer tale ut fra tekstfiler, her må det gjøres noe med samplingsraten! if os.stat(innfil).st_size < 500: konvProg = subprocess.Popen('text2wave -F 16000 \"' + innfil + '\" -o ' + utfil, shell=True) konvProg.wait() return konvProg.returncode else: return 1 def konvFlac(innfil, utfil): # Konverterer flac til wav konvProg = subprocess.Popen('flac -d \"' + innfil + '\" -o ' + utfil + ' -f --totaly-silent', shell=True) konvProg.wait() return konvProg.returncode def konvJpeg(innfil, bildeUtfil): print innfil print bildeUtfil # Forandrer størrelsen til 320x200 konvProg = subprocess.Popen('convert \"' + innfil + '\" -resize 320x200 \"' + bildeUtfil + '\"', shell=True) konvProg.wait() return konvProg.returncode def konvFil(fil, utfil, musikkType, bildeUtfil): # musikkType er enten 'kunst' eller 'bluetooth', # spiller ikke txt, bilder osv for kunst. # Musikk/tale returneres bare for å bestemme hvilken # samplingsfrekvens som skal anntas ved innlesing av filen i PD if fil.endswith('.mp3') or fil.endswith('.MP3') or fil.endswith('.Mp3'): if konvMp3(fil, utfil) is 0: # Konverterer til wav os.chmod(utfil, 438) # gir alle brukere skrivetilgang til fila return 0, 'musikk' else: return 1, 'error' elif fil.endswith('.ogg') or fil.endswith('.OGG') or fil.endswith ('.Ogg'): if konvOgg(fil, utfil) is 0: # Konverterer til wav os.chmod(utfil, 438) # gir alle brukere skrivetilgang til fila return 0, 'musikk' else: return 1, 'error' elif fil.endswith('.aac') or fil.endswith('.AAC') or fil.endswith('.Aac') or fil.endswith('.mp4') or fil.endswith('.MP4') or fil.endswith('.Mp4') or fil.endswith('.m4a') or fil.endswith('.M4A') or fil.endswith('.M4a'): if konvMp4(fil, utfil) is 0: # Konverterer til wav os.chmod(utfil, 438) # gir alle brukere skrivetilgang til fila return 0, 'musikk' else: return 1, 'error' elif fil.endswith('.wma') or fil.endswith('.WMA') or fil.endswith('.Wma'): if konvWma(fil, utfil) is 0: # Konverterer til wav os.chmod(utfil, 438) # gir alle brukere skrivetilgang til fila return 0, 'musikk' else: return 1, 'error' elif fil.endswith('.amr') or fil.endswith('.AMR') or fil.endswith('.Amr'): if konvAmr(fil, utfil) is 0: # Konverterer til wav os.chmod(utfil, 438) # gir alle brukere skrivetilgang til fila return 0, 'tale' else: return 1, 'error' elif musikkType is not 'kunst' and fil.endswith('.txt') or fil.endswith('.TXT') or fil.endswith('.Txt'): if konvTxt(fil, utfil) is 0: # Konverterer til wav (syntetiserer tale) os.chmod(utfil, 438) # gir alle brukere skrivetilgang til fila return 0, 'tale' else:


-96-

return 1, 'error' elif fil.endswith('.wav') or fil.endswith('.WAV') or fil.endswith('.Wav'): try: shutil.move(fil, utfil) # Kopierer til riktig plassering except: return 1, 'error' else: os.chmod(utfil, 438) # gir alle brukere skrivetilgang til fila return 0, 'musikk' elif fil.endswith('.flac') or fil.endswith('.FLAC') or fil.endswith('.Flac'): if konvFlac(fil, utfil) is 0: # Konverterer til wav os.chmod(utfil, 438) # gir alle brukere skrivetilgang til fila return 0, 'musikk' else: return 1, 'error' elif fil.endswith('.jpg') or fil.endswith('.JPG') or fil.endswith('.jpeg') or fil.endswith('.JPEG'): if konvJpeg(fil, bildeUtfil) is 0: # Konverterer til wav os.chmod(bildeUtfil, 438) # gir alle brukere skrivetilgang til fila return 0, 'bilde' else: return 1, 'error' else: return 1, 'error' # Sletter alle ukjente filer def listFiler(kunstmusikkmappe): # Lager en liste over alle filer i alle undermappene (hele treet) filListe = [] for dirpath, dirnames, filenames in os.walk(kunstmusikkmappe): # List alle filer i alle undermapper dirnames[:] = [d for d in dirnames if not d.startswith('.')] # ikke mapper/filer som begynner på . for name in filenames: # Finner banen til hver fil: filListe.append(os.path.join(dirpath, name)) return filListe def onSignal(signalnummer, stackframe): # Rutine som utføres når programmet avslutter # Rydder opp og dreper subprosesser print 'Spamalot fikk signal', signalnummer, '; avslutter...' os.killpg(os.getpgid(0), 15) # Dreper alle subprosessene utlydfil = "/tmp/lydfil.wav" # Harkoding her er litt jall, bør forandres utbildefil = "/tmp/bildefil.jpg" if os.path.exists(utlydfil): os.remove(utlydfil) if os.path.exists(utbildefil): os.remove(utbildefil) sys.exit() # Avslutter programmet


-97-

15 Appendix: Main program functions – explanation The entire functions program code is listed in appendix 14.

15.1 Finding the file type, and call the right function to decode, in this case, mp3

Line 1 is the “konvFil “functions head. Line 2 finds out the file type, in this case, mp3and line

3 calls the function “konvMp3” for conversion and checks if the conversion went ok, if so, the

function returns 0 and the tag “musikk” (line 5) since mp3 is a music file. If the conversion

failed, function returns 1 and the tag “error”.

1 def konvFil(fil, utfil, musikkType): 2 if fil.endswith('.mp3') or fil.endswith('.MP3') or fil.endswith('.Mp3'): 3 if konvMp3(fil, utfil) is 0: 4 os.chmod(utfil, 438) 5 return 0, 'musikk' 6 else: 7 return 1, 'error'

15.2 Function for converting to wav files, in this case, from mp3

Line 2 starts the right program depending on file type. In this case Lame is started to decode

mp3 to wav. In the same way are all other the file types converted, by starting different

program to decode depending on file type.

1 def konvMp3(innfil, utfil): 2 konvProg = subprocess.Popen('lame --decode \"' + innfil + '\" ' + utfil + ' --silent', shell=True) 3 konvProg.wait() 4 return konvProg.returncode

15.3 Function for starting PD with random patch to play Bluetooth file

Line 2 lists all the PD patches and line 3 picks a random patch among those. Line 4 starts PD

with this patch.

1 def spillBtMusikk(): 2 btMusikk = os.listdir('pdPatcher/musikk/') 3 btPdPatch = btMusikk[random.randrange(len(btMusikk))] 4 blueSpill = subprocess.Popen('pd -r 44100 -nogui pdPatcher/musikk/' + btPdPatch, shell=True) 5 blueSpill.wait() 6 return blueSpill.returncode

15.4 Function to find all art music files in the art music folder and subfolders

This function scans through the folder “kunstmusikkmappe” and all the subfolders to create a

list of all the files.


-98-

1 def listFiler(kunstmusikkmappe): 2 filListe = [] 3 for dirpath, dirnames, filenames in os.walk(kunstmusikkmappe): 4 dirnames[:] = [d for d in dirnames if not d.startswith('.')]. 5 for name in filenames: 6 filListe.append(os.path.join(dirpath, name)) 7 return filListe

15.5 Exit function

This function cleans up when the program ends. Line 3 kills all sub processes. Line 4 through

6 deletes the temporary sound file /tmp/lydfil.wav, used by PD. 1 def onSignal(signalnummer, stackframe): 2 print 'Spamalot fikk signal', signalnummer, '; avslutter...' 3 os.killpg(os.getpgid(0), 15) 4 utfil = "/tmp/lydfil.wav" 5 if os.path.exists(utfil): 6 os.remove(utfil) 7 sys.exit()


-99-

16 Appendix: Installation guide main program This installation guide describes the installation of the main program with dependencies like it

has been used in the project.

It is assumed that the system is installed on a Debian based system. This is not necessary, but

the names on the programs needed are named the same way they are in Debian 4.0 Etch.

To get good multimedia support in Debian, it has to be added an opportunity to download

packages from debian-multimedia.org. The following line has to be added in

/etc/apt/sources.list: deb http://www.debian-multimedia.org etch main.

The installation of packages can be done with aptitude or synaptic, or other systems

depending on what one prefer. (Refer to appendix 4.1.3)

The main program is written in Python, and demand at least version 2.4 to function. Python is

usually installed as standard on every Linux distributions. If not so, any version of Pyhton

greater than 2.4 will work.

The program is configured to use ALSA. This can be changed by altering the PD

configuration file ~/.pdsetting. This file can be based on the following parameters:

audioapi: 1

noaudioin: False

audioindev1: 0 8

noaudioout: False

audiooutdev1: 0 8

audiobuf: 50

rate: 44100

nomidiin: True

nomidiout: True

npath: 0

standardpath: 1

verbose: 0

loadlib1: Gem

nloadlib: 0

defeatrt: 0

flags: -alsa


-100-

To let ALSA use PD with M-Audio Delta 1010, ALSA has to be set up the right way and in

addition a file has to be created; either /etc/asoundrc or ~/.asoundrc:

pcm.ice1712 {

type hw

card 0

}

ctl.ice1712 {

type hw

card 0

}

Packages necessary to get PD to function is:

gem - Graphics Environment for Multimedia - PureData library

pd-aubio - aubio external for PureData

puredata - realtime computer music and graphics system

pd-zexy - Addon library for Pd

The programs used for convering is:

mplayer - The Ultimate Movie Player For Linux

w32codecs - win32 binary codecs

vorbis-tools - several Ogg Vorbis tools

lame - LAME Ain't an MP3 Encoder

ffmpeg - audio/video encoder, streaming server & audio/video file converter

faad - freeware Advanced Audio Decoder player

festival - general multi-lingual speech synthesis system

flac - Free Lossless Audio Codec - command line tools

In addition, text2wave is needed. This is a festival script. It varies if this follows Debian’s

festival distribution or not, but if it’s not working after festival is installed, several version of

the script can be found in: /usr/doc/festival/examples/

When all the packages are installed, a folder has to be created where the main program will be

installed. All the files has to be copied to this location and the main program is made

executable with: chmod +x spamalot.py

Paths to the art music folder, “kunstmusikkmappe” and the Bluetooth folder can be changed

by editing the variables in the top of the main program code (appendix 12).

The Bluetooth files has to be owned by the same user running the program or all the files has

to be writeable to all, so that the program can delete the files even if it’s not started by the

owner.


-101-

The user running the program has to have permission to use the sound card. This is easiest

done by editing /etc/group, by adding the name of the desired user behind audio. For example,

for the user skulptur:

audio:x:29:skulptur

The number 29 is GID and may vary.

The program has to be started on the command line with:

/usr/local/spamalot/spamalot.py


-102-

17 Appendix: Product sheets for sound components

17.1 M-audio Delta 1010 specifications:

All specifications are found in M-audio’s official web site (www.m-audio.com).

10-input, 10-output recording interface

Supports up to 24-bit, 96kHz operation

PCI host card with DSP for digital mixing

Sturdy rack-mounted I/O interface

Eight balanced/unbalanced analog inputs and outputs on 1/4” connectors with +4dB or

-10dB operation (operating levels are individually selectable for each channel)

MIDI, Word Clock, and S/PDIF inputs and outputs

Balanced or unbalanced operation

High dynamic range: D/A 114dB, A/D 109dB (A-weighted)

Low distortion (measured THD @ 0dBFS): A/D 0.001%, D/A 0.0015%.

All data paths support up to 24bit/96kHz performance.

Control Panel software for mixing, routing, and monitoring capabilities

Sample-accurate hardware sync allows linking of up to four Delta 1010 interfaces in

one computer

Windows XP drivers for ASIO/ASIO2, WDM, DirectX, MME, and GSIF/GSIF2

protocols.

Mac OS X drivers for Core Audio and Core MIDI

Linux drivers for ALSA

17.2 M-audio Delta 1010LT specification:

All specifications are found in M-audio’s official web site (www.m-audio.com).

10x10 24-bit/96khz full-duplex recording interface.

PCI host card with two external, color-coded breakout cables.

8x8 analog I/O, balanced on female XLR and unbalanced on gold-plated RCA

connectors, with output line level adjustments selectable within the Delta Control

Panel.

The two balanced analog inputs can be set via hardware jumpers to accept microphone

level signals or line level signals.

S/PDIF digital I/O supports a variety of settings, including AC3 or DTS surround (PC

only) and copy protection schemes, which can be set via the Delta Control Panel.

External synchronization up to 100kHz via word clock I/O on BNC connectors.

1x1 MIDI I/O on standard DIN jacks.

High dynamic range (A-weighted measured): D/A 101.5 dB, A/D 99.6 dB.

Low distortion (measured THD @ 0dBFS): A/D and D/A less than 0.002%.

Frequency Response: 22-22kHz, -0.2,-0.4dB @48kHz; 22-40kHz,-0.2,-0.7dB

@96kHz

All data paths support up to 24bit/96kHz performance, no upgrades necessary.

Comprehensive digital mixing, routing, and monitoring capabilities with included

Delta Control Panel software.

Hardware sample-accurate sync will allow linking of multiple Delta units via S/PDIF.


-103-

Windows XP, 2000/ME and 95/98 multi-card, multi-client drivers with ASIO1 and

ASIO2 multi-card, GSIF and EASI drivers included; Windows NT multi-card drivers

also included.

Macintosh control panel and drivers with ASIO1, ASIO2, and legacy ASIO support

for OS 8.5.1 or higher.

Linux drivers for ALSA


-104-

17.3 MD-40 specifications:

All specifications are found in DNH’s web site – product sheets.

Material/Colour ABS / Black/White

Mounting Bracket

Termination Screw terminal

Weight 2,6 kg

IP-rating (UL Equivalent) 44

Max. / min. amb. temp 90°C / -40°C

Rated / max. power 40W / 60W

SPL 1W/1m 87 db

SPL rated power 103 db

Effective freq. range 60 - 20000 Hz

Dispersion (-6dB) 1kHz / 4kHz

Directivity factor, Q

Figure 35. Frequency response of MD-40

Figure 36. Technical drawing of MD-40

17.4 CAP-15(T) specifications:

All specifications are found in DNH’s web site – product sheets.


-105-

Material/Colour(Aluminium/PA)/RAL9010 or anodized

Mounting Bracket

Termination PG-nipple M-20 and Screw terminals

Weight 2.1 kg

IP-rating (UL Equivalent) 0

Max. / min. amb. temp 90°C /-40 °C

Rated / max. power 15W / 20 W

SPL 1W/1m 92 db

SPL rated power 103 db

Effective freq. range 150- 20000 Hz

Dispersion (-6dB) 1kHz / 4kHz 130° / 50°

Directivity factor Q

Figur 37 Frequency response of CAP-15(T)

Figur 38 Technical drawing of CAP-15(T)

17.5 IMG STA-1508 and CAP-15(T) on 100 V transmission lines.

This attachment will describe how to install 100 V transmission lines on the 3D sculpture’s

sound system.


-106-

It has been ordered 7 transformers which are going to be used on each channel. Figure 39

shows how to do this connection.

Figure 39. Connection for using 100 V transmission lines

From the left on figure 39 there is the green connection socket which is used on the IMG

STA-1508 amplifier that must be connected to a transformer (50/100V) on each channel. The

primary (input) connection uses black and white cords. From there on use 15W tapping,

which on most the transformers is the orange cord, also use the black cord as common

(COM). From the 15W tapping the speaker cables must be connected, by using screw

connections or something similar. In the CAP-15(T) speakers use the screw connections

which are connected to the white and red cord on the transformer (100/50V).

17.6 IMG STA-1508 Amplifier specifications

The specifications (table 4) are from the Stage Line STA-1508 data sheet. Table 4. Specifications for the STA-1508 amplifier


-107-

18 Appendix: Gantt chart

ID Aktivitetsnavn Start Slutt

1 Pre-project ti 16.01.07 ti 30.01.07

2 Time schedule for the pre-project ti 16.01.07 ti 16.01.07

3 Problem description fr 19.01.07 fr 19.01.07

4 Goals to 18.01.07 ma 22.01.07

5 Product specification ma 29.01.07 ma 29.01.07

6 Problem areas ti 23.01.07 ti 23.01.07

7 Miscellaneous on the pre-project ma 29.01.07 ti 30.01.07

8 Time schedule for the Main project ti 23.01.07 ti 30.01.07

9 Dividing into work packages ti 23.01.07 ti 23.01.07

10 Time schedule ti 23.01.07 ma 29.01.07

11 Equipment and resource list fr 26.01.07 fr 26.01.07

12 Budget ti 23.01.07 ti 30.01.07

13 Pre-project report examination ti 30.01.07 ti 30.01.07

14 Corrections on the pre-project report? ti 30.01.07 ti 30.01.07

15 If no corrections: Handing in the report ti 30.01.07 ti 30.01.07

16 Main Project on 17.01.07 fr 11.05.07

17 Website on 31.01.07 on 09.05.07

18 Hardware research on 17.01.07 fr 02.02.07

19 Bluetooth receiver on 17.01.07 fr 02.02.07

20 Computer and soundcard ma 22.01.07 fr 02.02.07

21 Power amplifier ma 22.01.07 fr 02.02.07

22 Speakers ti 23.01.07 fr 02.02.07

23 Miscellaneous on 24.01.07 fr 02.02.07

24 Ordering fr 02.02.07 fr 02.02.07

25 Software research on 17.01.07 on 07.02.07

26 Bluetooth software on 17.01.07 fr 02.02.07

27 Sound processing software on 17.01.07 fr 02.02.07

28 Java, C++ or Python? on 24.01.07 on 07.02.07

29 Ordering fr 02.02.07 fr 02.02.07

30 Training fr 02.02.07 fr 02.03.07

31 Bluetooth programming fr 02.02.07 fr 02.03.07

32 Socket programming fr 02.02.07 fr 02.03.07

33 PD programming ma 05.02.07 fr 02.03.07

34 Java, C++ or Python ma 05.02.07 fr 02.03.07

35 Programming on 07.02.07 ma 30.04.07

36 Bluetooth interface on 07.02.07 ma 30.04.07

37 Web interface on 07.02.07 ma 30.04.07

38 PD on 07.02.07 ma 30.04.07

39 Framwork programming ma 12.02.07 on 04.04.07

40 Planning ma 12.02.07 fr 23.02.07

41 Programming fr 23.02.07 on 04.04.07

42 Testing ma 12.02.07 fr 11.05.07

43 Sound system ma 12.02.07 ma 30.04.07

44 Final test ti 01.05.07 fr 11.05.07

45 Commissioning on 31.01.07 fr 11.05.07

46 Handing in the main project fr 11.05.07 fr 11.05.07

47 Project report on 31.01.07 fr 11.05.07

Project group

Project group

Project group

Einar Thorsrud

Thomas Asphaug

Project group

Thomas Tollefsen

Thomas Tollefsen

Thomas Asphaug

Even Martin Grytå

Håkon Grønning

30.01

Einar Thorsrud;Even Martin Grytå

Thomas Tollefsen;Thomas Asphaug

Thomas Tollefsen

Thomas Asphaug

Even Martin Grytå

02.02

Einar Thorsrud

Even Martin Grytå;Thomas Asphaug;Thomas Tollefsen

Project group

02.02

Einar Thorsrud

Even Martin Grytå;Thomas Asphaug;Thomas Tollefsen;C hristi

Project group

Project group

m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o15. jan. 07 22. jan. 07 29. jan. 07 05. feb. 07 12. feb. 07 19. feb. 07 26. feb. 07 05. mar. 07 12. mar. 07

Aktivitet

Deling

Fremdrift

Milepæl

Sammendrag

Prosjektsammendrag

Eksterne aktiviteter

Ekstern milepæl

Tidsfrist

Side 1

Prosjekt: GANT_hovedprosjekt.mpDato: fr 02.02.07

ID Aktivitetsnavn Start

1 Pre-project ti 16.01.07

2 Time schedule for the pre-project ti 16.01.07

3 Problem description fr 19.01.07

4 Goals to 18.01.07

5 Product specification ma 29.01.07

6 Problem areas ti 23.01.07

7 Miscellaneous on the pre-project ma 29.01.07

8 Time schedule for the Main project ti 23.01.07

9 Dividing into work packages ti 23.01.07

10 Time schedule ti 23.01.07

11 Equipment and resource list fr 26.01.07

12 Budget ti 23.01.07

13 Pre-project report examination ti 30.01.07

14 Corrections on the pre-project report? ti 30.01.07

15 If no corrections: Handing in the report ti 30.01.07

16 Main Project on 17.01.07

17 Website on 31.01.07

18 Hardware research on 17.01.07

19 Bluetooth receiver on 17.01.07

20 Computer and soundcard ma 22.01.07

21 Power amplifier ma 22.01.07

22 Speakers ti 23.01.07

23 Miscellaneous on 24.01.07

24 Ordering fr 02.02.07

25 Software research on 17.01.07

26 Bluetooth software on 17.01.07

27 Sound processing software on 17.01.07

28 Java, C++ or Python? on 24.01.07

29 Ordering fr 02.02.07

30 Training fr 02.02.07

31 Bluetooth programming fr 02.02.07

32 Socket programming fr 02.02.07

33 PD programming ma 05.02.07

34 Java, C++ or Python ma 05.02.07

35 Programming on 07.02.07

36 Bluetooth interface on 07.02.07

37 Web interface on 07.02.07

38 PD on 07.02.07

39 Framwork programming ma 12.02.07

40 Planning ma 12.02.07

41 Programming fr 23.02.07

42 Testing ma 12.02.07

43 Sound system ma 12.02.07

44 Final test ti 01.05.07

45 Commissioning on 31.01.07

46 Handing in the main project fr 11.05.07

47 Project report on 31.01.07

Einar Thorsrud;Christina Biels

a Bielsa

Einar Thorsrud

Project group

Even Martin Grytå;Thomas Asphaug;Thomas Tollefsen;C hristina Bielsa

Project group

Project group

11.05

Project group

t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t19. mar. 07 26. mar. 07 02. apr. 07 09. apr. 07 16. apr. 07 23. apr. 07 30. apr. 07 07. mai. 07 14. mai. 0

Aktivitet

Deling

Fremdrift

Milepæl

Sammendrag

Prosjektsammendrag

Eksterne aktiviteter

Ekstern milepæl

Tidsfrist

Side 2

Prosjekt: GANT_hovedprosjekt.mpDato: fr 02.02.07