DIY audio patchbay with digital routing....How hard?

[Nomical]

WOH!!

I go away for a couple of days and look what happens, 7 pages already! This is crazy  ;D

I could have never guessed that this would spark so much excitement among all of you.

I do see that most of this is way out of my league. You guys are really good at this.

Never crossed my mind this project could become this complex.

Could someone help me out and summarize the current design/concept? There's so much to read. I can hardly understand what the current setup is. What is the design looking like at the moment?

How much I/O's are we talking about? I see people posting numbers like 128x128.. ;D This is the part about scaling, isn't it? What's the current interface idea? I read people wanting a LED matrix, some wanting a display.

I hope these things are still possible in the current design:

- Multiple inputs to one output

- No 'stealing' of inputs: Inputs can be routed to more than one output

- All controls/routing from 1: frontpanel using display, encoders and buttons. 2: USB/RS232 connection to computer

- A mixup of balanced and unbalanced connections

- At least 24x24 would be nice.

It would be possible to use some of the outputs to be fed to amps for headphones on the frontpanel, right? That would be nice, having a digitally controlled audio patchbay that also has headphone ditribution amp capabilities. I've seen some shematics for small headphone amp sections having level control and that's so easy even I can design and build it ;D

How many people would want to control their patchbay from their computer?

How would a connection to a computer be best made? I read a section of that pdf thesis someone linked to and it mentioned that the name's machine had a rs232 connection to a computer. Or should the USB module together with MIOS handle it through some IIC connection to the crosspoint switch matrix IC? Would that graphical interface need to be Java based? The majority of the people are using Windows I guess. I would belong to the minority as I use a Mac (Intel running Leopard) and there are Linux users as well.

How much time does it take for the chip to reload when a crosspoint is changed? A few ms or are we talking about seconds? This should not be of any concern I guess as most people wouldn't do very fast connection switching during live performances and I can't think of any reason for doing so anyway. The only bad thing I can think of is if the chip can only reload one single crosspoint change at a time and this change would take a fairly noticable amount of time.

And how about digital I/O's like SPDIF (RCA, BNC, or preferably TOSLINK)? My guess is that the only problem would be if there was a need for syncing like word clock. Digital outputs from simple player devices like CD/DVD players, MD players etc shouldn't be a problem would it?

Well, it's good to see people are interested in the same thing.

I guess with all that diy building comes a need for more I/O's ;D

Thanks to all the people sharing thoughts and doing some fine work!

[doc]

My concern is that this may all be fruitless if we end up ganging boards together using ribbon (=unshielded) cable.

Just a hint about this:

The DOCmatrix has shielded ribboncables. It's a little bit tricky to pack them into a alu-foil. But it's worth it.

By doing the connections with multiple (shielded) rbbon cables you are saved from doing a three (ore more) layer PCB!

greets

Doc

[/tilted/]

Because we cannot change an individual crosspoint without loading the whole chip or all chips... perhaps it would be good to have a feature where you can set a number of patches before dumping that configuration to the chips? Just a little detail....

The 8113 has the option to do either a full chip dump, or individual crosspoints.

This option is selectable any time, using the (!Serial)/Parallel pin.

- however, it is also a 100pin LQFP.

The 75019 does not have this option.

In any event, as a crosspoint inherently happens only on one chip, we could chose to re-load only that chip, not the whole matrix...

Just a hint about this:

The DOCmatrix has shielded ribboncables. It's a little bit tricky to pack them into a alu-foil. But it's worth it.

By doing the connections with multiple (shielded) rbbon cables you are saved from doing a three (ore more) layer PCB!

Hi Doc.

I meant to get to this earlier, but got swept up a bit...

I hope you don't feel that we are completely re-inventing the wheel/stealing your thunder here.

I feel that where we're at here is perhaps more like a modularisation/ re-visit of your "vicky".

It was certainly no-ones intention to ignore your work.

I only hope I can do it justice. :-\

[Screaming_Rabbit]

It's a little bit tricky to pack them into a alu-foil. But it's worth it.

... shielded Ribbon is available ready made. - I have a whole roll of it... was thrown away at work and I was the first seeing it in the container  :D

Greets, Roger

Edit:

https://www.distrelec.ch/ishopWebFront/catalog/product.do/para/language/is/de/and/shop/is/CH/and/id/is/01/and/node/is/acagadaeaaap/and/series/is/1.html

[doc]

@screaming_rabbit

.. shielded Ribbon is available ready made. - I have a whole roll of it... was thrown away at work and I was the first seeing it in the container  Cheesy

Be glad you have it! I also saw the ready cable. But as I've seen the price, I shielded it by myself...

@/tilted/

I hope you don't feel that we are completely re-inventing the wheel

That was my thought. Not in a way that I felt ignored, or angry  -That's absolutely not the case- but in a more funny way.

If you read the whole thread as a non-involved you wake up thinking:

" Hey! They are talking about constructing a new car ... and someone already drives along with it."

greets

Doc

[stryd_one]

Hi all,

Regarding the similarities and differences between this project and the docmatrix... I have so far spent about 6 hours discussing this with various parties, and need a few more... Please hold off on conversation regarding this, I will report back soon. It is being handled :)

Be assured that I will involve any person as much as possible and as much as they would like to be. IE, we are not cutting doc out of the loop, or stealing any thunder, recreating any wheels, hijacking any projects, etc etc etc.... we will not do any such badstuff, badstuff will not be tolerated, and my decision on that is final. Doc rules, OK?! Good. :)

(Sorry to be a big bad bossy boots, but this is something I really want handled correctly, and too many chefs could spoil the broth.)

I'm at work so must be quick, Tilt and Nomical I'll reply in a few hours.

[doc]

hehe

Be assured that I will involve any person as much as possible and as much as they would like to be. IE, we are not cutting doc out of the loop, or stealing any thunder, recreating any wheels, hijacking any projects, etc etc etc.... we will not do any such badstuff, badstuff will not be tolerated, and my decision on that is final. Doc rules, OK?! Good. Smiley

Funny, how things go.

What shall I do, that noone has the feeling to do something wrong?

It is not worth the discussion. Everything is fine. So go on and let us build a matrix!  ;D

I never felt cut out of the loop. I just wanted to give several hints, how you can manage such a project.

And. The matrix isn't my favourite project at the moment. Several Others are in cue now.

I'll keep on with my suggestions and I also tell you when you run in the wrong direction, ok?

You all rules! OK?!  ;D

greets

Doc

[/tilted/]

I'm at work so must be quick, Tilt and Nomical I'll reply in a few hours.

Jesus Stryd!! The suspense is killing me! You trying to give me a heart attack??  ::)

maybe I need to cut back the caffeine a little bit

[lylehaze]

OK, I'm checking in briefly.

First, a few disclaimers:

I'm already up to my neck in another project.

I am NOT an expert in anything, just a resourceful amateur. :-)

I think this project has a good collection of people much smarter than me already.

That said, ANYONE (or even EVERYONE) should feel free to tell me how wrong I am, or even where to shove my opinion. No problems.

Nomical,

You asked a few questions I'd like to comment on:

1>LED Matrix and/or display:

For my own project, I chose to separate the "real audio handling" from the display and controls, as a great advantage comes from separating them. i.e. Take the controls and display to the mix booth, leave the audio matrix backstage. Saves a LOT of audio cable.

2> Multiple In to one Out. Can be done, but you have no control over the relative levels without some sort of mixer (coming soon!).

3>One in to Multiple out: Certainly do-able, but you'd better have an input buffer to assure a low signal impedance.

4>Controls, local or remote: Minimal local controls OK, but the primary should be remote, see #1 above.

5> Remote connection method: RS232 or USB?? Bah! MIDI is multiplatform, and I know a GREAT little controller called MIDIBox. MIDI can also be sequenced for dynamic changes.

6> Balanced/Unbalanced: Switches are available both ways, but dead-mixing balanced signals is beyond my comfort zone.

Someone in an earlier post suggested transformers to adapt balanced to unbalanced. If we have +- voltages, Op-Amps do much better (and cheaper) than transformers.

6+7> SPDIF/other digital formats: All signals will need to be converted to a common type for switching. Presumably analog, and preferably unbalanced while on-board. ANY type of input and output buffers can be built, but I think the board in it's current direction is going to be an analog switch.

Remember, I'm not driving, just offering my unsolicited opinion. Feel free to tell me to get lost. I'll be watching from the back row, at least until I finish my own project, which might combine nicely with this one.

It looks like fun!

Lyle

P.S.: Respect for all those involved.

[/tilted/]

Hi Lylehaze.

Some really good stuff.

I wonder if it might be a good idea to keep compatable pin headers between these projects, as they would work very well together.

I think especially that combining the FX routing options of the MBMixer would tie in very nicely with a switchpoint matrix such as this. A switchpoint matrix might also be good for dropping in things like channel inserts...

hmmmmmmm.

[lylehaze]

I have been busy trying to make the MBMix board as small as possible, because I'm a cheap bastard. The good news is it is now 4 square inches, but it doesn't offer much for connectors, as they were almost half the board space in the previous design.

I'm using "board stacking" pins for all buss connections, power and audio. (that's cheating, I know)

But what I have that might be useful for this project is the input buffers. I've managed to come up with a "configure at build time" plan that supports balanced, unbalanced, various preamp gain settings. It will even allow addition (off board) of a switch for phantom power, as I'm guessing some people will need that.

If you don't mind taking up a bit more space, These input buffers can have the settings changed later by "plugging in" a new configuration connector (usually just a few resistors on a 6 pin header).

This part of the board is hopefully going to be finalized today. But I can't offer a tested and "proven" design until the boards get back from the fab house. (I use a REALLY SLOW board fabricator, because I'm a cheap bastard, remember?)

Anyway. That's all about my project. I don't want to intrude on this topic, except to offer my own designs if you want to see them. I'll bring a few jpegs home tonight just in case.

Make Beautiful Music,

Lyle

[/tilted/]

My aim at this point is to make the matrix a line-level device, intended to patch signals at +4dBu type levels. Inputs and outputs will be balanced TRS connections. I'm also considering a +6dB gain switch for unbalanced inputs.

[stryd_one]

Jesus Stryd!! The suspense is killing me! You trying to give me a heart attack??  ::)

Sorry man, dramas with work and timezone snafus and the forum outage are killing the lines of communication.. :(

But what I have that might be useful for this project is the input buffers.

Are they similar to the ones doc posted PDF's of? I'm wondering ow these would compare... doc's is all tested OK, but I like the configuration block idea, that makes it quite flexible, which is suitable when we're trying to do an "every-man's" box.

On that note, I'm looking into (as soon as I get time to scratch myself!) supporting either MT88* or AD75019, in a similar fashion to supporting the different aout modules. More to come. Stay tuned, and tilted; stay off the bean, dude

Balancing... I couldn't say it better than these two links do.

http://www.dself.dsl.pipex.com/ampins/balanced/balanced.htm How to do it

http://sound.westhost.com/project87.htm Where to buy it

No intrusion lyle, these things go together like beef and broccoli ;)

[lylehaze]

OK, I have (possibly) finished the channel board, and even scraped up the beginnings of documentation.

Since some here might be interested in how I will try to manage my input buffers, I have posted the current documentation in a zip file, formatted as HTML for the widest audience.

Since it's for another project, I posted it there.

If you'd like to see it, check the latest post in the

MBMixer thread over in user-projects.

If someone knows how to add a link here to that thread, or better yet, a link to the .zip file, please do!

Respect,

LyleHaze

[stryd_one]

After some discussion in another thread, I want to release some info on the redesign. Only the channel board has been done yet, but the changes have been pretty big.

I'm about 90% sure that I'm done with the channel board. Now I need to make a matching master board, and I'll be ready to get started again.

The attached files will describe the options of the board. What it doesn't say much about is the size. This board is now <4 inches by <1 inch. If you get your boards from Sparkfun, it should bill out as 4 square inches. If you get them from Olimex, you should be able to fit 6 of them on a single board.

In the interest of making a document that will read on any computer, I zipped it up as an HTML file. I hope it carries the images properly to everyone.

As always, I'm open for suggestions,

LyleHaze

Attachment

[me=stryd_one]has great news today.... but i must get to work :([/me]

How's the suspense now, tilted? ;D

[/tilted/]

AD75019 layout - done.

AD8113 layout - analog done, digital control - I have questions.

Input buffers - done as a 16 channel, 4xTL074 layout, then re-done as a 16xTL071 layout, which allows for better power  segregation between channels = lower crosstalk.

Output buffers - not done yet.

AD75019 and AD8113 s are fully cascadable in two axes using dual-row 2x8 pin headers.

BAM.

BAM again.

And now the question:

The AD8113 has a serial mode and a parallel mode. I'm thinking the serial mode is what we'd use the most often.

Would we use the parallel mode at all?

I can see it being useful for creating patches, ie one connection at a time, the serial being better for slamming an already built patch in to the chip...

My query is one of MBHP pins to use.

If we use J10, the easiest option is to skip 595s and plug the serial connection straight in there.

But if we use parallel mode, we'll need more pins, so we'd use 595s.

But using 595 pins to spit serial data into a chip is gonna take months!!

Ie, PIC->(Serial to parallel via 595)->(Serial input at AD8113)

Perhaps we could cascade serial data out of the 595 into the AD8113?

Would this limit the number of AD8113s we could chain?

[stryd_one]

BAM.

BAM again.

Bam-a-lam!

Yo I hate to do this to you, but have you scoped out lyle's inputs... Do you reckon we should drag him into an alley and bash him and take them off him? ;D

And now the question:

Would we use the parallel mode at all?

Was wondering who'd bring this up heheh

Would this limit the number of AD8113s we could chain?

Now that I think about it (after writing the rest of the post heh) I don't think this is a good idea... the other pins need to be stable when the data is clocked in, and if you are updating the whole SR each time you set data, that could be real shaky. I think it's one of those 'works in theory' deals ;)

OK news time! Yay! TK and doc have kindly offered up the opportunity to merge these projects together! I think this is the way to go, and I hope you'd all agree :) I had been avoiding this topic, only because I was under the mistaken impression that docmatrix was a private project, and I didn't want to #$@& with it... This is the part where you al point at me and go "derrrr!" :D

I'm really excited by this :D

The idea with this is to have the system maintain compatibility with the docmatrix, and we will add in features to that. We have all talked a lot about the CS ideas we've had - minimal 2-knobs and a few buttons and LCD, LED matrix, GP buttons for quick loading, SYSEX/CC/Note input, patch storage and recall, etc etc. Let's move onto the chips.

Outside of this thread I have gleaned some guruknowledge^tm from some audio dudes I know regarding our selection of chip, and applied my audioknowledge^tm accordingly. There is no denying, that the MT88* series have a lot of advantages over other options - They're cheap, come in 8x8 and 8x16, crosspoints are individually addressed in a manner which is VERY easy to write to, and they have better crosstalk specs, which we all agreed could be important in CV routing applications.

However the distortion figures are high, and that is a knockout blow for some projects, leading to the AD75019. These two chips compare the way they do for good reason - the Zarlink is intended for telephony systems, and you don't want people overhearing neighbouring phonecalls, so crosstalk is critical - but frequency content is not so important, whereas the AD is made for analog audio routing in studio or equipment's internal routings, so the distortion is low as heck, but that comes at the expense of slightly higher crosstalk figures. The catch is, they use a very different method of loading the crosspoints, specifically that the whole chip (or all chips) must be loaded at once.

The good news about this, is that if we are going to implement patch storage, then the whole matrix state will have to be stored anyway, so I'm sure we can use this to ensure the ability to use either chip (no mixing chips) with the same CS.

As for the 8113... because the whole matrix state will have to be stored anyway, it should be possible to support it in serial mode and parallel ... It's a tough call as to how though - I mean it's really the everything chip, having both parallel and serial modes, and the best crosstalk and distortion specs of all, so it'd be nice (especially if some idiot like me wanted to route CV and audio)... however I'm not sure how practical it would be to allow both serial and parallel programming simultaneously.

Let's see:

8113:

Parallel: Address, data, CS

Serial: Sclk, SD, strobe, CS

75019:

Serial: Sclk, SD, strobe, CS

8816:

Parallel: Address, data, CS

So, it looks like it should be easy right? but how do we tell the app when to write what? It looks like we'll need to have a driver for each IC, which contains two functions for each chip, for EG SetCrossPoint(X,Y,State) and DumpStates() ..... regardless of whether the chip supports it. Then, the driver can handle the incoming data appropriately:

8113:

SetCrossPoint: Set the specified switch

DumpStates: Dump the whole matrix

75019:

SetCrossPoint: Ignore the switch specified, and dump the whole matrix

DumpStates: Dump the whole matrix

8816:

SetCrossPoint: Set the specified switch

DumpStates: Read the individual crosspoints from the stored Preset and set them all one at a time.

This means that the drivers will need to hook back into the patch storage and/or editing buffer data, and data regarding the physical configuration of the device (how many chips in what arrangement, for calculating chip enable lines and arranging serial data correctly)... I can't see any problem with this but a nagging feeling in the back of my head tells me that this might be bad programming practice... Anyone see any problems there?

Well that takes care of the logical side of it, then it just comes down to wiring it... and that's where it gets tricky, as you've noticed. I think that the easiest way to deal with this, is either 75019 directly in serial mode, or 595's talking to 88* or 8113 in parallel mode, can use J10, and to use another pin, like say J7, for the 8113 serial data - the enable lines can be driven from the 595's as they are in parallel mode.

This of course means that we lose motorfaders, and they could be useful... but so far nobody has piped up about them, so I think we could safely drop that.... If someone really wants to have the *does everything* box, then maybe they'll have a better idea (like using J5 or LCD pins)...  But I think this covers it all off?

If you read this far, I'm surprised! :D

[doc]

If you read this far, I'm surprised! Cheesy

I read it so far ;D

This of course means that we lose motorfaders, and they could be useful... but so far nobody has piped up about them, so I think we could safely drop that.... If someone really wants to have the *does everything* box, then maybe they'll have a better idea (like using J5 or LCD pins)...  But I think this covers it all off?

Motorfader? You're joking. If someone wants his matrix with MF he should build another box. Not every project must handle every option. I think there isn't a mf-section in the MIDIO128, also. So go one without mf! :)

greets

Doc

[stryd_one]

Motorfader? You're joking. If someone wants his matrix with MF he should build another box. Not every project must handle every option. I think there isn't a mf-section in the MIDIO128, also. So go one without mf! :)

Yeh that's basically what I thought :D

Thanks again doc, it's really cool of you guys to offer up this excellent work for us to build on. I hope you'll beta test the patch storage when we do that, it'll have to be done first ;)

[moogah]

Holy crap!

I totally give up on trying to catch up on everything that has been said here.. so I'll just add my .02 in, fully aware that it has probably all been mentioned in the last three pages somewhere:

- I've been pondering just such an idea for about 2 years now

- AD75019 and 8113 are the chips of choice

- 8113's are really damn expensive

- Digikey keeps the 75019 in stock (and I have 4 already ;D )

- Somewhere at home I have a simple layout for the 75019, but it seems tilted has made that obsolete :)  8)

- +1 to everything stryd has said so far (all that I read anyway), I need some massive patching capability!

- Some form of integration with Lyle's mixer would be great :)

So, in summary: you guys are freekin awesome and I'm waay late to the party!

[/tilted/]

MFs- negatory.

I say if someone wants to put motorfaders and a switchpoint matrix in the same box, they can add another core.

-they'd probably need to anyway.

For mixed serial/parallel control, we just need to hold on to as many free pins as we can muster.

[doc]

Thanks again doc, it's really cool of you guys to offer up this excellent work for us to build on. I hope you'll beta test the patch storage when we do that, it'll have to be done first Wink

LOL. If I'll find someday the carton with the matrix in (and if my workspace is cleaned up...), I'll do all tests for you!  ;D

greets

Doc

[stryd_one]

Thanks doc!

moog: Yeh I remember talking about this with you in the past... I've been keeping your needs in mind ;)

tilt: I think that the only pins we really have free, are the AIN and MF jumpers... everything else is used. Never enough IO hehehe

all: Who wants to be a guinea pig beta tester alpha tester/developer/designer/whatever? I need to start thinking about how many chips to get and boards to have made... Unfortunately you'll need to buy your own parts, I'd love to shout you but... Damned taxes :(

I think that this has reached a stage where we will take it off the forum until there is more news, does that sound about right guys? I think we've planned enough ...

[/tilted/]

I think that this has reached a stage where we will take it off the forum until there is more news, does that sound about right guys? I think we've planned enough ...

Now here's a little subject I've been wondering about.

Is there a less-than-official chat somewhere?

[Screaming_Rabbit]

Is there a less-than-official chat somewhere?

... how about an E-Mail list which is always handled with "Answer All"?

all: Who wants to be a guinea pig beta tester alpha tester/developer/designer/whatever?

... I have an AudioPrecision System2 at work if needed

Greets, Roger