[OT] Re: Mixer units
[OT] Re: Mixer units
- Subject: [OT] Re: Mixer units
- From: Brian Willoughby <email@hidden>
- Date: Fri, 14 Mar 2003 18:43:42 -0800
Hello,
I have marked this subject as off-topic because I believe that, in hindsight,
the original message was off-topic. While the requested features are
certainly a valid consideration, the analogy that was made is flawed.
AudioUnits do not match up to the market for physical Mixer products. A more
accurate analogy would be to compare AudioUnits with potentiometers, buttons,
knobs, circuit boards, operational amplifiers, and other electronic parts. In
other words, a Mixer is a finished consumer product geared towards musicians
and audio engineers. The corresponding software component would be an Audio
Hosting application, like eMagic's Logic Audio Platinum, Digidesign's Pro
Tools, or MOTU's Digital Performer. The typical musician or audio engineer is
not going to be building their own mixer by writing code to piece together
audio units with a custom user interface. They are going to buy a finished
product.
Once the soldering iron heats up, you now have electronics engineer, not an
audio engineer. The consumer of AudioUnits is best compared to the consumer of
raw electronic parts. Electrical engineers are highly trained and can build
their own mixers, but this is a relatively rare exercise. Similarly, piecing
together Audio Units to make a software mixer is something that a seasoned
programmer should be doing, not a musician or audio engineer who just wants to
get to making their art (not that programming isn't an art - as a programmer, I
consider what I do to be an art).
Granted, musicians and audio engineers will be using Audio Units as plug-ins,
much like external processing and effects boxes or rack units. In this
respect, there is an argument that a reasonable variety of AUs should be
provided in the system, but Apple should not be expected to provide everything.
In any event, using AUs is not going to be easy for a non-programmer without
an Audio Hosting application, and it is the Audio Hosting application which
should provide virtual mixer features. I believe there is little benefit to
allowing non-programmers to build their own mixer outside a full-featured
hosting app.
Given all the possible Audio Unit features that can be implemented, and
considering the complexity of the open source Audio Units that already exist, a
mixer AU and / or stereo panning AU should be some of the simplest tasks to
complete. Any programmer capable of building a well-coded Audio Host should be
able to create mixing and panning AUs as needed for their Host App. In my
opinion, it is perfectly acceptable that Apple's CoreAudio team has focused on
the much more difficult tasks of implementing the critical pieces, and in their
limited time have left those of us in the developer world to implement the
easier stuff in the mean time before they can complete everything on the wish
list.
To put this another way: The lack of AUs which handle mixing and stereo
panning does not exclude anyone except the beginning programmer who is not
familiar with DSP and basic audio programming algorithms. I believe that the
primary goal of the CoreAudio team is to provide state-of-the-art system
support for audio in a device-independent fashion such that interoperability
between audio applications and audio hardware is taken to a new level. I do
not believe that they are trying to bring audio software development itself to
a new level accessible by less-experienced programmers. I could be wrong...
To reiterate, I am not criticizing the request for mixer and stereo panning
AUs from Apple, but I believe it is a bit overkill to compare the market for
physical mixer boxes with the market for Audio Units, especially the
insinuation that CoreAudio is somehow incomplete by not providing all the
features familiar to audio engineers who are at home on the typical mixing
console.
Brian Willoughby
Sound Consulting
Begin forwarded message:
Hi,
Great !!!! I don't think I'll make WWDC but it is an incentive.
I still think that the analog mixer is reasonable as an analogy. As you
point out it is not a reasonable definition of a specific piece of
code. It is however something that we are all familiar with.
Studios seem to gather up a massive collection of odd little boxes over
time. Compressors, limiters, sample players, graphic equalizers, noise
gates, patch bays, amps, pre amps, and various distortion boxes (vital
to the well being of guitar players). It is not unusual to see rack
after rack full of this stuff all wired up in some odd fashion.
In the analog world a number of discrete items make up a studio. One
of these items is a mixer. The computer implements (or at least can
implement) the entire studio. The question is how easy is it to do so.
A reasonable way to check out your ability to do so would be to see how
close you can come to duplicating each item in the analog studio with
code.
As with any analogy you can carry this one to far. An analog mixer by
it's very nature starts off with a definition of how many channels and
how many busses. I do not see that as the fundamental unit of structure
to a software mixer. The analog mixer always does pretty much the same
thing on each channel. About the only exception is ones that have a
limited number of microphone inputs. Again not a reasonable thing to
duplicate in an software mixer. An analog mixer lines everything up in
time without any thought at all. The software needs to take a bit more
care.
A one to one correspondence between each chunk of code and each box
would be counterproductive. It puts a set of definite boundaries in
places that they probably do not make sense. It probably also does not
break down each box into small enough pieces. I might suggest though
that a series of example programs making up a series of common boxes
(one of them a multi bus mixer) would make a great WWDC presentation
......\
One of the most basic ways to check out a set of gear is to plug it all
together. Any studio I have ever been involved with came up with a
number of surprises the first (and usually well past that) time it was
fired up and listened to it. It's amazing the stuff you can hear almost
immediately. I only have about 35 years in at this code stuff but it
seems to also give a surprise from time to time .... The structured
example stuff might also be a reasonable way to check things out.
Enjoy!
Bob Camp
>
> On Tuesday, March 11, 2003, at 09:27 PM, Bob Camp wrote:
>
>
>
>> Hi,
>
>>
>
>> A lot of this comes down to having a model that people are
>
>> comfortable with. The longer it takes to figure out the presentation
>
>> the worse the user experience. Frustration is not a good thing.
>
>>
>
>> When I sit down with a good old analog mixer I expect to have:
>
>>
>
>> 1) Pan pots - both for stereo and mono sources
>
>> 2) Trim pots on each input
>
>> 3) Mute and solo switches
>
>> 4) Basic tone adjust
>
>> 5) Aux sends and returns
>
>>
>
>> If that stuff isn't there on my shiny new mixer I'm going to wonder
>
>> what I spent my money on.
>
>>
>
>> I think the same thing applies to the software equivalent of the
>
>> box. A quick look at any number of analog boxes will give you a
>
>> feature set that they pretty much all have. Each feature cost them
>
>> something to put in there. None of them came for free. They put them
>
>> in there because that's what people needed and used. When they left
>
>> them out people complained or bought another brand.
>
>>
>
>> The software "toolkit" probably will have the same sort of market
>
>> that the analog mixer did. It's a building block that more or less
>
>> does the same thing. You use it to as part of a setup. In the end
>
>> they should look a lot alike.
>
>>
>
>> Enjoy!
>
>>
>
>> Bob Camp
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.