Tuesday, June 27, 2006

O1 Perspective

O1 view of performers, audience, contact mics, computer...

You don't know until you try to make music for seven hours whether such a task is even possible. In the weeks leading up to O1 I started assembling materials from the concepts that Katarina Mojzisova had discussed with me. Much of the piece revolved around definitions of the miniature, so I started my process there.

miniature: descriptive term for a short Romantic piece, usually for piano

This definition led me to select piano as my first raw material. I found stereo samples of a Steinway & Sons 3145A recorded with a stereo pair of Neumann KM 84 microphones. This is part of the collection of instruments made available by the University of Iowa Electronic Music Studios. These required a great deal of post-processing before they were usable. To a lesser degree I used samples of short pieces played by Glenn Gould.

the dancer

miniature: derived from the Latin "minium", red lead. A picture in an ancient or medieval manuscript

From this definition came the second sound source: paper. I cut, crumpled, and otherwise manipulated various items of paper and sampled these into the computer.

Katarina had asked for rhythmic material, since such is necessary for her to sustain dancing over such a long period. Using various processing techniques, I manipulated the paper samples into a drum kit that I could then play back in various ways.

the sound artist

miniature: copy that reproduces something in greatly reduced size

miniature: a work of art where they represented object is created on a much-reduced scale

Granular synthesis works by cutting up a stream of sound into small particles time-wise, and then assembling them again with altered pitch, duration, envelope, amplitude, and so on. The greatly reduced size of the components engenders rich sonic results.

I decided to concentrate on that method of sound manipulation and ignore additive, subtractive, or other synthesis possibilities.

bowl of fruit but no still life

Finally, I wanted an interactive element. I taped two contact microphones to a metal tray, and made this "instrument" playable with some pennies and other small coins.

Piano / Paper / Pennies: that has a nice symmetry to it.

I then spent a couple of weeks assembling instruments in Reaktor, and coming up with a mixer setup that would allow channeling of any of the sources through such instruments for processing.

The performance itself went well. People dropped in throughout the day; some stayed for short periods but others were captivated and stayed for hours. A few people took Katarina's place and gave her a break from dancing. This was part of her original conception: that she could only stop dancing if someone else would fill in. Places of exhaustion she marked with red tape on the floor.

Some visitors were delighted to play around with the tray/penny instrument. Between the organically evolving sounds and shared dance a certain happy collaborative environment was created.

In this instance a seven-hour performance that at first looked only "possible" was made "probable" and then, finally, became inevitable.

I must first of all thank Katarina for inviting me to take part; Susannah for the photos and dancing; Róisín for the video, dancing, and play; Davide and the Daghdha Dance Company for the opportunity. Finally thank you to everyone who attended and participated.

See also my announcement with poster.
Saturday, June 10, 2006

O1 All-Day Performance

O1 event
This is one of the little flyers, larger than life-size here, made for my upcoming performance.

Following is the full poster with all the details. Click on it to get a larger size.

How is Katarina going to dance for seven hours without a break? How am I going to produce live sounds for the same length of time? The only way to find out is to drop by the Daghdha Space. It's the last event of the season, so don't miss out!

Wednesday, June 07, 2006

Website Security Considerations

It is not always easy to determine what type of a security system should be put into place when building a website. Here I outline some of the basic security principles, as well as some decision points that need to be considered. I consider software-based systems (challenge-response with user name and password) rather than hardware implementations like biometrics or dongles, since these are rarely used on websites and certainly not for those I build!

Principles


Here are some basic security principles which nonetheless appear to be non-obvious at times.

1. Security is never absolute. There is no such thing as a secure system.

2. The more secure a system, the more trouble it is to use it. Every security system is a balancing act between security and convenience.

3. A security system that is implemented poorly is worse than none at all. This is because hidden flaws are harder to diagnose and fix that weaknesses which are known and planned for.

4. The more complex a security system, the more expensive it is to implement, and the more likely it is to be implemented poorly.

5. Every security system has its weakest link. There is no point addressing other aspects of the system until the weakest link is hardened.

Therefore, one should pick a level of security which balances the expectations of all parties (client, customers, technicians), is reasonably easy to implement, and finds a comfortable point on the secure/convenient scale.

Scope


For a website there are several modalities of a security systems to consider. The first is scope. Here are some possibilities:

1. None: All access is open.

2. Partial: A login system is in use for certain pages only.

3. Full: A login system is in use for all pages.

4. Variant: One might have two levels of password protection, or simply challenge the user with the same password requirement for access to areas considered especially sensitive (for example, eBay does this).

No public website has a completely full security scope, since this means that even the home page would not be accessible to search engine robots and the like.

Duration


The second major dimension is that of time. How long will the secure login be active? More than one of the following options may be in place at once.

1. For a single transaction.

2. For a fixed time period.

3. Until a fixed period of inactivity has occurred (eg: a time-out).

4. Until the user explicitly logs out.

5. Until the user navigates away from the site.

Problems


Here are some common problems of website password systems.

1. They email you the password. Email channels are not secure. Furthermore, if someone compromises your email account they can look for all your passwords in one fell swoop.

2. They store the email in unencrypted form, for example in a database.

3. They allow you to work around the password with a question like "What is your pet's name?" or something similar. This is much easier to guess or socially engineer than the password itself.

4. The password handling is done on the client side (in JavaScript) rather than on the server side.

References


The article Password Management Best Practices is a worthwhile read.
Wednesday, June 07, 2006

Spring Update

Just thought I'd say "hello" and bring to your notice a change to my sidebar. There are two new categories: "photos" has been split from "media" and "events" from "miscellaneous". Hopefully this will help you hone in on what you're looking for, since not everyone has the same range of interests as yours truly.

I've also re-jigged the top of the sidebar so it displays links to my other sites. Some of you may know that my articles on programming and web design have their own home at diagrammes modernes. But some may not -- now it is clear. Because of this I've removed the web links to Python sites, so I don't have to maintain them in two places.

I've made a bunch of template corrections to reduce validation errors, following the process I wrote about in Validating a Blogger Page. If you write in Blogger and have an interest in web standards that article makes a good read.

It's the beginning of June and as I look back over the spring I see that I still haven't written some articles I've promised... although I've written a lot I never thought I would. I've got a backlog of topics that just keeps growing. So if you want to encourage me, leave comments, let me know what you like, or even donate a little.

As always... thanks for reading!
Saturday, June 03, 2006

Interview Microphones

A poster in a MicroTrack thread recently asked about microphones for interview situations, specifically those from Sound Professionals and Reactive Sounds. My reply became voluminous enough that I thought it best to post an entire article on interview microphones.

The stubby T-shaped stereo mic that comes with the MicroTrack is not convenient, since the interviewer ends up "physically passing the unit back and forth", as our poster described. There are two solutions: a pair of lavalier mics that can be clipped to interviewer and subject, or a single-point stereo mic that can be pointed in the right direction.

Lavalier mics are handy when you need something discrete, particularly for stage and TV work.

On the high end (over $400) you've got mics like the Sennheiser MKE series and the DPA 4060/4061. You can save some money by going for the slightly less exacting Sennheiser ME 102 and similar.

A good lav in the mid-range is the Audio-Technica AT899, at $275. Remember though that if you want to record the interviewer as well you will need two of them!

For impromptu situations, in-the-street interviews and the like a battery-powered single-point stereo mic like the AT822 ($250) is a common choice.

Better yet, just do like the BBC do, get a Beyer M58 ($180) and forget it! This mic has a long handle for getting into people's faces and a hot output to handle weak inputs.

I'm not going to specifically address the mics from the two companies suggested by the poster because at the lower end I do not imagine them good value, and at higher prices why not just get name-brand professional kit?

One thing you may not know is that many lower priced mics use a Panasonic WM-61A omni cap. You can buy these raw in prices at around $1. By the time companies get through with them they cost much more, but I guess that's "value added"! The best thing to do is purchase mics built from these caps from individuals on eBay. I can recommend seller micro_sound who offers a binaural pair at the fair price of $23.

A cheap set of mics like this is good as a "reference standard" in the low-end, and as a pair you can throw around and not care if they get wrecked, lost, or stolen. They are surprisingly usable for tasks like voice recording.

Disclaimer: I have not used many of the more expensive mics mentioned above, but instead have based this article on best practices recommended by others. Also, I don't know how any of these work with the MicroTrack. It's always best to test mics with the specific gear (power, recorder) you are using.

Further reading: A Transom article addressed a similar issue.
Friday, June 02, 2006

Voice Recognition For Programmers

Over a decade ago my fulltime career as a programmer was sidelined when I developed a Repetitive Strain Injury (RSI). While recovering (a process that took years) I tried many speech recognition products. In fact, I was an early adopter, back when you needed to spend ten grand to get a system that supported DOS only. I tried Dragon Dictate, IBM VoiceType, and so on. While ok and very annoying for natural language dictation, these products are unusable and even more annoying for programming.

The issue is, of course, that programme code does not follow the grammar of a natural language. Now, help is on the way, via the open source project Voice Code, developed by the National Research Council of Canada. This New Scientist article contains a few more details, plus links to discussion forums.

Of special note is the fact that the current version was written to support Python, since the clean and simple syntax lends itself especially well to verbal interpretation.