Jump to content

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


Nomical

Recommended Posts

Damn!

I look away for a minute and you guys take off running.

It looks like great fun, but already well beyond what I need. No harm in that though, I'll continue to cheer you on from the sidelines.

I did notice one thing from a previous post:

The Midibox Mixer is really using NE5532 op amps. I find them to be very clean and quiet.

As mentioned before, most op amps are pin compatible, so it's up to the individual builder. I might have even used a different part for the eagle files, but the pinout is the same.

Unless you want some REAL preamps. Then you'll need to change the pinouts over for some 12AX7s. Oh, and some power supply changes too. :-)

Yeah, it's meant as a joke, but I have already been asked if I can adapt the MBMixer to replace the front end of a Fender Amp Head. You never know what the next guy will try to do with it. :-)

LyleHaze

Link to comment
Share on other sites

  • Replies 215
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Isn't this a typical usecase for an encoder?? The selection can also be done "single-handed" if you use a push-button encoder.

Best regards, ilmenator

... if space and money is an issue, yes. When it comes to handyness and usability, no. The big advantage is, that you can label the snapshots (like on conventional Bantam PatchBays or with some 40x2 CLCDs) and pressing a dedicated button is the quickest and most intuitive access.

Let's face it: Who needs more than a few presets/snaps (I'm talking about a central Broadcast Router)? If it is for me, I would need about 2 or 3 Snaps and the rest would be direct and individual patching.

Perhaps you could think of a good way to make the LED matrix scalable, IE 'pages' of LEDs, we'd need up/down/left/right buttons, and some way of showing where we are now, or something...

... if it would be technically possible (multiplexing), I would prefer one big matrix. I want to see what's going on with one sight, no matter +/- $200 or taking 5 to 6 HE rack space, otherwise I'm quicker with good old patch cords.

Greets, Roger

Link to comment
Share on other sites

Was just thinking about the UI:

I think the system should be built distributed and the RouterCore is just reacting to MIDI messages which are defined from the development team.

E.g. there is a predefined controller message to select and load Snap1. or one to connect source1 to target2

There would be no button handling implemented into the RouterCore application.

The MidiBoxers building such a router can create an additional MIOS-Core with the Midio128 application and their own design/implementation for the UI. Now if they want to load snap1, they just have to send Controller xy "127" to the MIDI-In of the RouterCore and "snap1" gets loaded and executed, no matter how they made their MIDIO128 to send the message.

In the aaplication of the RouterCore, we just would implenet the rules and handling. Like for source/target routing:

e.g. connect "sourceX" to "targetY", the receved messages from the controllerUI would have to be like:

- ControllerY "127"

- ControllerX "127"

#if ControllerY receives "0" before ControllerX received "127", no connection is executed

#-> existing connection of target gets overwritten (disconnected)

#-> Connection established

#-> LED XY "127" (gets sent back to the controller(s)

- ControllerX "0"

- ControllerY "0"

Greets, Roger

Edit1:

Just trying to be creative :P... One could build the RouterCore, build into the same RackCase a MIDIBoxMerger and e.g. a MIDIO128 with an encoder/button style UI (illmenator) and on the 2nd "In" of his Merger he connects another UI which is placed on his MidiBoxLC surface. The feedback (Crosspoint-LEDs) are distributed from the RouterCore to both ControllerCores over MidiThru.

Edit2:

This way a MidiBoxer even could control the Router with a Japanese wireless ToiletRemoteControl  ;D ;D ;D

Wireless_toilet_control_panel_w._open_lid.jpg

Edit3: Corrected Typos

(... and LMO 1st about of having those new MTE-buttons on my surface, 2nd about thinking of sitting on this toilet in Japan and pressing one button after another while being scared that I could get my face flushed next  ;D )

Link to comment
Share on other sites

Damn!

I look away for a minute and you guys take off running.

It looks like great fun, but already well beyond what I need.

No sweat bud, it's supposed to scale up AND down :) Tell us what you need, I'm sure it can be done. I'm really keen that noone be left out on this (unless they want something wayyyy different, which I haven't thought of yet), and besides, the practical difference between a big 128X128 array with encoders and LCD and a remote led array, and a simple 16x16 with no CS controlled by midi and built into a synth, is not so big :)

The Midibox Mixer is really using NE5532 op amps.

Rad, I have a couple tubes of them :)

Yeah, it's meant as a joke, but I have already been asked if I can adapt the MBMixer to replace the front end of a Fender Amp Head. You never know what the next guy will try to do with it. :-)

I must admit I did think about strapping one to the back of each of my 8 channel vale pre's... Heh  :-[

Link to comment
Share on other sites

So the interface with the 75019 looks to be a doddle.

I've as good as done the layout for that. I do need to know...

This sucker would connect to J10 on the core, right? Thus leaving J8/J9 free for UI stuff?

The interface to this chip is very simple hardware-wise.

SCLK - Sync for upload of switchpoint data in serial form.

SIN - The input pin for aforementioned switchpoint data.

SOUT - Output pin (allows for cascading of chips- nice!)

PCLK - Tells chip that all switchpoints are loaded into serial buffer.

This all reads as very similar to the way a 595 works.

So my thinking is:

SCLK - SC

SIN -  SO

SOUT - to cascade output...

PCLK - RC

Any problems?

Link to comment
Share on other sites

Roger: sysex/CC/note control implementation is a MUST in my opinion, but I don't think it need to be a separate controller... It should be possible, but also, reading existing connections from a preset (For EG to light the LEDs when loading a saved preset) could be very slow over midi. I'll try and get it all into one box, allowing the option of an external controller.

... no hurry for the LED feedback. Normally when you load a preset, you know what you're doing/patching. I wouldn't care if the LED Matrix hat a few seconds to be built up completely. Even thought that the whole matrix always has to be updated, when a Snap gets loaded)

Link to comment
Share on other sites

but I don't think it need to be a separate controller... It should be possible, ...(Edited)  I'll try and get it all into one box, allowing the option of an external controller.

... I don't think it's not possible. My suggestion was more to save energy discussing the "real"-problems than how to hadle/design the UI. A few bucks more for an additional core is not much compared what the whole routing chips will cost.

Link to comment
Share on other sites

This all reads as very similar to the way a 595 works.

So my thinking is:

SCLK - SC

SIN - SO

SOUT - to cascade output...

PCLK - RC

Any problems?

Exactly. It's just like a 595 :)

The tricky part about the layout is the grounding - I'm no guru on this as we know but I do know that you want to keep analog ground wires and traces physically inbetween the analog signals, and digital ground should be separated, and you want a big analog ground plane... As well as avoiding sharp corners on the traces etc. I think you were around in the chat when we discussed that?

I highly recommend reading the AD8113 datasheet for the lowdown on all this, there's a whole section dedicated to it with several pages of "Do's and Don'ts ".

As for the CS stuff maybe it would make sense for me to use the 4685 so we have the option of using MBnet. Doc has clearly demonstrated that an external CS is possible without it though ;) But some other more processing intensive CS suggestions have been made whech would probably need a separate core.

My suggestion was more to save energy discussing the "real"-problems than how to hadle/design the UI.

I agree. Fortunately as tilt has said the interfacing to the chips is a bit of a walk in the park really, and it won't be the first time I've written a driver for something like this, so the real problems are not so big... but I don't want to get too distracted with the CS. Supporting a basic 2-encoder+LCD interface and a LED matrix should be fairly straightforward, and I'm cool with refining the details a bit, but I don't want to get too deep into it just yet. Gotta keep focussed :)

Edit just for your info - the very first working build of this will likely be a CS-less core with CC's to select the IO and a note to engage it. After that I'll put sysex and encoders/buttons in place for the same, then the LED matrix.

Roger - out of interest, how big do you want your LED matrix?

Link to comment
Share on other sites

I think I can get by on 128x128, which works out to 8x8=64 chips, about 1400 in chips if it's AD, or 1000 if it's zarlink .... So believe me, I'm price-focussed right now Wink But I would hate to spend a grand and be disappointed.

Well, if you use the transistor crosspoint solution, it'll only cost you $250 worth of transistors and $160 worth of resistors.

There are just 16384 transistors and 32768 resistors to solder that way  ;D

(I wonder how much it would cost to get this board built with automatic PCB assembly, it wouldn't be too long though, there are machines that place 13k components per hour.

Link to comment
Share on other sites

Hi guys,

I've been following the discussion a bit and one question comes to my mind:

Did you somehow all not realize that Doc has built and already partly documented a finished and working 24x24 matrix with detachable control panel etc, or is there some reason for your (non-)reaction that I didn't see yet like he used the wrong ICs to make you happy or something else? I mean, the usual reaction to his post would be something like "Wow, fantastic work, I absolutely wanna build that, too", but instead of the enthusiasm that would be the natural answer to such a publication IMO, it seems you're all kinda ignoring his work and trying to reinvent the wheel??? Please enlighten me :)

S

Link to comment
Share on other sites

... and you want a big analog ground plane...

I lately was just discussing this with one of our guys who was designing the stuff in our good old analog times. He said that compared to the digital PCB designs, in analog you don't want ground planes, because of building up capacity.

Roger - out of interest, how big do you want your LED matrix?

I was thinking about 1024 (32 X 32). It's enough, since I do most of my studio routing directly on the 2 RME MADI cards and the D21m Interface.

d21m_series.gif

So I would use two MIDIBox Matrices:

- 1 for selecting monitoring sources 16 X 16

- 1 for my Guitar rig 32 X 32

Greets, Roger

Link to comment
Share on other sites

Well, if you use the transistor crosspoint solution, it'll only cost you $250 worth of transistors and $160 worth of transistors.

There are just 16384 transistors and 32768 resistors to solder that way  ;D

LOL. Yeh and a whoooole bunch of design concerns that would leave me totally out in the dark... I'm sure you could use IC's with multiple transistors and make the job easier but yeh.... Unless you know how to do it, I think that one might go in the too-hard basket ;)

said that compared to the digital PCB designs, in analog you don't want ground planes, because of building up capacity.

Yeh I always thought It would act like a big antenna but I don't know sh*t from chocolate on this stuff ;) Anyway it's all in that PDF, I'll leave it to the pro's at AD to explain it before I start looking (more) stupid heheh

Did you somehow all not realize ..... the usual reaction to his post would be something like "Wow, fantastic work, I absolutely wanna build that, too"

Totally! I bugged out on him in the chat room, I guess my enthusiasm would have shown a lot more at that time :) In fact I think I blew him a smiley kiss (that's like a double disgust for poor bugfight too) after lots of yelling and excitement.

it seems you're all kinda ignoring his work and trying to reinvent the wheel??? Please enlighten me :)

Yeh I can see how it would seem that way, but that's not the intention at all - it's not so much that we are ignoring his work, not at all, in fact I believe that final credit in our device should be shared with him because he has been kind enough to furnish us with some healthy advice, and schems for things we did not have like the buffers and PSU too. Although tilt is re-doing them, I'm sure that he (like me) will be referring to them as a guide. But as you can see from the thread, the design we have now is one that has evolved through a discussion aimed at meeting everyone's specification, so it was heading in a certain direction as a result.... By the time we knew enough about the docmatrix, it already had momentum, and we're just following that momentum. Myself, not speaking for anyone else, I would prefer to use the AD chips, so I probably would have kept along this path even if I had known of the docmatrix, but if someone else would be happy with doc's design then I think they should build it, cause it's excellent!!

It's like...when I heard a really cool tune that MTE sent me the other day, I didn't stop making my hiphop track because his trance song was so cool... I thought it was great, but I was doing my own thing... but that's no disrespect to MTE's tune :)

Link to comment
Share on other sites

Bunsen: Sure, but there's already a "midibox router" (for midi), so I've created http://www.midibox.org/dokuwiki/midibox_audiomatrix

tilt: Exactly. I don't know what's involved in the whole >2 layer board thing when it comes to having PCBs made up :-\

I always wondered though, if you look at it from the edge of the board (side on) they are suggesting this:

G  G  G  G  G 

G  #  G  #  G 

G  G  G  G  G 

Where G is a ground and # is the signal...Would this:

G  G  G  G  G 

G  #  G  #  G 

Be just as effective?

Analog gurus....?

Link to comment
Share on other sites

I always wondered though, if you look at it from the edge of the board (side on) they are suggesting this:

G  G  G  G  G 

G  #  G  #  G 

G  G  G  G  G 

Where G is a ground and # is the signal...

Exactly.

Would this:

G  G  G  G  G 

G  #  G  #  G 

Be just as effective?

Analog gurus....?

By definition, less effective.

They are basically discussing turning your board into a shielded device.

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

On the other hand, is all this a little overkill if the whole deal is to be mounted in a heavy steel box, connected to earth?

Or would something in between be better, to take a leaf out of the RF world. Perhaps we could go for your example 2, with signal traces on board top, ground plane on board bottom, ground traces between each signal trace, and an Al lid mounted on top (a la the RF box in the C64, to use a common example)

Edit:

PS, re the ground plane argument...

there are two basic design concepts to be taken into consideration here.

1) the ground as a sheild.

2) the ground as a 0V reference, as the "return" for an unbalanced signal.

in the former, you want the ground to surround the sensitive areas of your circuit, and to be connected only where needed, ideally in one location only, or the minimun number of locations.

in the latter, you want to avoid ground planes, as these are the opposite of the ideal, which is a star sheild arrangement.

Link to comment
Share on other sites

By definition, less effective....

I guessed as much ;)

They are basically discussing turning your board into a shielded device....

On the other hand, is all this a little overkill if the whole deal is to be mounted in a heavy steel box, connected to earth?

Or would something in between be better....an Al lid mounted on top (a la the RF box in the C64, to use a common example)

Well I think you're thinking about shielding from external RF interference, where this design note is about minimising crosstalk, IE neighbouring signals effecting each other. I could be wrong about this (me analognoob, remember that) but I think the effect is somewhat like a transformer, where the signals create an electromagnetic field, and if they neighbour another signal wire, then the EM field effects the flow through the other trace...

I also wonder if this is a "soft spot" where it will introduce problems only where the cable is, or if it's a "weakest link" situation where having this one flaw will compromise the whole circuit in general... My guessi si the former, but .... That's MY guess, which is a bout as useful as tits on a bull.

I'll come back to that...

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

Well when you use the ribbon cable you should have the cores going G # G # G # etc  so that the signal wires always have a ground separating them. But yeh, if that's good enough, then I'm sure that two layers on the PCB would match it. I guess we could always use something different for the interconnects like CAT5/5e/6. I'm guessing I'm about the only one with a CAT6 crimper around here ;) (and CAT* isn't insulated between the cores, just around them) What's common, cheap, and shielded, and has more than 8 cores?

Coming back to the EM crosstalk... I can't help but think that, in conjunction with as much electronic shielding as possible, physical separation of the traces and cables might be enough, it's not like it's super high current running through those wires. The AD8113 does have much smaller pins and could be placed an a much smaller PCB with thinner, closer traces than ours. If we have the traces radiating from the 75019 outwards in a 'star', then they'll quickly reach a point where there's a lot of PCB between them. Likewise we could further isolate them in the ribbon cable like: G # G G # G G # G etc....

Thing is, that the benefits of such a methodology may be great, or just plain not worth the effort... As far as I can see the only real way to know, is to get the PCB's made up and try them, but that's the kind of luxury that commercial operations can afford, not I ;) So the next best thing is someone who is savvy with analog audio design who can tell us what's up... And someone who fits that bill, and will also understand that this is a DIY project and we don't want to go totally boutique (IE, we are willing to make minor sacrifices in order to keep the project realistic) ...I dunno where to find that person :( I probably already know the person, but don't realise it! heheheh

Link to comment
Share on other sites

PS, re the ground plane argument...

there are two basic design concepts to be taken into consideration here.

1) the ground as a sheild.

2) the ground as a 0V reference, as the "return" for an unbalanced signal.

in the former, you want the ground to surround the sensitive areas of your circuit, and to be connected only where needed, ideally in one location only, or the minimun number of locations.

in the latter, you want to avoid ground planes, as these are the opposite of the ideal, which is a star sheild arrangement.

Yeh, I never can figure out which one of those is right!

3 Parasitic capacitive coupling There's our problem.... Looks like I do have half a clue after all ;)

Link to comment
Share on other sites

Just bumping this:

Damn!

I look away for a minute and you guys take off running.

It looks like great fun, but already well beyond what I need.

No sweat bud, it's supposed to scale up AND down :) Tell us what you need, I'm sure it can be done. I'm really keen that noone be left out

Come back Lyle! ;)

Link to comment
Share on other sites

Oh.... something I keep thinking of which I should mention:

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....

I've been discussing details of this project with some guys tonight and will report back when the details are finalised.... Need to talk with one more VIP first ;)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...