Organization is difficult for some, and absolutely vital for others. But our brains are built for abstracting and organizing, so why not run with it?
In programming, abstraction describes the act of turning a complex object into a box with some inputs and outputs. If you’ve worked with Max, Pure Data, or Reaktor, you’ve seen abstraction in the form of the objects you patch together to make your system (or, in Max, patches that you include in other patches are actually called “abstractions”). Those boxes often have a lot going on in them–timers, data transformations, DSP, etc. But you don’t need to know about that. You only have to know what it does when you tell it to do its thing.
In computer science, the definition of abstraction goes something like this:
Abstraction is simply the removal of unnecessary detail. The idea is that to design a part of a complex system, you must identify what about that part others must know in order to design their parts, and what details you can hide. The part others must know is the abstraction.
In the general use, abstract is defined as:
expressing a quality apart from an object – the word poem is concrete, poetry is abstract
The two go nicely together. And you might say that the general definition itself is an abstraction of the computer science definition. The CS definition includes additional detail that’s implied by the dictionary definition, which I suppose makes it a subclass of the dictionary definition. But enough about programming.
As a sound tech person, I spend a lot of time talking with people who aren’t sound tech people about sound tech for a thing they want to make. Somewhat often, they attempt to spec out the equipment they want–be it sensors, software, speakers, or microphones. And in almost all of those scenarios, I end up talking them into a completely different set of equipment to do the thing they want to do. I’m sure it has to do with trying to be helpful, or not realizing that it’s my job to translate their designs into tech specs, or something else having to do with not being used to the support. Whatever it is, it’s one of the trickier conversations I have to have day-to-day. It would be much easier for me for someone to come to me with a nebulous artistic idea, and then let me figure out how to make that happen. And most likely, the project would end up better for it. I wouldn’t be redoing their work, and the other person wouldn’t be censoring themselves based on their knowledge of sound tech.
One technique I’ve found useful in this is to abstract away the technology. I lead with these questions:
- What does your thing sound like?
- How does that sound change over time?
- How does that sound change in response to a human, and what is the human doing when it changes?
- Where is the sound coming from?
- Are there multiple sounds?
Most of the time, the person will still try to specify some tech they know about or heard about. And sometimes that’s fine. But I still try to follow that with, “don’t worry about the tech. Let’s see if we can make your dream.” That usually does the trick, and then we’re on to talking about what they’d really envisioned for their project.
This kind of experience isn’t limited to just sound tech people. Sound designers love to tell stories about creative directors attempting to specify sound effects, rather than imparting a vision. Graphic designers have whole books and blogs dedicated to clients getting a little too hands on for their comfort.
How do you ensure your clients–whoever they might be–get what they’re really looking for?