Hey,
that sounds very nice, all in all… thank you for your long description of the audio quality - that is good enough for me… 
btw. with cascading (sorry for the unclear description, it is not my native tongue ;-)) I meant the audio signal going through multiple chained 4311s, which I think would worsen the sound quality (as it goes through multiple amp stages) - but this is not the case in your design and this is very good
When my other project is finished and my government grants me another time segment ;-), there are two ways to continue…
a) use your mixer pcbs and extend the design with motorfaders for volume control and encoders for panning and fx sends … if possible, I don´t want to dive into core8 programming.. maybe there is a way to connect everything to a core32…
b) use an own approach with the 4311s… I just had the following idea allowing for an arbitrary number of mixing channels only involving one 4311 per mono input channel, I would love to hear your comments on that
audio in socket
|
direct out socket
|
|_ input led level meters (higher than 10 led per channel resolution can be obtained by cascading the lm3915s)
|
|_ 4311 (same audio signal connected to audio in ports 1…4)
|_ mix audio out 1: fx 1 send
|_ mix audio out 2: fx 2 send
|_ mix audio out 3: fx 3 send
|_ mix audio out 4: master bus send
and then on each mono master bus, use a plain and simple passive audio summer (resistors) configured for the correct number of channels (e.g. 8 mono channels) Edit : as far as I understood now, you do exactly the same… the passive summers are not necessary, if the master bus send signal from above is attenuated enough to allow for simple connection linking. right? if so, that is great, but one might nevertheless use a passive summer to increase resolution, as the attenuation would have to be done using only 8-bit volume controls on every channel… to keep the cost of the control surface down, per stereo channel, one could use (from top to bottom):
an endless encoder for input gain
an endless encoder for stereo panning
three endless encoders for fx1-3 sends
(all endless encoders optional with led rings from a led matrix)
one motorfader for volume control,
buttons for solo and mute.
What do you think? If I by mistake reused any of your ideas, please accept my apologies…
Thanks and bye,
Peter
It’s all good. I don’t want to “take over” your project, but I’ll toss out a few ideas for you to consider.
One of the unusual advantages of my mixer design is the separation of the audio
handling from the controls. This offers a few cool tricks: In a live music application, the
mixer can be placed backstage, and the controls located a long distance away. This gives a
much easier setup, as the “snake” connecting them can be as small as a pair of MIDI cables,
or better, a single CAN cable. This is much better than running all the audio up to the booth to be
mixed and run back down to the stage. It also offers the advantage of allowing multiple points
of control, each one being a hardware device (MB64e?), a software board like my Java XML mixer,
or even a sequencer that might be linked to a bigger system. Of course, all the controls respond
to remote commands so you can see what’s really happening.
There’s a hardware cause too. The PGA update cannot be interrupted, and it already takes just a
bit longer than a MIDI byte time, so I do not recommend using the same Core8 for the PGAs and
a user interface. Things work better if you separate them onto different cores.
Everything mentioned above is already complete. what comes next is one of the things I am working on:
If you want to separate the controls from the mix deck, I suggest a simple integrator circuit on each
channel input, with the resulting analog voltage being read by a PIC and transmitted. this will allow
you to see the levels from any/all of the remote sites. I already wrote the display code into the XML mixer,
and breadboarded a hardware circuit, but have not finished it out yet.
It will create a lot of MIDI traffic. I have been watching MBNet with interest, as CAN is looking better
all the time! (Great for long distance fast comms)
Regarding the 8 bit resolution: MIDI supports 14 bit resolution, though most control surfaces only use
7 bits. There is no reason the whole MBMix program cannot be re-written for 14 bits of control sensitivity
completely in software. The PGA chips support 0.5dB resolution.. and even at 7 bit, the combination
of multiple controls results in a higher res than that.
Let me say again: I don’t want to take over your project. This is a DIY community. I released my code so that
anyone can take it anywhere they want. Oh, re-writing MBMix for Core32 should not be a problem at all, except
that I don’t have a Core32, and I have very little time too. The actual program logic is very simple, and the
math is too. I WILL support anyone who wants to re-write it for the Core32 in C.
I lost a fingertip a few weeks ago, so I have to keep my typing in short spells. (Ouch!) Maybe better after I get all
the stitches out.
Have Fun,
LyleHaze
