Designing a modern mixing console - Part 1 (and introduction): Channel Input

[Balijon]

First of all, I really like this thread! Good concepts in here, I like to add some 'fuel' to the conceptual discussion.

I like the 500 format concept for the channel processing modules like Mic-Pre / EQ / Comp-Lim. This way everyone can create his own preference.
I like the idea behind Tree-Audio, provide a plug-and-play platform that provides the basic infrastructure for control and connections.
But lets take it a step further.

I have been fighting and replacing bad switches all my live, so (reliable) Fet/Cmos switching is a big plus.
In addition, switches take up a lot of real estate in the control surface.
Another point is that you would basically want matrix switching within the channel.
- Decide which processing module is connected to what input/output and in which order
- Decide which control-output is connected to what source (pre/post etc..).
If you look at the current switching arrangement around the Input/EQ/Insert, this basically calls for a more smart approach based on a routing/switching matrix similar to the 'group-bus' lines between the channels.
With the Maxim DG407 you could create 8 internal input/output channel-bus-lines.
Some of which could have a 'fixed' feed like the line inputs, others could be used as floating lines.
To keep things simple for a start, consider the 8 lines connected to the outputs from the various sources:
1- Line input-1
2- Line input-2 (DAW output for example)
3- Group-bus Buffer
4- 500-Module-1 output (Mic-pre for example)
5- 500-Module-2 output (EQ for example)
6- 500-Module-3 output (Comp/Lim for example)
7- Patchfield-Insert-return
8- Channel Fader output (for post fader sends)
Each input (and volume control) would get its own multiplexer attached to the 'output' lines and can switch to any source.
Examples are of course the processing modules (like the 500 modules and insert) and channel controls like channel-fader, direct-out & aux-sends.

Another discussion point I would like to make, is on our traditional approach to bus-lines between the channels.
For me they are technical identical, but we are used to split them into 'static' functions in our communication (Aux/Cue/Send/Grp/Mix/Prgm etc...)
If you take a look at ADT they provide the option to use CUE-send to additionally route to the Groups http://www.surroundconsole.com/SRC51/ImgBdIM5Fdr.html . I like their way of thinking, I would like to take it a step further:
Why not have a generic number of bus-channels (16 or 32) and assign any volume/pan control to any bus-channel via a matrix switch?
With the previous described 'Channel-matrix' concept, you can assign any volume control source to any of the 8 lines anyway.
As the Channel-Group-Buffer is assignable to any bus-line, why would you still need 'dedicated' Aux & Cue modules? (still possible of course)
Maybe 'In-line' should become 'In-Matrix'.....

This way you could limit the discussion to how many Volume and Pan control's would you actually need concurrently in any workflow, how you would assign them would be totally flexible.


Theo

 

[Nishmaster]

Sorry folks, I have been caught up with other activities that have limited my work on this project.

Going back and thinking about logic more has gotten me thinking about changing my stance on automation. Discussing the project with the other studio owner has clarified some of the requirements as well. Currently we have a Digi Control24 that we use a our big expensive mouse. As we have gotten quite used to the workflow of that product, he would like to keep that in addition to the new console. I think that request is a bit silly, but I can also see his side of things. He does more electronic and less rock than I do, therefore his automation requirements are a bit higher. We could use both boards, but that makes the physical desk quite large and limits the analog portion to 40 channels, the most that would fit in that space.

A compromise I thought of would be to build the analog desk and then just purchase a much smaller control surface. This, to me, is the idea compromise between cost/complexity. However, he did request that I look into fader automation. MIDIBox has a nearly prebuilt solution for the HUI protocol containing a PIC and motor drivers that looks more or less plug and play. The problem with that solution is repairs. With it not being my code, I can't control for rewrites that may be necessary should parts go obsolete. It looks to be open source, though, but definitely far over scale for this small of a task and beyond my programming abilities to understand.

Another route is to go Arduino. The interface is simple and each Arduino could control 8 motor drivers with ease. The problem is the HUI protocol itself, of which there is no open specification. So, the trade off is that it would likely require a moderate deal of reverse engineering. The downside to both of these approaches is that I'm limited to 32 faders, but even SSL has that issue with HUI in ProTools. There is a max of 8 faders per HUI MIDI connected device.

I still "vote" to make the group return a patch into the module, which eliminates the need for the switching AND the need for the "line/group" selector switch.

I'm nearly positive at this point that this is the direction to go. Why have the switching when doing it this way, while not as "high-tech" feeling for the user, eliminates 768 switches and erases the need or questions about the group/l/r routing situation.

Do you know there's static logic (gates, diodes or relays sitting there doing nothing but wait for the push of a button or an electrical stimulus), as opposed to sequential logic (micro controllers with their noisy clocks). 

Yessir, quite true.  I think a static-logic routing system of that complexity eludes me, though.

Have you considered going in this direction Nish? You could satisfy your programming itch with micro controllers and branch that out to a simplified, analog input card.

That's how Otari (Sound Workshop) handled things on their Concept (and other) desks. 

If I do buckle and go with microcontrollers, that is indeed how I was thinking of keeping everything separate.

Well. this thread has died.....

For the EQ section...why not use a 500 format module?

In your I/O design, it seems that a 500 could fit above/below the rest of the module?

Yeah, again, sorry about the dead air. It's been mostly brainwork on this project and real life things to deal with.

It could very easily be a 500 format module like an API desk. I'm not sure I want to deal with the extra cost of another panel, though. It's a bit cheaper to put everything on one panel than it is to get separate panels made.

That brings me to another question I've been thinking about for the past week or so. What is the current trend for getting signals to and from the master section? I see wire looms in some desks and bus cards in others. I feel like shielded bus wires would possibly be best from a performance standpoint, but I have questions on capacitance problems there as well as complexity from a physical standpoint. There's no way I'm running a distinct set of all signal wires for each module to the master section, that's a seriously large (and costly) amount of cable (and space). Maybe that's what's done, though, I really just don't know the answer to that.

Theo, I'm quite positive I'm not at all understanding your internal channel routing concept. Won't the switching matrix require 64 possible points, then, and not 8 (ie all the possible internal routing combinations)? That seems to be quite complicated for just a channel module.

-Matt

 

[Balijon]

Theo, I'm quite positive I'm not at all understanding your internal channel routing concept. Won't the switching matrix require 64 possible points, then, and not 8 (ie all the possible internal routing combinations)? That seems to be quite complicated for just a channel module.

-Matt

You don't need 64 points, it is 8xIn to YxOut (Y can be any number based on the number of controls and outputs needed).
In fact most of the lines inside the desk are currently there, only they are not always accessible in a flexible way.

Let me give an example of a typical In-Line workflow 'Tracking' setup with various signal routes to show what you can do.
We have a number of (processing) modules:
- Mic pre-amp
- Limiter
- EQ
- Compressor
Blue lines are for the record-chain, Red lines are for the monitoring-chain

Feed to DAW in:
Mic-Preamp -> Line-1-in -> Limiter -> Fader-1 -> Direct-out -> DAW-in

Cue-send:
AUX-1 = Limiter-out (=pre-Fader-1) -> Fader-AUX-1 -> PAN -> Groups-7&8
AUX-2 = Fader-1-out (=post-Fader-1) -> Group-6

Monitoring-Mix:
DAW-Out -> Line-2-in -> EQ -> Comp -> Fader-2 -> PAN -> Groups-1&2

Effect-send:
AUX-3 = Fader-2-out (=post-fader-2) -> Group-3
AUX-4 = Comp-out (=pre-fader-2) -> Group-4
AUX-5 = Line-2-in (=pre-EQ/Comp/fader-2) -> Group-5

It is very easy to change the order of the EQ and the Comp, by setting the switches of Module-2 and Insert-Send

For a different workflow you can create a complete different assignment and signal routing

Theo

 

[Brian Roth]

For the EQ section...why not use a 500 format module?

In your I/O design, it seems that a 500 could fit above/below the rest of the module?

It could very easily be a 500 format module like an API desk. I'm not sure I want to deal with the extra cost of another panel, though. It's a bit cheaper to put everything on one panel than it is to get separate panels made.

That brings me to another question I've been thinking about for the past week or so. What is the current trend for getting signals to and from the master section? I see wire looms in some desks and bus cards in others. I feel like shielded bus wires would possibly be best from a performance standpoint, but I have questions on capacitance problems there as well as complexity from a physical standpoint. There's no way I'm running a distinct set of all signal wires for each module to the master section, that's a seriously large (and costly) amount of cable (and space). Maybe that's what's done, though, I really just don't know the answer to that.

-Matt

The reason a 500 module for the EQ seemed like a good idea is the fact there are SO many options, versus deciding on only a single choice for this console project.  IOW, if you decide to put everything into a single module, you are stuck with just a single "flavor".  This would also make the design less interesting as an "open source".

As for your question re. the internal cabling, there are two distinct issues.

1.  I/O from each module to/from the patchbay or external connects.  That would be line inputs, inserts, etc, and you are stuck with some sort of wire harness for that.  In recent times, many manufacturers have gone to shielded ribbon cables.  Other (and older) desks use a multiplicity of 1 pair shielded cables for each module.

2.  Busing lines from the modules to the summing amps (where ever they happen to be located).  Many desks used some sort of multipin connector on each module, which could be a standard "edge board" connector or a "Eurocard" style connector.  The mating connector down in the desk's frame is attached to a circuit board with circuit traces going down the length of the desk, or individual bus wires tying each mating connector pin to the others down the line.  Old Neve desks had a variation of this, with each bus line housed in a "slot" of a piece of extruded aluminum to shield the buses from each other, but that is kind of a hairy mechanical design.

The down side of that arrangement is working out the "mechanicals" so that the module connectors correctly mate with the connectors down in the belly of the beast.  An alternative is to use a ribbon cable to "daisy chain" down the length of the desk.  In the Otari Concept desks, they had hinged "trap doors" on the underside of the desk, which could be opened to pop loose the busing ribbon from the module.  They used a similar arrangement for the DC powering into each module, which was on another connector.  The DC wiring was its own harness, which ran back to a distribution block.

Best,

Bri

 

[Brian Roth]

As far as automation goes, you've opened a new can o' worms!  I've been meaning to look more in depth into MIDIbox, so here is my excuse!!

As for the Arduino approach, that idea was briefly kicked around on the MCI console forum as a possible retrofit for the long-obsolete auto sold with those desks.  However, MCI used VCA level controls, which made for a very interesting situation to ensure correct level matching of "set" vs. "recall" voltages to the VCA's.  The so-called "analog outs" from the Aurduino are actually PWM signals, requiring filtering and shaping to act as a DC control voltage for the VCA. 

I guess with motorized faders, the positional info from the fader during "recall" would have to be constantly compared to the stored info to ensure the PWM signal to the fader correctly moved/parked the fader.

Best,

Bri

 

[boji]

"positional info from the fader during "recall" would have to be constantly compared to the stored info to ensure the PWM signal to the fader correctly moved/parked the fader."

This would make for some fun and challenging code. My old Tascam DM-28 was fond of doing the fader jitterbug. I always had to flick them to get them to shut up.

How do automated faders typically find position?

JR's autotune drum tool I bet required some pretty fantastic code.

 

[JohnRoberts]

"positional info from the fader during "recall" would have to be constantly compared to the stored info to ensure the PWM signal to the fader correctly moved/parked the fader."

This would make for some fun and challenging code. My old Tascam DM-28 was fond of doing the fader jitterbug. I always had to flick them to get them to shut up.

How do automated faders typically find position?

JR's autotune drum tool I bet required some pretty fantastic code.

Lots of code and I'm still improving it.

While for the record I do not automatically tune drums, I read the drums state of tune or clear and give the drummers arrows pointing in the direction he needs to turn the lug,,, I have had people ask about building this into a drum and making it automatic but it requires too much hardware in the wrong places and would interfere with the drum's day job.

Regarding closing the loop on motor faders this involves damping a servo loop so it doesn't overshoot, effectively slowing it down some so the feedback is there in time, and it doesn't hunt above/below. Classic problem with servos.

I suspect there are different approaches for positional feedback if motor fader is actually passing audio. It could involve a another linear resistive track to determine position. If the fader is driving VCAs or digital with a control voltage, that voltage is the positional data. Another option is to use stepper motors and keep count of where you are (or should be).

Most motor faders today are probably not passing actual audio.

JR

 

[sahib]

....My old Tascam DM-28 was fond of doing the fader jitterbug. I always had to flick them to get them to shut up.

How do automated faders typically find position?

Jitter is a result of cheap control.

Automated fader is basically a servo motor, in which there is a feedback mechanism to establish the position. The feedback mechanism can be a potentiometer or encoder. The encoder banches out further to mechanical and optical.

In the case of a potentiometer feedback a resistive track parallel to the audio track is used. It simply acts as a voltage divider. The voltage (DC) on the wiper is read and the position of the fader is established.

In the encoder feedback we count the pulses to establish the position.

Jitter on your old Tascam  is basically the servo going into oscillation due to overshoot. This is a result of not having acceleration/descelleration, or sufficient implementation of it. A mixture of a mechanical and programming issue. 

When the positional command is sent to the servo, the motor should accelerate, reach to its maximum speed, descellerate and neatly stop at the destination.  If you look at most motorised faders you'll see that the (DC)  motor is coupled to the fader by a timing belt. Which means it is a direct drive and it is not so easy to implement acceleration/descelleration. If the fader is moving full length then things are easier as you have sufficient distance. But in the case of  fader moving say only a few milimeters the motor does not have much time to accelerate, reach to its full speed and descellerate. The only mecahanism that will give this breathing space to the motor is the ratio between the number of teeth on the timing belt and the cog and there is not much space to manouvre there. The other aspect is to read the current position, compare it to the destination and establish a speed control. A lot of hard work on programming. So whichever way you look at it quite a fine tuning required there.

 

[abbey road d enfer]

Moving faders is very often the kind of thing that ends up on the desk of a junior designer, and their most common mistake is using too much brute force; then the system is not stable enough and it has overshoots. A good regulation is PID (Proportional, Integrate, Derivative); its design starts with measuring the dynamic characteristics of the moving object (max speed, acceleration, damping).
It seems Tascam designers have done their homework, because my DM4800 works flawlessly in that respect. I have a Behringer side-car fader pack which, in comparison acts like a caricature of uncontrolled hectic behaviour.

 

[Andy Peters]

Moving faders is very often the kind of thing that ends up on the desk of a junior designer, and their most common mistake is using too much brute force; then the system is not stable enough and it has overshoots. A good regulation is PID (Proportional, Integrate, Derivative); its design starts with measuring the dynamic characteristics of the moving object (max speed, acceleration, damping).

It's a lot trickier than it seems! Part of a camera design I recently completed involved a stepper motor turning a lead screw which moved the sensor electronics back and forth (from a retracted home position to an extended operating position).  The problem was greatly simplified because there were only two positions to deal with, and only one (the operational extended position) had to hit its location with any accuracy. (Which was to be repeatable to less than a pixel size, which is like 5 microns or something silly like that.) Oh, yeah, the sensor electronics lives in a vacuum, so the forces on extension are different than on retraction.

I ended up using a lookup table for the acceleration and deceleration, and four optical position sensors. One for home and one for "almost home," and one for fully extended and the last for "almost fully extended." It was great fun working on this, too; for a while, I clamped the assembly to my work table and hung a ten-pound hand barbell from the mechanism to model the vacuum.

It was as fun as the sensor temperature control loop, which regulates down at something like -50C. I was able to make snow on my desk when I ran the cooling at atmosphere. Heh heh.

-a

 

[JohnRoberts]

Making snow at your desk might be desirable in Az during the summer months....  8)

JR

 

[Brian Roth]

The moving faders system I'm most familiar with is part of the SuoerTrue system that was sold by Amek and used on their high end desks.  I can't claim to be a "super expert" on the entire system's subtle aspects, but I've had to do troubleshooting and a bit of reverse-engineering on two desks from the 9098 family.  If my memory is correct, that is a total of 180 100mm moving faders and 72 shorter (60mm?) moving faders between the two desks.

Amek used P&G slidewire pots.  Those had a small "slot car" DC motor whose pulley moved a piece of "fishing string".  I don't see the same faders at the current P&G website, but there is probably info at Dale Manquen's website.  Anyway, these indeed had an extra conductive plastic track for positional info for the servo control.  Since Amek ran analog audio through the fader, a mono slidewire had two tracks, while a stereo fader had three.

There is a TON of circuitry in each of the Amek desks for the automation, but that also included the ability to change the state of many pushbutton switches as well as performing "total recall snapshots" of all the rotary pots (which also had an extra section for positional info).  Moving the slidewires and changing switch statuses was also stored/recalled under SMPTE timecode control.  An external PC acted as the storage/file management system.

Another desk I've worked with (DDA Profile) came factory delivered with Uptown moving fader automation, but I never delved deeply into that...especially since it came with NO docs for the auto!  Now that AT! (parent company of the current owners of AP!) now owns Uptown, forget about ever getting any service assistance.

OTOH, the ancient MCI JH-50 automation (and later versions sold by Sound Workshop/Otari) used VCA's for audio level control.  In these systems, the slidewire fed a DC level into an A/D which was "digested" for storage/recall AND also reconverted by a D/A which then controlled the VCA.  That worked around the need for any sort of positional feedback.  IOW, if the slidewire was spitting out (say) 5 VDC at a particular position, the A/D followed by a D/A spit 5 VDC into the VCA.  Note...actual voltage scaling was different than I described, but the concept applies. 

It was that latter VCA design concept which made me say "whoa!" to the possibility of using an Arduino system to make a modern retrofit for the old JH-50 systems.  While the Arduino has 10 bit A/D inputs, the stock "analog" outputs are PWM with a rate around 400 Hz...not a faithful 10 bit re-creation of the original analog input.

And NOW we are discussing hacking some sort of fader (and more???) auto via ProFools.  EGADS!  IMHO, that one is a Fools Quest.  Lack of published protocols as well as the fact that Av!d will likely change everything "tomorrow" (so all current system owners will have to dump and replace everything for the "uggrade treadmill") seems to be beyond the abilities of Ordinary Mortals.

I will quit now, since my hatred of Av!d and ProFools is bubbling to the surface <g>.

EDIT....concealed some trade marked names.

Best,

Bri

PS,,,in the back of my mind, I recall that Harrison was doing some sort of "open source" stuff for auto, but IIRC, it ain't ProFools compliant.

 

[Andy Peters]

Amek used P&G slidewire pots.  Those had a small "slot car" DC motor whose pulley moved a piece of "fishing string".  I don't see the same faders at the current P&G website, but there is probably info at Dale Manquen's website.  Anyway, these indeed had an extra conductive plastic track for positional info for the servo control.  Since Amek ran analog audio through the fader, a mono slidewire had two tracks, while a stereo fader had three.

FWIW, the Mackie Control Universal uses the same thing, except that it's encoder-only (no resistive tracks for audio).

It was that latter VCA design concept which made me say "whoa!" to the possibility of using an Arduino system to make a modern retrofit for the old JH-50 systems.  While the Arduino has 10 bit A/D inputs, the stock "analog" outputs are PWM with a rate around 400 Hz...not a faithful 10 bit re-creation of the original analog input.

Rather than constrain yourself to Arduino, consider doing up a microcontroller board with micros that have proper D/As and A/Ds on board (various Silicon Labs parts, for example). And there are many 12-bit SPI converters available.

-a

 

[abbey road d enfer]

Automation is a major endeavour. Many companies have burnt their wings trying to produce the ultimate fader automation. Most have gone out of business or found a more profitable activity.
Personally, I have never been "fluent" in using any automation; dedicated mix engineers use it all the time, so they have their brain connected but mixing is a small part of my activities, so when comes mixing time, I have to have the manual open.
Ever since I use Samplitude, which has clip level since day one (PT has it finally!), I never had to use any automation.
The nice thing in a custom-built analog mixer is that the signal path can be optimized like no other, but automation, I would either use an existing system (Flying faders or GML) or completely forget about it and have automation in the DAW, that would always end up cheaper.

 

[Nishmaster]

Yeah, there are a lot of questions in regards to controller protocols, especially as concerns Avid. The closest thing to a universal standard is the HUI protocol, which runs over MIDI. The specification has been reverse engineered well enough to create this type of system.

The big limitation is that there is a maximum of 8 faders per HUI interface, with a maximum of 4 interfaces in Pro Tools. This puts the maximum number of automated faders to 32. To simplify, these can be hard-designated as opposed to flexibly assigned throughout the desk. This means 4 single UART micros or a micro with multiple UARTs. The reason I mentioned Arduino is simply because some heavy lifting layout-wise is already complete and a library exists to intercept MIDI over the serial pins. The other pins needed are pins for fader position, digital pins for the touch sensors, then + and - voltage out to the motor drivers. Even 1 Arduino per automated bucket is cheap. Plus, mute automation is not needed (do it in the box), and to be honest, I can count on a single hand the number of times I've used pan automation, so take that away too. Recallable EQ? Forget it. Do that in the box too.

So, that leaves us with just fader automation only. The board design work is done for us, the MIDI interface library work is done for us. Really, two necessary items are left: motor driver board and servo program. Intercept the required note and value, send the value to the servo function. Iterating through 8 servos really won't take much in horsepower or code terms. It's a basic read, compare to destination, determine current velocity, determine total move time, clamp at some destination value (with appropriate fudge factor for damping/noise). At least it is in my head. Modern motor faders don't reach more than 10 bits of precision anyhow, (nor does the protocol) so there's no need to exceed that in the code either. This gets a little trickier when moves are small or slow.

Of course, the other side of the coin is VCA control, but in that case you're really just swapping motor drivers for D/A chips. 12bit cheapo units would probably work here though. They make 8 channel 12bit D/A at low cost. The PWM outputs on the Ardiuno set up are not really up to the task.

A lot of this is just talking off the cuff, but to me this part seems easier than some of the other pieces of the desk.

-Matt

 

[Balijon]

How about using the control voltage from the individual faders servo track to govern the VCA's?

Did you have a look at the ALPS motorized faders with touch-sense-control?
The N-faders are quite affordable (60mm & 100mm).
100mm K-faders compare to P&G's size wise and have an extended operational life expectance.

ALPS also produces dual-track-motorized-units where one track can be audio law (A or D law) and the other one is a servo track (B law).
So no VCA's would be needed.
http://www.alps.com/WebObjects/catalog.woa/E/PDF/Potentiometer/SlideMixers/RSN1M/RSN1M.PDF

Theo

 

[Brian Roth]

Perhaps desk automation should be a different "track" on this thread???

lol

Best,

Bri

 

[Nishmaster]

This desk isn't dead, it just smells funny.

Lots of internal discussions and debate over number of channels, automation requirements, inline/not inline. We've been debating over workflow and what seems best for all the engineers here. Dollars for testing have shifted elsewhere during the holidays.

Looks like the input is going to get simplified greatly, eschewing the group select function for breaking that stuff out to the patch bay where it probably belongs. Most likely just a line receiver and trim, nothing very fancy at all.

Meanwhile there have been sketches for various other pieces, with a little testing, but not much more to concretely document here. I am currently working on the EQ schematic, but as John pointed out earlier, using off-the-shelf parts is resulting in compromises that I don't like much. Dual gang reverse log pots are basically non-existent in DIY quantities (at least, for good PCB mount versions that allow for decent control density).

Anyhow, I will probably update some things here as the holidays give me some time off. Also, the fellow who posted regarding the modular console design may want to peruse through this as many of the basic design questions have been answered by the wonderful gurus here.

-Matt

 

[deuc224]

One thing that i wouls say, i know its handy to each for an EQ or compressor but you could really set it up with dual inserts and make the EQ and compressors in buckets( not 500 series). That way you can expand as you go or if you dont really need them in the path, you dont have to insert them.

 

[r2d2]

  WOW !

so incredible project ...

but about the cost ?

i seen some neve V3 48ch (inline 48x2) desk in good working health for sale under 30000 $
...also ssl 4000 - 40ch  too ....


peace!
r2d2