4 ms·

> Is this not a blatant layer violation? This is the one of the areas a recording engineer's problems are different than a software engineer's intuition. In s

> Is this not a blatant layer violation? This is the one of the areas a recording engineer's problems are different than a software engineer's intuition. In software, we have a lot of problems that can ultimately be traced back to not having good "visibility" into the software or its state. This has various far-reaching consequences, from specialized tools to examine software (such as debuggers) to cultural values ("one job per component") that help us reason about complex systems we cannot see. But in the case of audio, we have a multiple sensory organs to directly perceive sound. A bad audio engineer would be able to push a few buttons to move his headphones around in the signal chain and know in seconds where the EQ is occurring. A good one would simply know the U87 rolloff "by sound" and would not have to conduct any investigation at all. There are some cases where more detailed analysis is done with fancy tools–mastering song recordings, for example. But in live sound, an audio engineer's primary concern is UX, because good UX is the difference between solving a problem quickly and annoying pops or worse. One button that engages a good EQ is much, much better than something like this: http://adn.harmanpro.com/product_attachments/product_attachments/1373_1425316080/hi_fcs966_original.jpg http://adn.harmanpro.com/product_attachments/product_attachm.... And epoxying the single button to the correct position is even better still!

Ericson2314 10y ago
Isn't controls on mics the worst UX because the wrong people are always messing with them? You raise a good point about (even in the bad case) moving headphones around the signal chain---and damn as an (especially functional) programmer I'd like that to be able to tap arbitrary locations in data flow like that. Enough all these control-flow-based debugging tools! > One button that engages a good EQ is much, much better than something like this Well there's always overkill, but would one of those be worse than one of those and then, next in the signal chain, a 1-button EQ whose functionality is completely subsumed?
- ww520 10y ago
  Yes. Especially the instrument people who always turn up their instruments' volume mid play because they want to push theirs through. It really messes up the sound engineer's overall tuning.
- mrsirduke 10y ago
  > You raise a good point about (even in the bad case) moving headphones around the signal chain---and damn as an (especially functional) programmer I'd like that to be able to tap arbitrary locations in data flow like that. Enough all these control-flow-based debugging tools! You should look into dtrace and it's new Linux counterpart who's name currently alludes me. It's almost like being able to do just that.
  - Ericson2314 10y ago
    I'm very aware of dtrace. probes are kinda like faking dataflow on top of control flow I guess. I was thinking more of a development aid that would render a dataflow graph like max/msp---in the general case the graph itself is changes but thats's OK.

Ericson2314 10y ago

Isn't controls on mics the worst UX because the wrong people are always messing with them? You raise a good point about (even in the bad case) moving headphones around the signal chain---and damn as an (especially functional) programmer I'd like that to be able to tap arbitrary locations in data flow like that. Enough all these control-flow-based debugging tools! > One button that engages a good EQ is much, much better than something like this Well there's always overkill, but would one of those be worse than one of those and then, next in the signal chain, a 1-button EQ whose functionality is completely subsumed?

ww520 10y ago
Yes. Especially the instrument people who always turn up their instruments' volume mid play because they want to push theirs through. It really messes up the sound engineer's overall tuning.
mrsirduke 10y ago
> You raise a good point about (even in the bad case) moving headphones around the signal chain---and damn as an (especially functional) programmer I'd like that to be able to tap arbitrary locations in data flow like that. Enough all these control-flow-based debugging tools! You should look into dtrace and it's new Linux counterpart who's name currently alludes me. It's almost like being able to do just that.
- Ericson2314 10y ago
  I'm very aware of dtrace. probes are kinda like faking dataflow on top of control flow I guess. I was thinking more of a development aid that would render a dataflow graph like max/msp---in the general case the graph itself is changes but thats's OK.