Launch the MySQL daemon

% sudo /usr/local/bin/mysqld_safe [type ^Z] % bg

Stop the MySQL daemon

% mysqladmin shutdown -p [type in the password when prompted] % mysqld --skip-grant-tables

Change MySQL's root password

% mysqladmin -u root -p password NEW_PASSWORD [type in the old password when prompted]

Backup a MySQL database

% mysqldump --opt -uUSERNAME -pPASSWORD -h HOSTNAME DBNAME > db.txt % zip db.zip db.txt

If you can't remember USERNAME, PASSWORD, HOSTNAME, or DBNAME, you can find them in (for example) your WordPress wp-config.php file.

During installation phpMyAdmin says "#2002 — The server is not responding (or the local MySQL server's socket is not correctly configured)":

I don't claim to understand this one at all. But some combination of these seem to do the trick:

1. Log on as root and create the file /etc/my.cnf. Insert these lines into the file:
   [client] socket=/var/mysql/mysql.sock [mysqld] socket=/var/mysql/mysql.sock
2. Look at /etc/php.ini and find the line concerning "Default socket name for local MySQL connects". There should be nothing after the equals sign:
   mysql.default_socket =
3. Execute phpinfo() and examine all the references to mysql. Look for any weirdnesses and inconsistencies there. Make sure the mysql socket names and directory paths all make sense with your php installation.

Check your PHP configuration

Create a text file containing the following single line of code:

<?php phpinfo() ?>

Name the file something useful like phpinfo.php and load it into your browser.

Handy references

• Working with PHP 5 in Mac OS X 10.5 (Leopard)

Problem: The Apache web server isn't finding a website's top-level directory named /icons.

Cause: By default, Mac OS X 10.5.5's Apache server has /icons aliased to /usr/share/httpd/icons/. The server will thus always look there, instead of in your /icons directory.

Fix: Disable this alias. Launch Terminal, edit the file /etc/apache2/extra/httpd-autoindex.conf, and change this line

Alias /icons/ "/usr/share/httpd/icons/"

# Alias /icons/ "/usr/share/httpd/icons/"

(The '#' is Apache's "comment" character. Apache treats the rest of the line as a comment, and ignores it.) Now restart Apache (apachectl graceful). Your browser should now find your icons just fine.

• It provides a seamless way for several people to collaborate on the same project without stepping on each other's toes. (Have you ever had a collaborator delete one of your crucial files?)
• You can easily document the changes you make to your code.
• If you make a mistake, You can easily "roll back" to an earlier version.

Making the switch to Subversion is well worth the modest effort required. (If I can do it, so can you.) This "Quickie" article will take you through (1) creating an online repository for your site; (2) creating a development site for doing live testing on your live server; and (3) using Subversion in routine development work. There are, doubtless, other, better, ways to accomplish all this, but this is what has worked for me.

Assumptions in this article

• You have a basic grasp of what Subversion is, what it's for, and (roughly) how to use it
• Subversion is installed on your server and on your local computers
• You have a site (we'll call it www.example.com) that's already up and running on your Apache server. I'll also assume your site lives in the server directory ~/example.com (i.e., in your home directory)
• You have login (shell) access to the server

Setup

For starters, you'll need to create two new sub-domains. Follow your web host's instructions about how to do that:

1. Create two new sub-domains: svn.example.com (for your svn repository) and dev.example.com (for your development site). [If you're using DreamHost, go to your webpanel and select Domains » Manage Domains » Add New Domain/Sub-Domain.] It's a good idea to password-protect your dev site, so that only you and your co-developers have access to your not-quite-ready-for-prime-time version of the site.
2. Create a new Subversion project. We'll give it the id "myproject", and install it to the svn.example.com URL. (Don't forget the username and password you choose here!) [If you're using DreamHost, you can create a new Subversion project right from your webpanel: select Goodies » Subversion.]

The rest of the setup happens through the login shell on your server. So log on to your server and do the following:

3. To hide the Subversion directories from web browsers, create (or edit) the .htaccess file in ~/dev.example.com. Add the following line:

   RedirectMatch 403 /\.svn.*$

4. Add this line also to the .htaccess file in ~/www.example.com.
5. Create an empty trunk/branch/tag directory structure as the initial import into the project. (In the following, "YOURNAME" is your svn username.)

   % cd % mkdir tmp % cd tmp % mkdir branches trunk tags % svn import . --username YOURNAME -m "initial import" \ http://svn.example.com/myproject Authentication realm: <http://svn.example.com:80> My Project Password for 'YOURNAME': {enter password} Adding trunk Adding branches Adding tags Committed revision 1. % cd .. % /bin/rm -fr tmp

6. Now go ahead and import your current site (www.example.com) into the repository:

   % cd ~/www.example.com % svn import . --username YOURNAME -m "importing website" \ http://svn.example.com/myproject/trunk

   If your site contains some dirs that you want to exclude from the development version (e.g., wordPress), you might prefer to import the site on a directory-by-directory basis:

   % cd ~/www.example.com % svn import ./keep_me1 --username YOURNAME \ -m "importing keep_me1 directory" \ http://svn.example.com/myproject/trunk/keep_me1 % svn import ./keep_me2 --username YOURNAME \ -m "importing keep_me2 directory" \ http://svn.example.com/myproject/trunk/keep_me2

   Or, to be more efficient about it, you could run a little shell script like this:

   #!/bin/tcsh -f foreach d ( some_dir another_dir yet_another_dir ) { svn import $d --username YOURNAME -m "importing $d directory" \ http://svn.example.com/myproject/trunk/${d} }

7. Checkout a working copy to the development site (dev.example.com):

   % svn co http://svn.example.com/myproject/trunk ~/dev.example.com

Your dev site (dev.example.com) now contains a full working copy of the latest revision of your site.

Routine workflow

1. Checkout a working copy from the repository to your local machine. (I recommend the svnX GUI client for the Mac.)
2. Develop and test your code, etc., on your local machine.
3. At logical stages (say, when you fix a bug or finish writing a new function), commit your changes to the repository. Some good habits to practice: (1) Always update your working copy before each commit. Always jot down a meaningful comment with each commit. (Instead of saying "Fixed a bug", say "Fixed function Foo() in bar.php that had wrong mySQL query.")
4. Log on to your server and update the development site:

   % svn up ~/dev.example.com

5. View the dev site. You may discover bugs on the dev site that weren't apparent on your local machine. (They might be using different versions of Apache, PHP, mySQL, etc.) If there are bugs to be worked out, iron them out on your local working copy (i.e., go back to Step 2).
6. If you're satisfied that your dev site is good to go, then either checkout a copy to your live deployment site:

   % svn co http://svn.example.com/myproject/trunk ~/www.example.com

   or update the copy already in your deployment site:

   % svn up ~/www.example.com

7. Double-check that the deployment site (http://www.example.com) is working to your satisfaction. If it's not, go back to Step 2. If it is OK, you're done!

The development cycle is now much simpler and safer. If you go on the road, just checkout a working copy onto your laptop, make your changes, and commit them back to the repository when you get the chance. If you (or your collaborator) made a mistake 6 revisions ago, just tell svn to checkout or update to an earlier revision.

Nice!

But eventually you may want to use server-side includes (SSI) to generate standard headers or footers on your pages. SSI are probably readily available on your webhost's server, but to get them working on your Mac requires one small step: you have to configure Apache to activate a virtual server for each of your sites. Don't panic; it's easy to do.

Let's say you have a site installed at ~yourname/Sites/project1. And let's say the site's pages have a standard footer, which is contained in the file ~yourname/Sites/project1/includes/footer.html. You'd like to be able to put the following SSI line in every file on your site:

<!--#include virtual="/includes/footer.html" -->

Trouble is, the server interprets that path as relative to the DocumentRoot setting in your Apache configuration. On the Mac, the default setting (in /etc/httpd.conf) is

DocumentRoot "/Library/WebServer/Documents"

So when you load a page from the site, the server looks for your footer in /Library/WebServer/Documents/includes/footer.html. Since that's not where your footer lives, you'll probably just get this unhelpful error:

[an error occurred while processing this directive]

You could move your includes into /Library/WebServer/Documents, but that's a supremely bad idea; you'll soon go crazy keeping track of all your files scattered across the filesystem. Instead, take 2 minutes to do things properly, by setting up a virtual host on your Mac. This will allow you to set the DocumentRoot for each of your web projects. Here's how:

1. Open Terminal and type: cd /etc/httpd/users. You should see a file in there with a name like yourname.conf where "yourname" is your Mac user name.
2. Type sudo vi yourname.conf and enter your password, if asked.
3. Insert the following lines at the end of the file

   NameVirtualHost 127.0.0.1:80 <VirtualHost project1> ServerName project1 DocumentRoot /Users/yourname/Sites/project1 </VirtualHost>

   (If you have more sites, just add more <VirtualHost> blocks.)

4. Save and quit (type :wq)
5. Restart Apache: sudo apachectl graceful
6. Finally, edit your hosts file (sudo vi /etc/hosts) and insert the following lines at the end:

   127.0.0.1 project1

   (If you have more sites, just add more lines in that format. For example, 127.0.0.1 project2, etc.)

7. Now point your browser to http://project1 and your SSI include files will be correctly displayed.

• Bounce desired audio from ProTools to WAV files. [I haven't tried this with AIFF.]
• For each file: import it into Audacity and export it as a WAV file. [For some reason, the ADAT HD24 doesn't recognize WAV files created by ProTools — the ftp client hangs after a few hundred bytes into the upload.]
• Rename the files as described in the HD24 manual (“TrackXX.wav” — refer to p.86 of the manual). [The ADAT HD24 doesn't recognize WAV files created by ProTools — I can't even upload them.]
• Connect the HD24 to the Mac via an ethernet hub. [I simply could not establish a direct ethernet connection, with either a direct or a crossover cable.]
• Use Fetch to upload files to the appropriate directory. [Cyberduck connects with the HD24 OK, but it displays each folder in the HD24 as empty!]

Here’s how to concatenate two songs. We’ll assume that Drive1 contains “Song1″ and “Song2″, and that Drive2 has enough free space for one copy of Song1 and two copies of Song2.

1. Select Drive1 and copy Song1 and Song2 to Drive2. [see p. 54 in the manual]
2. Select Drive2. (From here on we’ll only need Drive2)
3. Select song “Song1″ and rename it to “Merge” [p. 33]
4. Select song “Song2″ and write-protect it
5. Set the Edit Start and Edit End points to each end of “Song2″ [p. 56]
6. Select a track (or group of tracks) to copy.
7. Copy
8. Select song “Merge”
9. Set Edit Start to the end of “Merge”.
10. Select the track(s) to paste (must be the same as the track(s) you selected in step 6!).
11. Paste

(If your songs are long, your HD24’s copy/paste buffer may not be large enough to copy and paste all your tracks at once, and you’ll get an error message. If this occurs, try copying/pasting fewer tracks at once.)

You’ve now appended a copy of one (or more) track(s) from “Song2″ to the corresponding track(s) from “Song1″. If your songs contain additional tracks, repeat the following steps as needed:

1. Select song “Song2″
2. Select the next track (or group of tracks) to copy
3. Copy
4. Select song “Merge”
5. Select the track(s) to paste (must be the same as the track(s) you selected in step 2!).
6. Paste

Now you can create a loop for your merged song, as described on pp. 45-46 of the manual. And don’t forget to write-protect your merged song!

The Operating System held off interrupts for too long. If this occurs frequently, try increasing the "H/W Buffer Size" in the Playback Engine panel. (-6093)

The Digidesign website and suggests several workarounds, including:

• Reduce CPU Usage to "below 95%"
• Connect Digi 002 to FireWire port on Mac G5's front panel
• Reduce number of active plugins

What works for me:

• Quit ProTools, re-launch, and try again (works sometimes)
• Connect Digi 002 to FireWire port on Mac G5's front panel

A handy toolkit

IRIS website	IDA station map	Earthquake news
IDA station worksheet	Azimuthal planning map	panQuake

Obtaining seismic data (an abbreviated HOWTO):

1. Review seismic event catalog
2. Review IRIS data holdings by station
3. Place breq_fast request
4. Check order status
5. Download order

Handy calculators

Notes and emerging documentation

• Deep Earth Dome ~ a sound installation of the seismic sounds of Earth
• Turning Earth Noise into Sound: Notes for a Future "How-to" ~ my jottings, slowly taking shape
• Trucks in Turkmenistan? Forensic Seismology Brings Sound Art Down to Earth (060817) ~ my reflections on misidentifying some mysterious "crustal chirps" from Turkmenistan
• Sound file protocols (notes to self)
• Determining speaker placement in a spherical model space
• Modeling a spherical space using "N+2" loudspeaker geometry

Useful references

(For links to Earth sounds and sound art, see my Links of Note.)

• Auditory Seismology ~ Dr. Florian Dombois's explorations with audification of seismic data
• Dome Calculator (Desert Domes) ~ a handy online JavaScript calculator for designing geodesic domes
• The Great Sumatra earthquake of December 2004 ~ geophysical synopsis of this catastrophic event
• IRIS (Incorporated Research Institutions for Seismology) ~ "a university research consortium dedicated to exploring the Earth's interior through the collection and distribution of seismographic data"
• "Model-Size to Full-Size Scaling" by Barney E. Klamecki ~ notes for a mechanical engineering class; applicable to acoustic Earth time- and space-scaling issues.
• Oklahoma Geological Survey Observatory Catalog of Nuclear Explosions
• Project IDA ~ the global broadband seismic network
• SAC (Seismic Analysis Code) ~ a big, powerful, and cumbersome program designed for the study of timeseries data, like seismograms. Although I don't use SAC in my earth sound work, many of the data files I work with arrive in SAC format.
• Yucca Valley at the Nevada Test Site ~ (what's left of it, that is, after more than a half-century of nuclear explosions)