Most home recorders are already converting twice by necessity, getting the sound in and out of the computer. Intuitively, it makes sense to leverage analog processing whenever they’re appropriate to avoid these additional conversions prior to the sound interface. The other option is to record dry and use digital processing ‘in the box’ as there are no additional conversions in this case. There are no shortage of high quality software DSPs.

Most folks, including myself, likely have more pressing problems to address in their home studio. However, A/D conversion is certainly a factor to consider before mindlessly stacking another gadget on the signal chain. Think about where in the chain the gadget is being placed. Could the number of conversions be reduced by rearranging the chain? Could this gadget be placed in a digital loop with the sound interface, thus avoiding another conversion entirely? Most modern rack-mount DSPs do indeed have this capability.

However cabinets present problems. They’re expensive, heavy, and need to be driven loud to impart the impulse characteristics associated with modern metal and rock. This doesn’t gel with living in a 900 sqft house in a major metropolitan area. Many home recorders and musicians need an alternative.

One alternative is to simply record via the line out on a pre-amp…this sucks big time. You can compensate a bit with high and low cuts on an EQ but it will sound very thin and fizzy. Leaving the power amp in the chain and brining the signal back down to line level through a load box and speaker simulator is better. Many of these units feature adjustable high cut and voicing controls. Additionally, you retain the color of the power amp section. But the results are usually still disappointing. There’s something missing, speaker impulse response.

The sound heard on most rock and metal recordings of guitar is the result of miking a speaker cabinet. Without a cabinet in the chain, it’s virtually impossible to reproduce certain dynamics captured by the microphone. Enter speaker impulse samples. Thanks to Prof. Fourier, it is possible to tease apart the speaker impulse data for all possible tones given any guitar speaker. These impulse ‘deconvolutions’ may then be convolved with any digital audio track to replace the otherwise missing impulse dynamics. Several ‘convolution reverb’ plug-ins are available for the task.

With well captured data from a good cabinet and microphone, the results are amazing compared against the unprocessed track. Many free guitar speaker impulse deconvolutions can be found via Google. At least one free convolution engine exists for Linux platforms, jconv, and can be integrated with Ardour via the Jack protocol. I highly recommend anyone recording guitars direct-to-console check these tools out.

Untitled_demo1.mp3

This was after spending about a month’s worth of solid weekends learning the tools and reading some advice from professional metal producers/engineers. In the field of sound engineering, I’m still very green.

Symptoms of the disorder include attention on manufacturing differences between Russian KT88 tubes and various knock-offs at opposed to important factors such as the instrument, skill, and the physical recording and monitoring environment.

Cognitive behavioral therapy is indicated in any instance of this disorder. The individual must be trained to recognize the excessive research behavior and reduce the amount of gear research. The additional attention redirected to more important issues will result in sound improvement and reinforce the behavioral change.

The Kick
Metal mixes will often synchronize the kick attack, a bass guitar attack, and a staccato attack on guitar simultaneously for a super non-syncopated punch effect. The kick is often on top of all this in the mix and that takes a ‘big’ kick that’s ‘perceived’ as ‘deep’. There are a couple do’s and don’ts here.

First, chorus works miracles on kicks. Apply it to the kick and only to the kick. Play with the settings until you achieve the desired size of balls. I’ve successfully used a multi-voice chorus LADSPA plugin to this end. The A-B difference is extreme. Mixing the chorused signal with the dry signal will help preserve the kick punch/attack. A 50/50 mix has worked well for me.

Next, I think it’s generally good to avoid reverb on a kick as it can kill the attack. I’ve heard it used effectively on older ’80s metal but it seems uncommon in modern metal, where the ‘fist in the face’ punch takes precedence. If it is used then the wet signal should be mixed with the dry as to preserve attack.

Snare
The snare seems much more variable, even amongst a sample of closely related metal bands. Tuning can vary quite a bit as can the level with respect to the overall mix. However, I’ve found that the careful application of plate reverb can effectively spice up a snare hit, specifically in sampled kits. I’ve used a LADSPA plate reverb that includes some filtering allowing for adjustment of sonic characteristics as well. A formerly ‘stock’ sounding snare blast now possesses an almost ‘gunshot’ like quality. And that’s what we metal folks like; the drums that sound like the 4th of July.

Cymbals and Hats
Thus far it’s my experience that cymbals sounds good relatively unprocessed. Some EQ may be in order depending on the situation, but I don’t see much point in toying with the natural resonance with reverb or anything else per say.

Toms
Toms are still a bit of a mystery to me. I’m not particularly happy with results I’ve achieved thus far. The toms seem to lack in pitch characteristics and sound ‘flat’. I’ve experimented with reverbs, which didn’t provide good results. Perhaps something to broaden the frequencies like pitch shifting would help. It’s also possible that I simply have poor tom samples. Anyone who would like to chime in is certainly welcome!

I will take a ‘big-picture’ approach and outline how a number of different software applications are used together to achieve a sophisticated tool chain for recording music. I will not cover the operating details of each individual tool. However, I will reference external resources such as documentation and tutorials. Each individual tool has a learning curve of its own and will require time investment.

The Foundation
A personal computer running a Ubuntu Studio; a ‘mostly free’ distribution of the Linux OS geared toward multimedia production. It features a low-latency kernel that allows real-time monitoring while recording an analog source. Unless otherwise specified, it includes all the software discussed below. A reasonable quality sound interface is also required. Generally, a consumer grade sound card geared toward gaming is not appropriate. A sound interface designed for recording music with support for multiple balanced line inputs will save a tremendous amount of hassle and preserve fidelity. Many ‘pro’ and ‘prosumer’ grade interfaces use firewire to communicate with the PC. For a list of all supported firewire devices, click here. I personally use a Focusrite Saffire 4-in/10-out. Beware of Motu interfaces. They have a poor reputation with regards to supporting the Linux community.

The Plumbing
Browse the Ubuntu Studio menu and become familiar with it’s layout and contents. One of the items is ‘jackcontrol’ or ‘qjackcontrl’, a software version of a studio patch-bay. Consult the Jack Quick Start guide for an overview of basic functionality. Ensure that your sound interface inputs and outputs are visible from within jackcontrol before continuing. This application allows all other components of the studio to communicate with each other. It is the cables running from box to box in a physical studio.

The Kitchen
This is where it all happens. The Ardour application is a muti-track audio mixer/recorder with extensive track editing facilities. It communicates with your sound interface via Jack and can synchronize with all other sound applications, such as drum machines and sequencers, over the Jack protocol. Besides mouse and keyboard, Ardour can be controlled via external surfaces such as Mackie or Tascam mixing consoles. Enough information to get productive with Ardour is available through their online documentation.

Ardour supports LADSPA (Linux Audio Developer’s Plugin API) for effects processing modules. For most users, Steve Harris’s library will be more than enough to meet processing requirements. Effects can be added and removed from individual tracks via Ardour’s mixer console.

If you plan to record mostly ‘real’ audio sources, i.e. non-midi, then your sound interface + Ardour may be all you need. However, most folks don’t have a fully mic’ed drum set handy and many will want to emulate instruments they don’t actually play or own themselves. For these purposes, some additional software is required.

Instrument Sampler
Linuxsampler is capable of playing ‘.gig’ or ‘giga’ format instrument samples which was the format of some of the highest quality sample libraries. I say ‘was’ since Tascam discontinued in-house development of the format. However, development continues within the open source community. Regardless, giga samples are still widely revered in terms of quality today and many libraries remain available. Although the tool is free for non-commercial use, one generally must pay for the instrument libraries, which can run in the hundreds to thousands of dollars. However, a fantastic concert grand piano is available on the Linuxsampler site free of cost. Due to the software license, Linuxsampler is not included with Ubuntu Studio and must be downloaded from the Linuxsampler site.

The caveats aside, it’s the best sampler I’ve been able to find for the platform. Linuxsampler is a command line interface, so I recommend installing JSampler as well (also on the Linuxsampler site). This provides a graphical interface to the sampler engine. Consult the Jsampler documentation for installation and usage details.

Midi Sequencer/Tracker
Alright, we now have a nifty sampler that can be patched to Ardour either via the ‘mixer’ window or Jack directly, but there’s a catch. Ardour does not currently support midi-tracks. That is, the recording of midi data rather than the raw audio coming from the sampler. Capturing the midi data is ideal because Ardour can play back the track, using it as a midi source, into the sampler allowing different instrument setups to be substituted. If the audio is recorded then we’re stuck with that audio. Preserving the original midi-data provides extensive flexibility for re-mixing at a later time.

Enter the application Muse, a midi/audio sequencer. Rather than directly recording the audio output of the sampler with Ardour, we’ll patch the midi controller (i.e. a midi keyboard) to Muse, patch the output of the muse midi track to the sampler, and patch the sampler output to Ardour. Muse is responsible for capturing the midi-data while Ardour optionally records the audio simultaneously. If we’re unsatisfied with the instrument or sampler settings, the midi track can simply be played back in Muse with different sampler settings and re-recorded in Ardour. Muse also provides editing facilities for midi data.

The documentation for Muse is sparse. However, there are some decent tutorials to gain quick productivity. In particular, see Tutorial 2 that is relevant to patching Muse to an external sampler.

Drum Machine
Traditional hardware based drum machines are about as fun as drilling into concrete. To track a sophisticated song takes so long you just end up not doing it; the interfaces just stink. At least from my perspective, this all changed with Hydrogen. I don’t recall even needing documentation to begin using it, but a good manual is available on the site. A number of alternative drum kits are available, including a ‘death metal’ kit. Hydrogen will synchronize with Ardour over Jack. Mixing and panning of each individual drum piece can be performed through Hydrogen’s mixer. Like Ardour, Hydrogen also supports LADSPA plugins. When satisfied with the drum track and mix, just patch the output of Hydrogen to Ardour using jackcontrol and lay down the track.

Mastering
Personally, I consider ‘mastering’ the art of ‘pulling the tracks together’ to sound like a cohesive performance rather than x-consecutive weekends in front of a computer. Many people would actually classify this as part of the mixing process. Either way, it can be accomplished by ‘mixing down’ tracks in Ardour, possibly with some EQ or reverb plugins.

The other side of mastering involves loudness control and saturation of the dynamic range; ‘filling the sound space’ to produce a sonic perception of ‘fullness’. The tool for this job is JAMin. It provides a suite of filters, limiters, EQs, analyzers and other processors. Tracks are routed from Ardour to JAMin and then back to Ardour. Tutorials are available on the site.

Delivery
One part of the chain excluded from this discussion is tools to take the final master track from Ardour and publish it to one of many formats, mp3, CD, etc. This is because I’ve not yet reached this phase myself as of this writing. I’ll be sure to report my findings in a future update to this post.

The best of luck and satisfaction on your own musical endeavors!

The degree to which spoken language influences thought is intensely debated, with Steven Pinker amongst the most outspoken of Whorfian hypothesis critics. Daniel Casasanto (2008) refutes the popular anti-Whorfian stance proclaimed by Pinker on the grounds that Pinker’s claims are too broad in scope. Casasanto argues that one must distinguish between an Orwellian flavor of the hypothesis, where language and thought are formal equivalences, and linguistic relativism where language and thought simply influence one another. Although Pinker’s assertions may successfully challenge an Orwellian interpretation of Whorf, extending the argument to ‘weaker’ forms of the hypothesis, such as linguistic relativism, is logically fallacious (Casasanto 2008).

The degree to which programming languages in particular influence cognition has received little attention. An informal survey conducted by Richard Wexelblat (1980) revealed that  some programmers believe certain languages can interfere with abstract forms of reasoning such as data-structure design and high level engineering activities. Wexelblat expressed his personal concern over the popularity of “do it quick and dirty” languages, such as BASIC, and the generation of students indoctrinated to them. Although interesting, the usefulness of such self-reports is extremely limited. Accordingly, Wexelblat concludes with a call for controlled studies on the subject. Unfortunately, to my knowledge no such study has ever been conducted. Indeed, it’s likely that an experimental approach to such research is not yet sufficiently developed.

A strong version of the Whorfian hypothesis is likely an inappropriate foundation for considering the interaction between the mind of a programmer and a programming language. The language is not the programmer’s thought. Minimally, the language is the cumulative thoughts of many contributors under many transformations. However, a weaker version of the hypothesis may provide a starting point for the study of how programming languages influence the cognition of the programmer. However, significant definition needs to occur prior to applying a Whorfian-like hypothesis to programming languages. Here are some points I’ve identified.

1. Definition and scope of the term ‘language’. Certainly, programming languages are simpler than natural languages. There are closed definitions for the syntax and semantics for programming languages. One may assert that the set of all closed language definitions is the definition of language in the context of programmer-machine interactions. However, this definition is far too narrow as the programmer rarely interacts with the language specification itself. Rather, the interactive elements include emergent properties of the language, such as graphical and syntactical abstractions. Therefore, a useful definition of language in this domain must include all abstractions that carry meaning for the programmer including atomic elements such as keywords up to highly composite elements like user interface components. Developing a clear and agreeable definition will be challenging.

2. Capturing differences in state or state changes. This involves some method of objectively measuring changes in the programmer’s behavior due to changes in the ‘language’; using the broader form of definition above. These could be changes in the structure of the language that influences adaptive behavior on the part of the programmer or changes in the ‘behavior of the language’. Therefore, operationalized metrics must be established that represent an abstract measure of machine/language state and human state.

One could begin with high level programming language qualities such as type system, syntactical style, binding style, etc. and measure how a programmer’s approach to problem solving changes after continued exposure and use of a language that sits at a particular point on this qualitative coordinate system. One method that may be used to examine changes in the programmer’s state, in order to infer changes in problem solving strategy, is examination of their semantic network via lexical decision tasks at different intervals of language exposure time. Such tasks are used to measure word or concept availability in the domain of natural language (McNamara 2005).

If such experiments demonstrated a link between semantic network changes in the programmer that appeared programming language specific then Dijkstra’s intuition that a programming language influences a programmer’s thought processes gains validity. It follows that such influences would form a loop between the programmer and the machine/language forming a cognitive system where the behavior of the programmer influences the language behavior which influences the programmers behavior and so forth. The practical applications of such findings would include renewed appreciation of programming language diversity and help elucidate the relative strengths and weaknesses of language properties with respect to how they combine with the programmer to solve problems.

Carroll J.B. (Ed.). (1997). Language, Thought, and Reality: Selected Writings of Benjamin Lee Whorf. Cambridge, Mass.: MIT Press.

Casasanto D. (2008). Who’s afraid of the big bad Whorf? Crosslingual Differences in Temporal Language and Thought. Language Learning. 58(Suppl. 1), 63-79.

Dijkstra E.W. (1982). Selected Writings on Computing: A Personal Perspective. (pp. 129-131). New York, NY.: Springer-Verlag.

McNamara T.P. (2005). Semantic Priming, perspectives from memory and word recognition. New York, NY.: Taylor & Francis Group.

Wexelblat R.L. (1980). The consequences of one’s first programming language. Proceedings of the 3rd ACM SIGSMALL symposium and the first SIGPC symposium on Small systems. 52-55.

In this implementation, the participant is shown a series of 3D object pairs. On some trials, the two objects are different. On other trials, one object is simply a rotation on the xy plane of the other object by a variable multiple of 20 degrees. The participant responds by pressing ’1′ to indicate the same object or ’2′ to indicate different objects while their response time is measured. Previous research shows that response time increases linearly relative to the number of degrees one object is rotated from the other (Shepard, Metzler 1971).

The image to the right below shows the stimuli for one trial. The image to the left depicts my own results for 100 trials. My response time is far less than the typical Shepard (1971) subject but I have years of experience working with 3D graphics and, of course, wrote the code for this experiment. I’ve posted the code as I think it provides a decent example of accessing OpenGL from Matlab and a good starting point for related experiments. The code is available for download here.

Shepard R., Metzler J. (1971). Mental Rotation of Three-Dimensional Objects. Science. 171.3972, 701-703.

It is exceedingly unlikely that visual information is stored in memory for all angles of all objects encountered, as this would require virtually incalculable storage space. Therefore, object recognition is probably not based on rote comparison against stored images. An interesting and demonstrable model described over a series of papers from researchers at MIT proposes that top-down components of object recognition involves a set of 2D prototype objects from which a set of object transforms are learned. These learned transforms can be applied to novel concrete instances from the same object class (Poggio, Vetter 1997).

The best way to illustrate this is by example. I implemented the Poggio and Vetter (1997) model in Matlab and tested it on a set of cuboid prototypes. One can think of these as representing the cube like objects of prior experience. For this implementation, the 3D cuboid vertices were randomly generated. The 3D representations were tilted by a few degrees to avoid an accidental perspective and then projected to 2D space using a perspective projection. The resulting 2D cuboids are rendered in figure 1.

Of course, one rarely observes an object from just one angle, so we’ll add another angle. In reality, there would be many, but not all, possible transformation of the object class. For simplicity, we’ll consider one rotation about the x-axis by 20 degrees. The resulting object class is rendered in figure 2.

Upon this rotation, the model learns how to transform the set of 2D vertices defining the non-rotated object into the 2D vertices defining the rotated objects. In this implementation, the transform is learned by a single layer neural network. However, an analytic solution also exists if the vertices form a linearly independent set; for details see Poggio & Vetter (1997). At this point, we have a single function that will transform any 2D cuboid into the same, or at least very close (if class is not linearly independent), cuboid rotated by 20 degrees.

This can be demonstrated by generating a new random cuboid, one that is not in the prototype class, and using the learned transformation function to rotate the novel cuboid. Figure 3 depicts the random cuboid in red rendered in the same location as the rotated version in blue. This is intended to assist in recognizing a successful transformation.

It is key to recognize that a traditional rotation in 3D space is not being performed on the novel cuboid. The novel object is projected into 2D space and then rotated via the learned 2D->2D transform.

An interesting prediction implied by this model is that when an individual mentally rotates an object, their performance should degrade relative to the number of degrees they are trying to rotate due to repeated applications of learned transforms. For instance, if we wanted to rotate the novel cuboid 40 degrees then we could simply apply the learned transform twice and this should take twice the amount of time. It also follows that the performance should degrade linearly, as the transform is a linear function. In fact, this is exactly what was reported in the classic mental rotation study by Shepard and Metzler (1971). They found a linear increase in reaction time when deciding whether or not two objects observed from different angles were the same object as the degrees of rotation between the two objects increased.

It would be interesting to see if performance holds for rotations of different increments. Shepard and Metzler tested only one increment; all rotations were in increments of 20 degrees. Differences in performance would be expected if individuals stored more than one rotation transform for an object class. For instance, if asked to rotate something by 40 degrees one may apply two iterations of 20 or several iterations of a more granular transform. However, one may be able to jump strait to a 45 or 90 degree rotation, especially for cubes.

Furthermore, experiments investigating the effects of different object classes would provide additional insight. Although Shepard and Metzler argued their objects were novel, they were all composed of cubes. It’s possible that the visual system may be able to apply the cube transforms to the cubes composing the object individually. What would happen if pyramids were used as the atomic component as opposed to cubes? The Poggio and Vetter model examined here couples transforms to an object class. Therefore, differences should be expected when manipulating object class. More specifically, one may not expect performance increases due to learning effects to carry over to a new class.

Poggio T., Vetter T. (1997). Linear Object Classes and Image Synthesis From a Single Example Image. IEEE Transactions on Pattern Matching and Machine Intelligence. 19.7, 733-741.

Shepard R., Metzler J. (1971). Mental Rotation of Three-Dimensional Objects. Science. 171.3972, 701-703.