A few months ago, our beloved breadmaker developed a fault. The plastic latch that holds the seed dispenser closed had snapped in half. A bit of Googling indicated that this was a common fault, caused by the constant heat cycling it experiences above the oven.

Thankfully, Panasonic offers spares for its breadmakers, so it’s possible to buy a genuine seed dispenser assembly on its own at a reasonable price, but I came across someone else who had 3D-printed a stainless steel replacement and thought I could have a go too. They had used Shapeways, and it had been possible to buy a replacement direct from Shapeways based on their model, but Shapeways were mid-collapse when I was looking at it, so it wasn’t really possible to make a new order on there.

I’d not used CAD before but I wanted to learn, and I’d watched enough videos of Martin Molin struggling to design a marble machine in Fusion360 to be dangerous, so I glued the original part back together and started measuring. I knew those cheap digital calipers I bought on a whim during a recreational hardware shop trip would come in handy eventually!

Eventually I had sketched out the dimensions and turned my sketches into a single solid object in Onshape. The next step was to find somewhere that would do stainless steel 3D printing.

I spent a morning uploading my file to various suppliers, and found the cheapest option to be IN3DTEC. I ordered the part for SLM printing in 316L stainless steel. The total came to USD 4.11 for the part, and USD 24.00 for delivery. I got a 6% new user discount, so the total came to USD 27.86 - within a couple of pounds of ordering the replacement assembly (priced at £20.76 as of writing this)!

If you’re doing this, make sure to prepare a drawing of the part that indicates how it fits into the mechanism, plus photos of the original part and the space that it sits in. I got an email from IN3DTEC after ordering, asking if I could provide this information to help inform them on how to print it.

The part arrived 15 days later, and was a good fit. I found that the end of the ‘hook’ was a little too high, a little too rough, and/or a little too sloped, but that was quickly resolved with a trip to the repair shop, where a rotary tool was available to grind down the end. The measurements I took were pretty accurate, and used to constrain the model’s dimensions, so I think the issue was caused at least in part by the difference in finish between the smooth plastic original and the sandblasted steel replacement - though the edge is also definitely sharper in the model than it was on the injection-moulded plastic original.

Over six months later, the latch is still working great, and I also get the satisfaction of knowing it won’t break any time soon. I’d definitely recommend doing this, as even a brand new replacement assembly will presumably experience the same fault eventually.

The latch is publicly available as an Onshape document; you can find it here. Feel free to modify it to adjust the hook.

There’s also another publicly-available model that I only just discovered while Googling for this article today, available here on Thingiverse.

The outcome of this guide should be a computer that boots straight into the Ubuntu desktop upon receiving power, hides the mouse cursor, and launches a fullscreen Firefox window pointed at your chosen URL. The computer will be safe to unplug thanks to a read-only file system, and will keep its screen on indefinitely. More information on this project can be found in its project documentation.

Step 1: Installing Ubuntu

Ubuntu is a free operating system based on Linux. It’s more lightweight, reliable (arguably) and customisable than Windows, so is an ideal option for this use case.

To install it, you’ll need three things:

• A computer to set up the Ubuntu installation media
• The computer that you want to put Ubuntu on
• A USB flash drive

You’ll probably want a capacity of at least 8GB (preferably 16GB) for the latter, and the first two items can be the same computer if necessary.

Ubuntu have their own instructions for this, so I won’t repeat them here - you can find them at ubuntu.com/tutorials/install-ubuntu-desktop. I’d recommend using the latest LTS version - at time of writing, this is 24.04 LTS. You only need the default selection of apps, and it is up to you whether to install the proprietary software - for simplicity I have chosen not to.

Make sure to un-tick the ‘Require my password to log in’ box when setting up your login details. I’d recommend still setting a password, though - this will ensure that only authorised users can change the computer’s settings in a meaningful way, as it will prompt you for it in these cases.

You don’t need any additional applications from App Center, or an Ubuntu Pro subscription.

Step 2: Installing necessary packages

The software we need on top of Ubuntu itself is:

• Firefox
• unclutter
• overlayroot

I’ll go into more depth on what the latter two are for later - I’d suggest reading this article in full before installing, as you may not need them for your use case.

Firefox should come with Ubuntu - if not, follow the official instructions.

The other two can be installed by opening a Terminal window and typing:

$ sudo apt install unclutter overlayroot

You’ll be prompted for your password, and probably also to confirm that you want to actually install the packages.

They won’t do anything until we configure them, so that’s what the next steps are going to be about!

Step 3: Setting up the computer

3a: Stopping the screen from turning off

This setting can be found in the Ubuntu settings, probably under ‘Power’. Make sure that the screen will never go blank, and the computer will never go to sleep.

3b: Configuring Wi-Fi if necessary

If your computer will be pointed at a website on the Internet, you’ll need to connect it to a network on location. If it’s not already configured, make sure you’re connected to the right network. If the network isn’t in the same place you’re setting up the computer, you can still set it up in advance - just select the ‘Connect to a hidden network’ option and fill in the settings as if the network was there. The computer will attempt to connect for a little bit and fail, but it will still have saved the network credentials.

3c: Enabling Unclutter

The unclutter package we installed before is a piece of software that hides the mouse cursor when it’s not being used. It’s very handy for this use case, as without it Ubuntu will show the mouse cursor all the time.

You can enable unclutter by launching the ‘Startup Applications’ app, and adding a new entry. The command to run is:

unclutter -idle 5 -root

The number after -idle tells unclutter how long to wait before hiding the mouse, in seconds. So, if the mouse isn’t touched for 5 seconds, unclutter will hide the mouse.

This process will launch unclutter when the computer starts up, but we’re not done yet. Recent versions of Ubuntu ship with the Wayland window manager enabled by default, but unclutter only supports X11. This is easy to fix, as both Wayland and X11 come installed with Ubuntu and you can easily switch back. There is no equivalent to unclutter for Wayland at the moment.

To make Ubuntu use X11 instead of Wayland, edit the file /etc/gdm3/custom.conf using either the Ubuntu text editor or a terminal-based file editor like nano, which comes with Ubuntu. You should see a line that says:

#WaylandEnable=false

The hash is ‘commenting out’ this line, effectively disabling it. Uncomment the line by deleting the hash, leaving:

WaylandEnable=false

Save the file and restart the computer. Once done, you should find that your cursor disappears, only reappearing when you move the mouse.

3d: Enable SSH

If your kiosk computer is going to be hard to access, you may wish to enable SSH. This allows you to remotely control it across the network through the command line. I chose not to do this, but you can enable it easily and there are many guides on how to do this elsewhere. Make sure to include your Ubuntu version when searching.

Step 4: Actually enabling the kiosk web browser

Most modern browsers have a kiosk mode; I chose to use Firefox as it is what I use anyway and it comes pre-installed with Ubuntu.

Enabling the browser is pretty simple - just open the “Startup Applications” app as before, and add a new entry. The command should be:

firefox -kiosk -private-window "https://your-url.com/whatever/something?cool"

The kiosk flag fullscreens the browser and makes it impossible to un-full-screen without using system shortcuts like Alt-F4, and the -private-window means the window will open in private mode (otherwise known as ‘incognito’ in other browsers). You can omit these flags if they don’t match what you’re after.

There’s more information on kiosk mode in Firefox here.

Restart the computer. You should now find that the browser launches as expected!

Step 5: Setting up a read-only file system using overlayroot

If you plan to turn your kiosk on and off using a mains timer, or just turn it on and off at the plug, I’d suggest setting up your computer to use a read-only file system. What this does is:

• Duplicate the computer’s file system as soon as it turns on
• Make the computer use this copy at all times once on

The copy is lost each time the computer turns off, but the original copy is retained as-is. This means that, even if the computer is turned off at a critical moment and something is broken, it will re-duplicate the original, unchanged copy of the file system as soon as it turns back on again.

Essentially, it will ensure that you can connect and disconnect your kiosk computer’s power supply however you like, without any risk of corrupting anything and causing it to fail to boot the next time.

Step 5a: Disabling software updates

If you’re using a read-only file system, chances are you will want to disable software updates. Otherwise, your computer will apply the same updates every time it turns on and then lose them when it’s turned off again. Updates can also cause unwanted prompts to appear on the screen, such as ‘restart this computer to update to blahblah’.

Obviously, this presents a security risk, so you may wish to have a plan to periodically log into your machines and upgrade the software they are running.

To disable software updates, do the following:

• Launch the ‘Software & Updates’ application.
• Navigate to the ‘Updates’ tab.
• Set ‘Automatically check for updates’ to ‘Never’. This ensures that Ubuntu’s Software Updater programme won’t run unprompted.
• Execute the command sudo snap refresh --hold. This ensures that applications installed with the snap system (including probably Firefox) won’t be upgraded automatically.

Step 5b: Disabling grub’s recordfail timeout

Enabling overlayroot often causes grub, Ubuntu’s bootloader, to show itself when booting and impose a 30-second timeout. If this isn’t desirable for you, just do the following:

• Edit /etc/default/grub.
• On a new line, below the line that looks like GRUB_TIMEOUT=0, add GRUB_RECORDFAIL_TIMEOUT=$GRUB_TIMEOUT.
• Run sudo update-grub.

Step 5c: Actually enabling overlayroot

We installed overlayroot in step 2, so all that is left to do is to enable it. There is an important caveat to understand when enabling it: both the benefit and drawback of it is that all new data is lost when the computer is turned off. This stops the operating system getting corrupted, but it also means that any and all changes you make to the computer while it is powered up will be lost. That includes things like changing the URL of your kiosk, configuring a new Wi-Fi network, tweaking some Ubuntu settings, etc. It’s always possible to disable overlayroot, but this requires two reboots (one to disable and one to re-enable) so I’d strongly suggest making sure you have everything right before enabling overlayroot.

When you installed overlayroot, it created a file called /etc/overlayroot.conf. Opening it as we did with /etc/gdm3/custom.conf, you’ll find a lot of comments explaining the different options available and how to configure them. At the bottom, you’ll find the line:

overlayroot=""

Change this to:

overlayroot="tmpfs:swap=1,recurse=0"

Save the file and reboot. Your file system should now be protected. I’d recommend checking this by creating a file on the desktop and rebooting. If the file vanishes, overlayroot is working!

“Okay, but how do I disable overlayroot?”

In order to make changes to the original file system again, you need to access the ‘original’ file system and make the necessary changes. This can be done by executing:

$ sudo mount -o remount,rw /dev/sda3

Note that the /dev/sda3 part is the name of the disk that you want to re-mount. It may differ on your system, but you can find the name by running:

$ df -h
Filesystem              Size  Used Avail Use% Mounted on
# ...
/dev/sda3                96G   16G   76G  17% /media/root-ro
# ...

Look for the entry that’s mounted on /media/root-ro - most other options will have names like tmpfs so it should stick out.

Once you run this command, you will have access to the original file system again at /media/root-ro. If the change you want to make is simple, you can just edit the file(s) directly inside /media/root-ro, but if not then you probably want to reboot into writable file system, so you can make the necessary changes, re-enable overlayroot and restert. This can be done easily, just by editing the overlayroot configuration and rebooting.

The config can now be found at /media/root-ro/etc/overlayroot.conf - open this with your text editor to see the same configuration you changed to enable overlayroot. You can revert to the original file system by commenting out (=prepending with #) the two non-comment lines at the bottom of the file.

Once rebooted, you should find that your changes are persisted again. Re-enabling overlayroot is as simple as editing the configuration (now back at /etc/overlayroot.conf) and uncommenting the lines you commented out before. You may wish to leave a note on the desktop to future maintainers so they understand this and know how to make their changes actually save again!

A note on updates when using overlayroot

One of the downsides of using overlayroot is that it will prevent software from applying updates. This is not a problem for the most part, except in the case of security updates. This is not a huge concern for me, as the repair shop’s kiosk machines aren’t accessing anything particularly private or mission-critical, but you should evaluate this risk, minimise it as far as possible and implement an update schedule if necessary.

Step 6: Boot upon receiving power

If you want to switch the computer on and off by applying mains power, either with a manual switch or with a mains timer, you need it to turn on when it receives power. This is usually a setting in the BIOS; to set it you need to turn on the computer and repeatedly press a button on an attached keyboard until the BIOS appears. Typical candidates include F1, F2, F12 and Delete so if in doubt give those a try.

Look for a setting like ‘Restore on AC’, ‘AC Power Loss’ or ‘After Power Loss’. It should give you a few options, like ‘power off’, ‘restore previous state’ or ‘power on’. Select ‘power on’, then save and exit the BIOS. Your BIOS settings are stored separately to your Ubuntu operating system, so you don’t need to disable overlayroot for your settings to apply.

If you need help with accessing the BIOS or enabling boot on power on for your particular machine, the answer can often be found online through a quick web search.

Sources

I stole bits and pieces for this article from the following places:

• https://askubuntu.com/a/968265
• https://spin.atomicobject.com/protecting-ubuntu-root-filesystem/
• https://rex.writeas.com/use-overlay-filesystem-on-ubuntu
• https://askubuntu.com/questions/1046979

Next.js is a really powerful framework for maximising the performance of a React frontend. In this post, I’ll share how I used AWS Lambda, S3 and CloudFront to host it in the cloud. The example given will be for AWS, but is also applicable to other providers with similar services.

The feature that this guide relies upon is the Next.js “standalone” output mode. Enabling standalone mode tells Next.js to write only the files you need for production into the /.next/standalone/ directory. The code in the standalone build is only what’s needed to generate the content that your Next.js server returns (predominantly, HTML pages) and excludes all static assets such as images, compiled JS chunks and stylesheets. The standalone function is really lightweight, which makes it perfect for serverless hosting.

As the standalone function isn’t designed to serve static assets, we need to host them elsewhere. In AWS, the obvious product is S3, which is designed specifically for this task. It is possible to get your standalone function to serve the static assets directly by copying the public/ and .next/static/ directories into the standalone directory, but this is not recommended as it will increase the size of your serverless function and make it harder to write different caching rules for static content and the server-side generated responses that Next.js sends back.

The final major piece of the puzzle is how we route different requests to our serverless function versus our static content host. Again, AWS CloudFront is specifically designed for this. CloudFront is a global network of servers that sits behind your domain name and forwards client requests to your hosts. Responses can then be cached physically close to your users, which will maximise the performance of your website.

To summarise, here’s how your frontend will be configured by the end of this article:

I should note that this guide assumes that you want both your static assets and your Next.js function on the same domain. It should be pretty easy to adapt if you want to have a separate CDN domain for your static assets.

Step 1: Uploading your static assets to S3

After building your Next.js server, you’ll find that you have static assets in two places:

1. .next/static/
2. public/

The static directory contains a compiled version of everything inside your frontend codebase (including media files and client-side code). These are pretty straightforward to host - we can simply upload them somewhere, and tell Next.js where they live by providing it with the assetPrefix configuration value. Whatever you provide as the assetPrefix will be added to the start of any reference to your static assets in the HTML that your Next.js function returns. For example, if Next compiles some image to /.next/static/myImage.jpg, and you provide the https://myhost.com asset prefix, then any HTML that Next.js generates will refer to your image as https://myhost.com/_next/static/myImage.jpg.

The public directory is a bit more tricky. The things we put in public/ are generally things that we expect to find at the root of the frontend host. If we create some file at public/robots.txt, then we expect to find it at https://myfrontend.com/robots.txt. This creates a bit of a conflict with our Next.js server, because that also needs to live at the root of the frontend domain.

The easiest way to handle this is to:

• Move everything that’s only referred to by frontend code (ie, site media content) into the src directory (and thereby into .next/static)
• Organise anything that remains and that doesn’t need to live directly at the root into a small number of directories under the root
• Create rules in the CDN for those directories, plus any files that do need to stay at the root (robots.txt, favicon, etc)
• Direct everything else to Next.js

Configuring this will happen at the end though - for now we just need to get the static assets uploaded to the S3 bucket.

The way I chose to do this was to copy .next/static/ and public/ to /content/[commit-hash]/_next/static and /content/[commit-hash]/public inside the bucket respectively. I chose this scheme because:

• Using a common prefix (/content/) allows me to have a single, unchanging CDN rule for static assets
• Using the commit hash in the path allows for different releases to be available simultaneously, in case users are using cached HTML content from a previous version. These releases can also be easily identified in the bucket (meaning the bucket can be tidied easily). The commit hash is easy to access in deploy jobs, and makes it easy to trace a set of assets back to a specific code state. It also would help with cache busting, except that Next.js does that already.
• Putting all assets for a particular version inside a single prefix also makes the bucket easy to manage and tidy.

Obviously, though, there are many ways to organise this, each with their own pros and cons. The rest of this post assumes this scheme, but tweaking the instructions for your own scheme should be straightforward.

Actually uploading the assets is pretty straightforward - just build your frontend, and upload your data to the bucket. If you’re using continuous deployment, the AWS CLI makes this easy.

The bucket really doesn’t need any special configuration at all - all the defaults are configured appropriately, and it doesn’t need to be public once we have a CDN. You can make it public temporarily for testing though.

Step 2: Hosting Next.js on Lambda

Build and configuration

Hosting web applications on Lambda has one small caveat: when a Lambda function is invoked, it doesn’t just get passed a HTTP request. The original HTTP request is actually encapsulated inside an AWS event, which gives us the ability to get a bit more data about, eg, the service that invoked the Lambda function. The problem here is that Next.js runs as a server, responding to HTTP requests on a given port, and therefore has no idea how to handle an AWS event.

Thankfully, AWS provides a handy tool called Lambda Web Adapter. When a user sends a request to your Next.js server, LWA does the following:

• Launch your server if it’s running in a fresh Lambda function
• Poke your server until it responds to requests on the appropriate port
• Once it gets a response from the server, turn the event back into an HTTP request and pass it into your server
• Return the server’s response back to the service that invoked the function

Lambda Web Adapter takes the form of a ‘layer’ that is applied on top of your function code. We therefore just need to apply the layer and configure it using environment variables, and it will work nicely.

This is obviously the most AWS-specific part of this process, but it is a common use case so I would imagine that most hosting providers will offer similar functionality.

In terms of an entrypoint, Next.js outputs a server.js file that you can invoke with node server.js in order to execute the production server. The creators of Lambda Web Adapter provide a shell script that you can use to actually launch the server.

This script will need to be copied into the .next/standalone/ directory before you compress and upload it to your function.

Infrastructure

For Next.js, all we need is a fairly standard Lambda function. The main thing it does need is a function URL (that is, a long public URL that you can use to invoke it). This is just a tickbox on the function’s configuration, and no authorisation is needed.

Here is a recommended list of resources that your function will need:

• A CloudWatch log group with the name /aws/lambda/[function-name] (your function will write to this log group automatically)
• An IAM role with the following:
  • The AWS Lambda trust policy (allows the Lambda service to provide your function runtime with credentials)
  • The Lambda basic execution role (allows your function to write logs to CloudWatch)
• The Lambda function itself, with the following configuration:
  • ZIP package upload; just ZIP up your .next/standalone/ directory
  • Handler: Your launch script
  • Timeout and memory size of your choice (maybe start at 1024 MB memory and reduce until you start having issues)
  • Node.js runtime (I used nodejs18.x but use what makes sense to you)
  • Architecture: I used x86_64 but I don’t see a reason why arm64 wouldn’t also work
  • Layers: use Lambda Web Adapter - the ARN info can be found in the AWS docs
  • Role: your execution role
  • Function URL: enabled; no authorisation
  • Environment variables:
    • AWS_LAMBDA_EXEC_WRAPPER: "/opt/bootstrap"
      • required by LWA
    • PORT: [some integer]
      • tells Next.js which port to host your application on - avoid ports 9001 and 3000 as these are used by AWS services
    • AWS_LWA_PORT: [some integer]
      • tells LWA what port to look for your server on; should be the same as your PORT
    • RUST_LOG: "info"
      • tells LWA what log level to use; change this if you need to troubleshoot. Possible values here.

You can find more info on AWS LWA configuration here. You may wish to enable gzip compression on your responses by setting AWS_LWA_ENABLE_COMPRESSION to true.

With your function configured, you should find that you can reach your function by copying its URL into your browser. If you’ve made your static assets bucket public and given the server a correct assetPrefix then you should even be able to see your frontend fully-formed at this stage. Make sure that you upload the same standalone server build as the one that you took the static assets from - Next.js generates different file names on every build for cache busting purposes, so non-matching assets and server code will result in missing assets.

Step 3: Caching & Routing

The final step is to use CloudFront to sit between your users and your deployed frontend. The main thing we’ll use CloudFront for is to route different requests to different places (Next.js vs the static assets bucket), but it’s possible to do loads of clever stuff with its caching and firewall options too.

When configuring a CloudFront distribution, there are two concepts that should be understood:

• An origin is a thing that CloudFront can point requests to. For our purposes, the two origin resources will be Next.js and the static assets host.
• A cache behaviour describes a rule that CloudFront should follow when serving a certain set of routes under your URL. It allows you to map a set of routes to an origin, and specify how that origin’s responses should be cached.

Before we make the CloudFront distribution itself, there are a few final things to configure:

• An Origin Access Control (OAC) for the static assets bucket. This configures how we allow CloudFront to talk to the bucket. For more information, see here.
• An IAM policy which allows the CloudFront service to access the static assets bucket. See the OAC docs for details on what the policy should look like. Remember to attach the policy to the bucket.
• An Origin Request Policy (ORP), with a query string behaviour of all. This policy, when applied, will tell CloudFront to forward URL query strings. We need this in order to receive query strings in our Next.js server.

So, we need a CloudFront distribution with the following configuration. I assume your domain name is in AWS Route 53, but this is not a requirement - some Googling should yield you some advice on how to configure it if you’re not using R53.

• Alias: Your frontend domain
• Price class: Choose the most appropriate one for your use case (list here)
• Certificate: Use an appropriate certificate here. It’s possible to register a free public certificate with AWS Certificate Manager (ACM) - docs here
• Origins:
  1. One origin pointed at the Next.js server’s function URL.
  2. One origin pointed at the static assets bucket, using the OAC mentioned above.
  3. One origin pointed at the /content/[commit-hash]/public prefix in the static assets bucket, also using the OAC mentioned above.
     • This is needed in order to map the public directory to the root of our frontend domain. It needs to be updated with each release.
• Cache behaviours (in ascending order of precedence):
  • As many behaviours as you need: point some file or directory at origin 3 (the current public directory). Caching enabled.
  • One behaviour: point /content/* at origin 2 (the root of the static assets bucket). Caching enabled.
  • Default behaviour: point to origin 1. No caching (we want the website to update straight away when we update our Next.js function). Apply the ORP mentioned above.

You’ll also need to configure the DNS for your domain to point to the correct CloudFront addresses. If you have your domain name in AWS Route 53, this is easy. Otherwise, you can create an alias record, pointed at the correct CloudFront URL.

Finally, make sure you’ve set the asset prefix on your Next.js function to use the correct path. This is briefly explained at the start of the static assets section above - but, in short, the value you provide should look like https://myfrontend.com/content/[commit-hash].

Once all this is configured and deployed, your frontend should be working! The last thing you might want to do is set up a serverless function or cronjob that clears out old releases from your static assets bucket every so often. I won’t go into detail on that here though, as this guide is focussed on getting the basic infrastructure in place.

I’m going to start by explaining how sound signals actually work, before explaining the signal flow through a typical DJ setup, and finally briefly covering acoustics.

Audio signals

What an audio signal actually is

For the purpose of this post, I’m going to portray sound signals using waves. You’re probably familiar with waves already from your library preparation software or any production experience you already have, but I’ll go a bit deeper on what the wave actually means now.

These plots are simple - on the x-axis is time, and on the y-axis is air pressure. So, essentially, you can think of a sound wave as just a plot of a speaker diaphragm’s position over time. If the line at a particular point is high, the speaker diaphragm will be ‘pushed out’ at that time when playing back the sound. If the line at a particular point is low, the speaker diaphragm will be ‘pulled in’. The inverse is true for the diaphragm of a microphone when you record something - the microphone diaphragm converts movement to voltage.

Speaker diaphragms are moved by strong electromagnets at their centres, which convert voltage into movement. So, when we transmit audio through a speaker, the electromagnet is converting a high voltage to a pushing out force on the speaker diaphragm, and a low voltage to a pulling in force on the speaker diaphragm.

So, a typical sound wave might look like this:

There are five things that define a signal: its channel count, its level, whether it’s analogue or digital, the connector it uses, and whether or not it’s balanced. Balanced audio is important in live music, but less important for DJs, so I’ll talk about the first four now and skip balanced audio until the end of the article.

Audio channels

An audio channel is really just a single fluctuating voltage. In DJing, all signals have either one channel or two channels. A signal with one channel is ‘mono’, and a signal with two is ‘stereo’.

Stereo music is just music with a left and a right channel, designed to match the left and right ears on a typical person. The two separate channels can play completely separate sounds in theory, but they generally play similar things with minor variations intended to give the track some ‘width’.

For example, the volume of a particular component of a track can be varied between the left and right channels to choose where it sounds like it’s coming from - if it’s stronger in the left channel than the right channel, then it sounds like it’s physically slightly left of centre.

Converting from mono to stereo is pretty straightforward - if we have a mono track to be split into stereo, we simply play the same mono signal on both channels (resulting in no particular width).

Converting from stereo to mono involves a process called ‘summing’ - the two signals are simply added together. For example, these two signals:

sum to make:

Almost all modern tracks are produced in stereo, so if you have a stereo speaker system it’s generally preferable to ensure that the signal chain is stereo all the way.

Signal levels

One thing to be aware of is the concept of a signal ‘level’. A signal’s level is essentially just its strength. Common signal levels include:

• Line level
  • This is a standardised signal level, designed for sending audio signals between mains-powered devices.
  • It’s a medium-strength signal.
  • ‘Consumer’ and ‘pro’ equipment have slightly different standards for line-level audio, but these standards are generally compatible if you don’t push your volume too high.
• Mic level
  • This is the level that a mic might produce.
  • It’s generally very weak.
  • It is not standardised, and varies depending on microphone design.
• Phono level
  • This is the level that a turntable (aka ‘phonograph’) cartridge produces.
  • It’s also very weak, and varies depending on the particular cartridge model.
  • Phono signals are quite interesting so will be elaborated on later.
• Speaker level
  • This is the voltage that is fed into a speaker’s diaphragm.
  • It needs to have a high enough voltage to physically move a speaker cone through the air.
  • It’s therefore much stronger than line level.

In general, signals start off weak at the source and get stronger as they progress through a signal chain from sound source to speaker.

In case you hadn’t guessed, signal strengths are increased by amplifiers. Microphone and phono signals are generally increased to line level by dedicated amps called called ‘pre-amplifiers’ or pre-amps. Pre-amps are placed as early as possible in the signal chain - so any mic/phono input on a mixer will naturally have a pre-amp built in behind the connectors. Line level inputs don’t need pre-amps though, for obvious reasons.

Analogue vs digital

So, we’re familiar with analogue signals. Next up, digital signals. I won’t go into too much details, but essentially a digital signal turns a sound system into a series of numbers rather than as a wiggly line on, say, a vinyl record.

It checks what the signal’s voltage is (or ‘samples’ it) several tens of thousands of times a second, and uses those numbers to describe the signal. A device playing back a digital signal simply joins the dots back up. You might think that the ‘steppyness’ of a digital signal would affect the sound, but a low-pass filter and some clever maths called the Nyquist–Shannon theorem actually means that a digital signal is capable of perfectly describing any analogue signal, provided that there is an upper limit on the frequencies we try to recreate. Humans are physically unable to hear frequencies above 20kHz, so this limitation is fine. Devices that convert between digital and analogue are called digital to analogue converters, or DACs - I’ll leave it to you to guess what an ADC does.

In general, digital audio is better than analogue audio - it is immune to interference and capable of carrying multiple channels down a single cable.

There is a separate analogue/digital discussion, unrelated to the audio signals that connect your devices together - that of analogue and digital DJ mixers. Analogue mixers such as Allen & Heath’s Xone line are fully analogue, meaning that your audio signals travel through the whole mixer without any digital signal processing (DSP). However, the effects units in modern mixers are built on DSP - so these mixers do not include effects past EQ and filters (which can be easily recreated with analogue circuitry).

Audio connectors

You’ve probably noticed that there are several different ways of sending audio between devices. I’m going to quickly cover the common audio connectors now.

I’m going to mention balanced audio in this section, so if you’re not sure what that is, balanced signals are less prone to interference. I’ll expand on balanced audio a bit more later on.

Analogue RCA

Most commonly used to connect DJ players to mixers, the RCA cable carries the left and right channels at line-level along two separate cables. White is left and red is right, and the signals carried by RCA are unbalanced.

RCA is easy to accidentally unplug, and sometimes has connection issues - particularly if you’re using cheap plugs. Cheap RCA connectors with ‘flower’-shaped ends (see the four ‘petals’ around the central pin in the image above) are bad, as they can be bent out of shape easily, resulting in a loose connection. Connectors with outer rings that fully surround the centre pin are a better pick if you have the choice.

S/PDIF (Digital RCA)

The digital connectors on CDJs and/or mixers use a protocol called S/PDIF to transmit digital audio through RCA cables. If your mixer and CDJs both support it, it’s generally preferable as it minimises the number of conversions between analogue and digital that take place between your USB stick and the master output.

In all physical aspects, digital RCA is identical to analogue RCA, so the cables are fully interchangeable.

XLR

XLR cables are the industry standard way of moving audio around, for good reason. XLR commonly carries both mic and line-level audio, and is balanced thanks to the presence of a third pin (more on that later). It also has locking connectors, meaning you can’t yank it out without pushing a button on the input side - though the mic inputs on the back of DJ mixers often don’t feature a lock.

It also has different connectors on each end, which means multiple XLRs can be daisy-chained to produce a single longer cable. The upper ‘female’ connector with the button plugs into outputs, and the lower ‘male’ connector plugs into inputs.

XLR cables are expensive, but good quality cables are worth it for their reliability. Bad quality connectors typically feel light or hollow in the hand, whereas good quality connectors feel more solid and are made with tougher materials. The above connectors are the good kind - the XLR standard was designed by Neutrik and their plugs are still generally thought to be the best.

6.35mm (1/4”)

Otherwise known as ‘big jacks’, or just ‘jacks’, quarter-inch cables come in two varieties - TRS on the left, and TS on the right. The difference between the two is simply that TRS has one more pin - this is usually used either to send stereo signals, or to send balanced audio like with XLR’s third pin.

TRS connectors are generally preferable wherever possible, as balanced audio is less susceptible to interference. However, TS is also commonly used, particularly for guitars, guitar pedals and production gear. If a 1/4” connection doesn’t clearly state that it’s balanced, it’s more likely to be unbalanced (but if in doubt the product manual will usually make clear which it is).

In DJ situations, TRS cables are most commonly used for connecting the mixer to the booth monitor speaker, but they can also be used for connecting mics or as master outputs on some mixers. Both of these scenarios usually use balanced audio, so TRS cables are definitely preferable.

The only exception is the send/return loops on mixers, which are typically unbalanced. If you’re fancy enough to be using the send-return loop, you probably don’t need TRS, but it may be worth checking the manual for your effect unit and/or mixer.

Plugging TRS into a TS socket (or vice versa) won’t break anything, particularly if the TRS is being used for balanced - it’s pretty idiot proof. However, if you do happen to be using TRS for stereo instead of balanced audio, you may lose the right channel - in most electronic music this isn’t the end of the world, but it’s probably preferable to sum left and right to mono if you can. Bear in mind that most DJ mixers offer the option to output in mono - either through a switch on the front, or in a configuration menu.

In terms of quality, similar rules apply to XLR.

Speaker-level 6.35mm

Note that TS 1/4” cables are commonly also used for connections from amplifier to speaker, particularly on very cheap passive systems. You should not use regular, line-level TS cables for this, as a speaker level signal requires the cable to transmit more power than a typical line-level cable is designed for.

If in doubt, look at the writing on the cable - if it says ‘microphone cable’ or ‘instrument cable’ then it’s not appropriate for high-power signals. If it mentions ‘speaker cable’ then it should be fine. A speaker cable will be noticeably thicker and heavier than a line-level cable.

speakON

Much like XLR, speakON is a type of cable designed by Neutrik specifically for live scenarios. It’s built to carry speaker-level signals, but is much better suited to the job than jack cables. It has locking connectors, meaning it can’t be yanked out accidentally, can carry more power and is generally more reliable.

Plugging in or unplugging a speakON cable for the first time can be a confusing experience, so bear in mind that you have to line up the (differently-sized) protrusions on the connectors, insert it, then twist it. The lock should have clicked into place. To unplug, just find and pull back the lock on the male connector and reverse the steps.

Advanced sound tech

Phono signals and RIAA equalisation

Vinyl records come with a few specific challenges for mastering engineers and listeners. There are two that are particularly interesting here: firstly, the needle can easily skip, particularly when playing back loud bass frequencies. Secondly, louder low ends require more physical space on the disc. Finally, records famously have a certain level of hiss and crackle when playing back, which tend to occupy the higher frequencies.

A technique called RIAA equalisation neatly solves both of these problems. Essentially, before it is cut into the record surface, a track is equalised in much the same way you’re used to on DJ mixers. The high frequencies are boosted, and the low frequencies are cut. Then, when the record is played back, the highs are cut and the lows are boosted to compensate. This is done with a standardised EQ curve defined by the Recording Industry Association of America in the 1950s.

The benefits here are two-fold: by reducing the level of the bass on the record, we reduce the space needed and the likelihood of skipping. Separately, boosting the high-end means that the high frequencies in the actual recorded music have an advantage against the high frequencies created by hissing and crackling as the needle travels through the groove.

The important thing to note here is that a signal coming from a turntable needs equalising before it will sound correct. This is a built-in feature of pretty much all phono preamps, so you shouldn’t need to worry about it, but certainly always make sure you’re connecting turntables to inputs that expect phono signals - failure to do this will result in a thin-sounding signal.

Balanced audio

In order to transmit an electrical signal, we need two metal connections. One way of understanding this fact is that, given we’re building an electrical circuit, the signal needs to flow ‘through’ the device on the receiving end. If there was only one connection, the electrons wouldn’t have anywhere to go. This is true, obviously, but an analogy that makes life a bit simpler when talking about audio signals is to think of each connection as transmitting a certain voltage level.

Under this simplification, the reason we need two ‘poles’ to transmit a signal is because, as well as the actual voltage of the signal, we also need a ‘reference’ level so we have something to compare to, also known as the ‘neutral’. The property that decides how far the speaker moves is the difference between the two voltages. We can call the reference level 0V, and the actual signal might oscillate between +3V and -3V, for example.

Here’s the above signal again, with the neutral voltage added in in green:

So, let’s imagine that we’re sending audio down a cable in the way described above. All is going well, until something near the cable causes some interference (represented in orange):

Interference is a common problem, particularly with weak signals such as those from mics. It can be caused by a whole range of devices and effects, and one cable could even induce voltage into another if run close to it for some distance. This interference will be audible in the reproduced sound, and probably won’t be very enjoyable for an audience to experience.

We have no way of stopping this under the current setup. But balanced audio gives us a solution. We add a second signal, and we flip it. Now, if we get interference, it affects both signals equally:

This may not seem that useful, but the clever bit is what happens at the receiving end of the signal.

The device receiving the signal flips the second signal back over again, giving us two signals:

It then adds the two signals together…

cancelling the interference out entirely:

So, essentially, balanced audio adds a second signal (and therefore a third pole to the cable) and makes the signal travelling through that cable much more resilient to interference.

Building your own cables

One of the huge benefits of pro audio cables is that they can be disassembled and re-soldered with relative ease. If you’re skilled at soldering, or interested in giving it a go, it’s usually cheaper to buy cable and connectors separately and construct your cables yourself. It also gives you the skills to repair almost all audio cable faults yourself, and is very rewarding.

Most cables designed for pro audio (XLR, TRS, SpeakON, etc) can be disassembled in this way - usually by unscrewing the metal or plastic ‘boot’ at the rear of the connector.

Chances are that your group are performing in a lovely big echoey room. The recording is inevitably going to capture some of that sound, which is good. But as nice as the reverb is, it’s also important to make sure that you get a good clear recording with a good amount of sound coming directly from the instruments themselves. In order to achieve this, the sweet spot is generally to place the microphones at the front of the group, probably just behind the conductor, and reasonably high up (at least 2m!). It’s a good idea to err on the side of being closer, because it’s easy to add more reverb and (pretty much) impossible to take it away.

One of the other main considerations is stereo width. Put simply, we have two ears, and some techniques are going to give you ‘wider’ signals (that is, signals with more differences between the two ears) than others. In a vacuum, more stereo width is a good thing because it sounds nice, but it shouldn’t come at the cost of things sounding natural.

For these orchestral recordings, you generally want a faithful reproduction of the sound with minimal colouration and high fidelity even in quiet sections. You’re also probably not using the microphones for amplification, so feedback won’t be an issue. For this reason, you’re almost certainly going to use condenser microphones. These microphones are perfect for the job, but it’s worth you knowing that condensers need ‘phantom power’. This is when the microphone cable not only carries the audio from the mic back to the recorder but also carries 48V in the opposite direction to polarise the microphone’s diaphragm.

I’m also going to need to briefly discuss ‘phase’ and the problems it can cause. Basically, imagine a nice sine wave coming from your sound source:

Waveforms.svg: Omegatron; Derivative work: MrLejinad, CC BY-SA 3.0 https://creativecommons.org/licenses/by-sa/3.0, via Wikimedia Commons

Now let’s say you’ve got two microphones receiving that sine wave. All good. But what if they’re slightly different distances from the sound source? Then each mic would be receiving the wave in a different ‘phase’: that is, that one microphone is picking up a ‘peak’ as the other is at the bottom of a ‘valley’.

This isn’t a major problem in and of itself, but it becomes more of an issue if your microphones get added together later on. In a basic situation, this is most likely to happen if you have a left mic and a right mic - in this case it will play back fine, except if someone listens to your recording in mono (that is, on a device with only one speaker). This might happen on a phone speaker, for example.

When two sounds get ‘summed’ together, what we’re essentially doing is averaging the y-axis of those two waves at each point. When our signals are out of phase, that means that a peak will average with an exactly opposite valley, giving us… zero. That means that the wave will cancel itself out, meaning anything at that frequency will magically vanish when summed to mono. In practice, this will happen at a number of frequencies, creating a ‘harsh’ and ‘unnatural’ sound. See this video for an example.

Finally, there are two main kinds of ‘pickup pattern’ to discuss. A microphone’s pickup pattern defines what directions it is sensitive to incoming sound from. A ‘cardioid’ microphone is most sensitive to things in front of it and tends to ‘reject’ sound from behind it, whereas an ‘omnidirectional’ microphone picks up sound (pretty much) equally from all directions.

Step 0: Choose your microphone setup

Next up, you need to think about what physical setup you’re going to use. Since this guide is primarily written for people that are borrowing equipment from Music Durham, I’m going to focus on the equipment that we have. That doesn’t mean it’s not applicable to other equipment too though!

There are a few main options in terms of how you set up the microphones. In general, you want your main microphones to all be in one place to reduce phase issues and to make the recording sound more natural (since someone sitting in the room would be sitting in one place too - they wouldn’t have ears spread around the room). You’ll get the “best” sound just behind (and/or above) the conductor, so that’s where you want to put your main microphones! As a general rule, 3-4m off the ground is a pretty good sweet spot as it means sound won’t be blocked by things like musicians or the conductor but is still reasonably close to the performers.

For a bigger orchestra (or more professional recording), you may also want to place ‘outrigger microphones’ either side of centre to capture sound from the wider fringes of the orchestra, but I’m not going to discuss this here.

XY Stereo

By Iainf 23:51, 21 September 2007 (UTC) - self-made; based on Image:XY-Stereo.png and Image:Cardioidpattern.svg, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=2792301

This is one of the most foolproof options. Basically, XY stereo places two microphones on top of each other, pointing approximately 90 degrees apart, either side of the centre line. The mics need to be cardioid, or you’d just be listening to the same point in space twice! At Music Durham, we have a pair of Rode M5 microphones that are perfect for XY stereo.

Pros:

• Very difficult to set up wrong
• No phase issues
• Only needs one mic stand
• Only needs two mics (and two channels on your recorder)
• Angle can be adjusted to suit the width of the ensemble

Cons:

• Not much stereo width (you’re only reliant on the difference in the microphones’ pickup patterns)
• May miss the centre of the group if the mics are angled too wide

AB Stereo

While useful for recording individual performers or instruments, AB stereo tends not to be that popular for larger recordings due to its potential for phase issues and prominent perceived ‘gap’ in the centre. The idea is essentially to place two microphones either side of the centre line, so that they each pick up one half of the group.

The problem with AB stereo for larger recordings is that you want your mics to be far apart to avoid phase problems. However, by placing them far apart you’ll also lose the centre of the group. This tradeoff is something that will always need to be overcome with AB stereo, hence its lack of use in orchestral recording. When recording a single instrument, it’s much easier to be closer to the sound source, meaning the mics can pick up the centre easily without causing as much phase cancellation.

Pros:

• Simple to set up
• Can use cardioid or omnidirectional mics (research this first though as they will sound very different!)
• Stereo concept makes logical sense
• Very wide sound

Cons:

• You’re always going to have to compromise between limiting phase cancellation and not missing out on the centre

Decca Tree

Named after Decca Records, the British record label who invented it, the Decca Tree is not only a hugely popular choice in capturing orchestral groups but also can be used in a range of other applications, particularly choral recordings. It’s based on an AB stereo technique, but with the addition of a centre mic to fill the hole in the centre, and positioned more centrally rather than being spaced across the front.

This technique uses three omnidirectional mics, positioned in a roughly equilateral triangle with about 2m side length, at the front of the group.

Step 0: Making sure you have everything you need

Here’s a quick checklist of what you will want to bring:

• Microphones
• Microphone stands
• Recording setup (probably just a portable recorder)
• Means of getting mains power to your recorder (probably a USB charger)
• Battery power for your recorder (just in case)
• XLR cables
• Wired headphones to monitor the signal
• (Maybe) a laptop to retrieve the recordings
• Cable covers and/or tape to avoid trip hazards

Step 1: Positioning everything

Once all the equipment is in the venue, the first order of business is to figure out where you’re going to put your recorder. You want it to be somewhere safe, preferably with power so you don’t have to rely on batteries, and in a spot that minimises trip hazards as well as being reasonably close to the microphones.

Once the recorder is placed, you need to place your microphones. When placing microphones, remember that you are essentially deciding where a listener’s ‘ears’ are going to end up when they hear the recording. As such, where you place them will greatly affect what the recording sounds like. Typically the best spot is just at the front of the ensemble (just behind the conductor, if applicable, is usually a good rule of thumb), and at least 2 metres in the air.

Case 1: XY Stereo

By Iainf 23:51, 21 September 2007 (UTC) - self-made; based on Image:XY-Stereo.png and Image:Cardioidpattern.svg, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=2792301

In the case of XY stereo, your two microphones should be placed on a short bar, such that they point inwards and cross over maybe 5-10mm from their ends (one above the other). They should be roughly at right angles, but this can be tweaked depending on how wide your ensemble is and/or how far away it is.

Case 2: Decca Tree

By Iainf 00:30, 23 September 2007 (UTC) - public domain, https://commons.wikimedia.org/wiki/File:Decca_Tree.svg

The centre microphone should be placed somewhere around the conductor (probably just behind), and the side microphones should be placed either side of it, a fair distance behind it. There isn’t any particular rule for this, but microphone manufacturer Schoeps recommend putting mics at least 1.5m apart to reduce phase issues, so around 2m spacing is probably a safe bet. You may want to adjust the dimensions a little based on your situation though - if the group is reasonably small or narrow then maybe shrink the triangle a little, and if it’s quite wide then you could move the left and right mics further out.

Step 2: Plugging it all in

Once you’ve decided where your mics are going you’re ready to put them on the stands, plug them in and raise them to 3-4m (in that order)! If they’re omnidirectional you probably want to point them either up or forwards (to not look silly), whereas with cardioid mics you need to be more careful to get them oriented correctly. If you’re using Music Durham’s tall mic stands (which are K&M 20800s), just raise them to the top of the stand’s range - this should put your mics around 3.1m in the air.

When choosing cables, remember that you’re going to need at least 3m just to get from the mic to the floor, so you’ll probably want more than 5m unless your recorder is basically at the foot of the mic stand.

Run the cables to the recorder, using cable covers or tape to stop them becoming trip hazards where necessary, and plug them in. I usually plug them into channels 1-3 in the order L, C, R but you could also do L, R, C if you want! Just remember which one you go for.

Step 3: Setting up the recorder

If you’re using a Music Durham recorder, visit its page on the Music Durham Tech Team catalogue to download its manual and/or quick start guide. The process varies between recorders but here’s a quick checklist of things to do:

• Make sure there’s an SD card with plenty of space inside the recorder
  • It will typically tell you how much recording time you have left before you run out of space on the recording screen
• Make sure the recorder is receiving power so you’re not relying on batteries
  • You might need to tell it to use the USB input for power when you turn it on - this might appear as a ‘bus power’ option
• Set the recording settings - 48kHz WAV at 24-bit is generally a good bet!
• Make sure phantom power is on; without this you won’t get any signal from your mics!
  • Phantom power is often switched on with a physical button or switch so if you’re struggling to find it have a look around the recorder’s body
• Turn off any pad switches
• Set the gain, with the following process:
  • Ask the group to sing/play at maximum volume for around a minute
  • For each channel, adjust the volume until it’s just maxing out at -10 dB
• Plug in a pair of wired headphones if possible and monitor the signal to make sure there aren’t any issues

Step 4: Record

Start your recording! If recording a concert, your best bet is probably to set it off just before the concert starts. I’d suggest pausing the recording for any intervals etc as there’s no point recording those, but don’t do that if you’re worried you’ll forget to resume it again!

Step 5: Edit

Once you’re done recording, grab your recordings off the SD card by either plugging it directly into a computer or connecting the recorder over USB with the SD card installed.

If you’re okay mixing your recordings yourself, import your recordings into a digital audio workstation; as a minimum I’d suggest you do the following:

• Set a low-cut (aka high-pass) filter at a minimum of 50 Hz to eliminate unnecessary sub-bass frequencies
• Pan your left and right signals all the way to their respective sides
• Set the gain of all your signals so they peak at around -6 dB at the loudest point of the recording
• If you used a Decca Tree, choose an appropriate mix between the centre mic and side mics
  • Make sure you’re using stereo speakers or headphones so you can appreciate the width properly
  • The centre mic is intended to ‘fill in the gap’ between the side mics, so if in doubt start with only those and bring up the centre mic until things sound balanced
• Set the master gain so your recording peaks just below zero at the loudest point

You may also want to use a small amount of mastering compression and EQ, but only do this if you know what you’re doing, and keep it minimal to preserve the natural sound of your recordings.

I should note that I am writing this from the perspective of a sound technician that has worked on a wide range of events at Durham University, so a lot of the specifics will be geared towards that niche, but the general process outlined here is applicable to more or less any event. Essentially, your job as an event organiser is to act as a central party who communicates with all the involved stakeholders, collects all the information needed to run the event in one place and ensures everyone knows what’s going on.

Step 1: Establish what you have at the venue

Probably the first step of planning an event is to decide on a venue. This could be anything from a small local bar to a literal castle, but what they all have in common is that they will provide you with a certain base level of equipment for your event, as well as obviously the space(s) that it will take place in. In all likelihood, they will invite you to the location to have a look around, and this is the ideal time to discuss the first thing you need to know: what exactly they have. Bring a clipboard!

First off, make sure to start a conversation about what exactly comes with your booking - it may be that they will only provide power, or it may be that they have loads of lighting, a stage and a speaker system. Knowing this in advance will make life easier for technicians (as they won’t need to bring or set up equipment if it’s already in the room) and cheaper for you (as you won’t need to hire equipment that doesn’t get used because it’s already in the room). It will also ensure that there aren’t any gaps - everyone will be clear on who is providing what. While the representative from the venue will probably talk through it in person, and noting down these things is good, it might be worth asking for the list to be forwarded over email too, so you have this important information straight from the horse’s mouth.

As well as a list of the tech that comes with your booking, it’s also useful to draw up a quick map of the area’s expected layout. This might seem unnecessary, but remember that the people setting up the event probably haven’t visited the venue and therefore won’t have the insight that you do. As well as things like the room shape, stage area and table locations, it’s very important to show the locations of all power outlets and any other equipment that the venue is providing. It’s best to do this either whilst at the venue or straight after your visit to ensure that it’s fresh in your mind. I told you the clipboard would come in handy.

Step 2: Establish what your performers need

Next up, you’re probably going to get in touch with some people to provide entertainment at your event. Once you have people confirmed, get a rider from (or at least confirm technical requirements with) every single one. That includes dancers, speakers, photographers, karaoke machine providers and unicyclists. You may find that many of them want little things like background music, a green room or a power socket. Having all of this noted down ensures that there won’t be any surprises on the day when your extreme juggler suddenly remembers he needs 24 speakers, a DJ, a light show and an inflatable water slide for his death-defying performance in the middle of a field, 6 miles from the nearest electrical outlet.

You will also want to chat with the performers about when they want to come to the venue. It’s likely that they will want to come and figure out layout, execute soundchecks, and rehearse, and getting their timings down early will make planning the day’s logistics that much easier.

Obviously, riders are particularly important from musical performers, dancers and other stage-based acts, so make sure they get them sent over ASAP. Otherwise, you’ll have to chase them for riders when your technician asks for them in a few days’ time and you’ll lose a day or two of planning time while they get back to you. If you need something to point to, I have a handy blog post on that very subject.

Step 3: Establish what you want

Now comes the fun bit. You have all the information at your fingertips, so have a think about what kind of production value you want your event to have. If you’re technically inclned, have a look at various tech hires (if you’re Durham-based, the best place to start is durhamtech.org.uk), see what’s on offer and compare against your budget. If you’re not technically inclined, though, don’t worry! It’s still useful to think about how much you’re willing to spend - as a guide (at Durham college hire prices), a ‘basic’ setup (with minimal lighting, 1-2 main speakers, a mixer etc) will cost around £70 + VAT, a more advanced setup (with stage monitors, slightly more lighting and a digital mixer) will cost £150 + VAT and a really fancy setup (with posh lighting, nice light and sound desks and maybe some staging) will cost £200+.

These numbers will also vary depending on how much your performers are bringing - a band that brings their own amplifiers and drumkit will obviously need less hire spend than one that doesn’t. Remember also that you’ll probably want at least one technician, and these should charge £15-30 per hour. Finally, while it may seem like needless spending to hire out nicer equipment that will only service your technicians and band (things like nicer mixers or more stage monitors) these things will allow those people to perform better: as an example, pricier digital mixers feature really handy features like compressors and wireless control that will allow a technician to really fine-tune the sound versus a more basic analogue mixer.

You might want to establish contact with some technicians at this point, to make them aware of the fact that you’re interested in hiring equipment for your event, but you will probably want to wait before you send all of the information over, since there are a few more things to tie together.

Step 3.5: Transport & logistics

By this point, you’ve probably also established what transport you’re using. As well as transport for your bands, guests etc, you may need to move technicians and equipment to and from your event too. As a very rough guideline (again, at Durham college hire prices), a small car will carry around £70-100 worth of equipment. If you have coaches, obviously those will be capable of carrying much more.

The other thing to consider at this step is things like rehearsals, setup and soundchecks. Put simply, the longer you can leave between the start of setup and the start of the event, the more time there is to iron out any bumps in the road that crop up. If you’ve done all the above then those bumps are far, far less likely to appear, but there’s nothing wrong with planning for contingency, and allowing more time will allow everyone to get things exactly how they should be for your event.

Once you’ve got all of this planned out, write up a rough initial schedule for the day. Include everything from vehicles going back and forth to soundchecks and setup time. It’s nice to have things planned out in your head, but getting it down on paper will mean you have a nice table you can send to everyone involved and thereby reduce logistical miscommunication.

I’ve put this step as a half-step because it’s something that you’ve probably been working on at the same time as the above things - between step 3 and 4 is sort of the ‘deadline’ to have these details planned out (though it shouldn’t be 100% finalised until after step 4, just in case there are any complications).

Step 4: Fill in the gaps

Notice that actually hiring technicians and equipment is the last step. That’s because by this point you should have all the information that a technician will need in order to plan and execute your event. That means all you really need to do is send everything over in one go. If you’ve been thorough, it may well be that the person on the other end goes “Okay cool. You need this, this, this and this and that will probably cost you somewhere in the region of £120” with no further back-and-forth needed. This is the ideal outcome, but it’s also very possible they have one or two minor things to clarify with you first.

Step 5: Relax!

Congratulations! By this point everyone involved in your event knows exactly what’s going on. You’ll probably want to circulate final arrangements with everyone involved in order to ensure that everyone knows the situation, but otherwise your event is all planned out! Have a cup of tea and reflect on how awesome you are.

As a bit of an epilogue, I’m just going to quickly draw attention to what the alternative to this process is. As tempting as it may seem to get in touch with the people providing you with technicians and equipment first so they can help you through the process, sending emails back and forth with every new thing is a waste of your and their time. You would essentially be acting as a go-between, and they would have to go through the above and talk to performers/venue through you. That’s not your job or their job, and giving them the contact details for the other parties so they can liase directly cuts you out of the loop entirely, meaning there’s potential for things like spending decisions to be made without your consent. I should note that emailing technicians early to confirm that you would like to use their services is a perfectly reasonable thing to do, but you should make it crystal clear that you are collecting information in the background and will get back to them once you have it all in one place.

I’ve included a range of different things here; if you’re a small band performing in a small gig then you probably won’t need much more than the first table below when constructing your rider.

One last thing before I get started - please don’t forget to be nice! It’s possible to be professional and precise without sacrificing personality and friendliness :)

Equipment list

The first thing you’ll need is to make it clear who’s in your band, what they play, what they have and what they need. A good way of laying this out is in a table, like this:

Performer	Instrument	Provided equipment	Required equipment
DJ Khaled (he/him)	Bass kazoo	Bass kazoo, high stool	Instrument mic (Shure SM57 or similar)
Rick Astley (he/him)	Electric guitar	Electric guitar, refusal to give you up	Guitar amplifier (min. 50W)*, amp mic / DI
Squidward (they/them)	Casio RAP-1 Rapman	The world’s 1st rap keyboard	1x mains power socket, 3.5mm mono output
Queen Elizabeth II (she/her)	Vocals, didgeridoo	Telefunken M80 Gold microphone, gold-plated mic stand	Instrument mic for didgeridoo, crown storage*

(*: can be provided if necessary)

Make sure to include less obvious items on this list, and state their purpose so technicians get an idea of what’s needed and how it all fits together! These items may include:

• Pedals / pedalboards
• Tables & seating
• Music stands
• Mic stands (if you have specific needs in this area)
• Power sockets (and what will need to be plugged into them)

If you have preferences don’t be afraid to state those too, but bear in mind that smaller-scale events and venues will only have limited tech selections.

Bonus points

Bonus points are available for:

• Listing the number of mixer channels used by each person
• Being specific on the setup of more complicated instruments like drum kits
• Including exact models of any electronic equipment you do bring
• Noting anywhere that condenser mics or DIs will be needed (this way the technician knows where to send phantom power)

Also, there’s no such thing as too much detail - even if you’re, eg, running a MIDI keyboard into a synth, or you like to have your laptop nearby to keep an eye on a recording, mentioning that will only stop there being any unpleasant surprises during the event. Plus, many technicians will be interested to see how you’re applying tech to make cool noises come out of their speakers!

Other technical information

This is where you’d add any info about technical requirements that aren’t covered in the main equipment list. For example, you could describe the setup you use for monitoring (eg if you have your own IEM rack), or if there are any non-standard things to be aware of. If you’re really pro, have your own technician/mixer and/or you’re the only band performing at that event, you can even list the mixer channels you use for each instrument to be super clear on what’s needed.

You can also use this section to specify things like whether individual members want their own specific monitor feeds (and whether they want personal control over them), what kinds of effects you might want on the sound, and if you have any preferences for the speaker or mixing setup. If there is a specific sound you’re after, providing sound clips is a good idea!

Finally, it may be handy to provide a set list for more formal events, particularly if you expect your tracks to vary in, eg, instrumentation, or desired sound. It will also help technicians understand the structure and length of your performance.

Stage plan

It’s common, particularly with more professional bands and venues, to send over a rough map of the stage. It’s not essential for smaller gigs, particularly when you’re one of several bands sharing the same stage at a small event, but if your band is particular about how things should be set up it’s a great way of communicating that in advance.

You don’t strictly need to include actual people, because those will (in a normal event at least) not be placed by technicians, but you should include:

• Drum kits, keyboards and other static instruments
• Stage monitors
• Amplifiers
• Any other static equipment you might be bringing yourselves (eg, IEM racks or pedalboards)
• Places that need to be left unblocked for movement on stage (not strictly necessary but possibly useful if your band moves around a lot)
• Places where you need power - bonus points for
  • specifically marking out spots to leave extension leads
  • noting the number of plugs that will be required in each location
  • noting any power-hungry (>100W) devices that might need plugging in (generally these are devices with speakers, but also may include computers, large displays, lights or heating appliances)

You can also depict items you expect technicians to provide, such as DIs or stageboxes, if you like - but it may be easier to leave positions of these items up to them as they probably know the space better than you do.

Other things to mention

Finally, you may want to mention a few final things to make sure you get what you need at the event. Things to consider include:

• Room to prepare for your performance or store equipment during the event
• Soundcheck requirements & expectations
• Special access requirements for equipment or people

And finally, one of the most important things to provide is contact details for someone who will be able to answer any queries relating to your rider or your performance. An email and phone number would ideally be provided, and it’s nice to include your band’s social media links too.

When doing sound tech stuff, I’ve often come across little things that have taken a bit of time to figure out. I’ve also often wished I had something to point to when less-knowledgeable people asked a frequently-asked-question. For example, I often had to explain what I expected from a band’s rider.

For those wondering, I’m a sound technician with some (admittedly quite limited) experience working on a range of different events at Durham University. At my university, there are many different technician collectives (for the most part, one for each college plus a couple for specific groups) but the vast majority of these are more lighting/theatre-focussed than sound focussed - resulting in a surprisingly small group of sound specialists (and an imbalance of training, making it hard to become a sound specialist without working with someone who was one already).

I’ve also always wanted to figure out Jekyll as I’ve used GitHub Pages for a long time but never really got into any of its cooler functionality. So it seemed like a smart idea to solve all these problems in one go.

The intention of this blog is to serve as a repository of information that I can point to. I’d also like to start writing a bottom-up tutorial series on sound tech basics, because (while I admittedly haven’t searched for this too much) it seems like it’s hard to come by a good centralised resource for sound tech advice.

So my (potentially somewhat self-important) quest with this blog is to try and create something that covers the practical basics of how to do sound on a day-to-day basis, built on things I’ve learned the hard way over the past couple of years.

I guess I’d better get on with that.