MT8816 based effects router

[chuck]

I just thought I'd show you all a guitar effects router I've been working on some.

It uses the MT8816 matrix switch to build patches of guitar effects in any order.

As you can see it has a SmashTV core module and a DIN and DOUT module.  So it pertains here.

This is a work in progress.  This is for my use, its not for sale.  But you can build your own.

[bugfight]

way cool.  been wanting to see someone try this.

[cimo]

;D ;D this stuff will let set patches and combinations of inputs and outputs (in you case guitar effects) and also can be controlled via midi and therefore sequenced and synced , am i right?

xcool nice one!

simone

[DrBunsen]

Will you be documenting this on the wiki?

[chuck]

Yes, but it will be the next version.

I wouldn't recommend building this one.

It uses serial based logic to control the MT8816.

The next version uses a parallel control bus and two MT8816 chips to handle 15 audio inputs and outputs pairs.

You can see the design talk in this thread here.

http://www.diystompboxes.com/smfforum/index.php?topic=43104.40

I wanted to finish this one though because I'm learning the best way to fit it all in a 1RU case.

[Sasha]

This is very interesting and useful project! I will wait for next version than.  :) Thank you.

What kind of connectors are those. 6.3mm Jacks? Looks strange from behind.

[gavgomad]

Hey Chuck! This project looks fantastic! I hope you'll share the details when it's "street-ready"!

Silly question, as I'm new to routers....

Is it possible to route more than one source to a single destination (ie. summing sources)?

Keep up the great work, Chuck, and keep us posted!!

Gav

[cimo]

!BUMP! (thanks flo)

[chuck]

Hey Chuck! This project looks fantastic! I hope you'll share the details when it's "street-ready"!

Silly question, as I'm new to routers....

Is it possible to route more than one source to a single destination (ie. summing sources)?

Keep up the great work, Chuck, and keep us posted!!

Gav

Sorry, the project is on hold as I exceeded the memory in the Pic.....  I'm considering options.

In the meantime I've been working on a Pico Compressor.

But yes, you can use it as a mixer.  Many to one,  one to many, any input to any output.

It is a full matrix.

[chuck]

By the way, a good cheap source for the Matrix chips is here.

http://www.futurlec.com/ICSFZarlink.shtml

[Sasha]

Sorry, the project is on hold as I exceeded the memory in the Pic.....  I'm considering options.

In the meantime I've been working on a Pico Compressor.

So what are the options/plans?

Tell us more about compressor too, please.

[flo]

Using the MT8816 switch matrix chip is very interesting. I have been looking at it for a while already.

Did you need an (opamp) buffer for every input and output or was that not needed?

How did you experience the cross-talk and harmonic distortion of that chip?

Any troubles in separating the digital part steering the switches and the analog signals going through the switches, any noise or digital "bleed-trough"?

Perhaps, if you are willing, you can already post the hardware circuit part of interfacing the MT8816 chip with the MidiBox core and some code snippets for addressing / programming it?

I would be interested in it in order to build or try-out a (much) reduced / simplified 8x8 matrix version of it with a very primitive (if any) user interface. It would make a nice variant on a 8 looper version with relais that I'm trying to build using the MidiBox.

[flo]

Not trying to steal the thread (please lets continue about the MT8816 and the MidiBox!), but I'm building on that Pico compressor too (well, I've just received the stereo and mono kits...). Some information I gathered on the Pico Compressor:

http://www.picocompressor.com/PicoComp/PCB-Kits/Documents/PicoComp_Document_Index.htm

http://www.picocompressor.com/picocomp/PCB-Kits/index.htm

http://www.ka-electronics.com/forum/php/viewforum.php?f=1

http://www.diystompboxes.com/smfforum/index.php?topic=68031.0

[chuck]

Using the MT8816 switch matrix chip is very interesting. I have been looking at it for a while already.

Did you need an (opamp) buffer for every input and output or was that not needed?

How did you experience the cross-talk and harmonic distortion of that chip?

Any troubles in separating the digital part steering the switches and the analog signals going through the switches, any noise or digital "bleed-trough"?

Perhaps, if you are willing, you can already post the hardware circuit part of interfacing the MT8816 chip with the MidiBox core and some code snippets for addressing / programming it?

I would be interested in it in order to build or try-out a (much) reduced / simplified 8x8 matrix version of it with a very primitive (if any) user interface. It would make a nice variant on a 8 looper version with relais that I'm trying to build using the MidiBox.

First I made a simple router, using a MT8816 and only 4 jacks.

http://www.voodooengineering.com/release/lab1.jpg

I didn't get any crosstalk, not even a pop or anything when switching.

So I decided not to use any OPAMPs.

But I never went to a full scale 8 in/8 out test.

Here is the schematic for the one pictured.

http://www.voodooengineering.com/switcher/Effects%20Router%20v01r.jpg

It is actually very simple.

I used 74HC595 shift registers to switch the MT8816, and connected them just like the DOUT module.

This was a mistake, I should have interfaced the 8816 better to the PIC, but I afraid of having to write a driver since I don't know assembler well enough to do so.  It really needs a parallel interface because the commands needed for the "serial control" just get too long.

Options?

The best is to redesign how the Pic controls the MT8816.

Now that I'm building a Pico, I'd also probably try a -15v reference voltage.  This current design is using -5v.

As for the Pico, we should start another thread on that.  I was going to try and control it with digital pots/ L2C interface.....  I'm still collecting parts.

[flo]

MT8816 based effects router

http://www.midibox.org/forum/index.php/topic,10247.0.html

-------------------

Re: MT8816 based effects router

http://www.midibox.org/forum/index.php/topic,10247.msg94551.html#msg94551

Long post ahead (sorry):

Although I'm just learning this particular uController, I got the impression that one can control the various ports on the PIC using "C", no need for ASM. Check this:

http://www.midibox.org/forum/index.php/topic,11705.msg94362.html#msg94362

Perhaps that lowers the threshold for you to rework this project.

So controlling the MT8816 with a parallel port would be better?

We could for instance use:

- J15 of the midi-box (although it is also to be used for the LCD) or

- J5

- 7 pins for addressing one switch.

    This could be:

    LATB pin [0, 6] (output latch B) = [J15:D0, J15:D6]

    or

    LATA pin [0, 3] & RA5 & LATE pin [0, 2] (output latch A & latch E) = [J5:A0, J5:A6].

- 1 pin for: DATA.

    This could be:

    LATB pin 7 (output latch B) = J5:D7

    or

    LATE pin 2 (output latch E) = J5:A7

- 1 pin for: STROBE.

    This could be:

    LATD pin 7 (output latch D) = J5:E

    or

    LATC pin 0 (output latch C) = J6:RC / J7RC

- Perhaps 1 pin for CS when using multiple MT8816 chips. When only using one, just keep it active (HIGH).

- Perhaps 1 pin for RESET although I think that one is not needed, just keep it inactive (LOW).

Then, for instance, setup one switch in the switch matrix with one C function and two input arguments, that does:

/////////////////////////////////////////////////////////////////////////////

// SetSwitch

// Enables or disables one switch in the MT8816 switch matrix. (pseudo-code)

//

// byte switchAddress [in] Address of the switch to set: [0, 127].

// bool  enable        [in] Enable (true) or disable (false) the switch.

/////////////////////////////////////////////////////////////////////////////

void SetSwitch( byte switchAddress, bool enable )

{

  /////////////

  // Init: Has to be done only once so move this to a more appropriate function like:

  //  void Init(void) __wparam.

  // Assume using J15 => LATB & LATD.LATD7

  // Set the whole port as an output:

  TRISB = 0;

  TRISD.TRISD7 = 0;

  // Select the MT8816 chip (if needed):

  // MT8816.CS = 1;

  // Deactivate RESET (if needed):

  // MT8816.RESET = 0;

  // End Init

  /////////////

  // Set STROBE to LOW (just to be sure):

  // MT8816.STROBE = 0;

  LATD.LATD7 = 0;

  // Address the switch:

  // MT8816.SWITCH = switchAddress;

  LATB = switchAddress;

  // Enable / disable the switch:

  // MT8816.DATA = enable;

  LATB.LATB7 = enable;

 

  // Stobe the switch data:

  // Set STROBE to HIGH:

  // MT8816.STROBE = 1;

  LATD.LATD7 = 1;

  // Set STROBE to LOW:

  // MT8816.STROBE = 0;

  LATD.LATD7 = 0;

}

Memory usage:

PIC18F4620:

Flash (bytes) = 64K

# Single-Word Instructions  = 32768

SRAM (bytes) = 3986

EEPROM (bytes) = 1024

Is the SRAM the available data memory for an application (I'm not sure yet)? I'll just assume it is for now.

One switch matrix "patch" (=how all 127 switches are setup) needs:

8 * 16  = 128 bits = 16 bytes

The position of the bit "tells" us for which switch needs to be enabled/disabled.

So we can store lots (>200) patches.

/////////////////////////////////////////////////////////////////////////////

// SetPatch

// Setup all 127 switches in the MT8816 switch matrix. (pseudo-code)

//

// double byte patchData [in] The states for all 128 switches. 

/////////////////////////////////////////////////////////////////////////////

void SetPatch( double byte patchData )

{

  // Iterate over all 128 switches and set each switch:

  for( byte switchAdress = 0; switchAdress < 128; switchAdress = switchAdress + 1  )

  {

    // Set one switch of the patch: 

    bool enable = patchData.switchAddress;

    SetSwitch( switchAddress, enable );

  }

}

Now, I haven't touched the "user interface" yet...

[stryd_one]

Take a look at the module skeleton on SVN, and the application development section on the wiki for more answers. If you take a look at the asm files in the output you can see how the ASM for that looks, should give you a hint... But yeh, the C interface will work fine.

You could use the LCD's RW line for the strobe and the RS line for data pins, and use extra pins for CS lines, for best flexibility.

There's a few things in that code that won't work in SDCC I might as well mention now: there's no bool type, and you can't declare counter vars in the for statement.

That said, I don't see what's so bad about using serial control? should be only 1-2 milliseconds of latency at worst, between pressing the button and flipping the switch...

...and, this is exactly what we're doing in that other thread that you said was too complex hehehe... why not join the party? :)

[flo]

> that code that won't work in SDCC I might as well mention now: there's no bool type, and you can't declare counter vars in the for statement.

Yes, it was just a bit of pseudo code doodling. Did not mean to confuse anyone by it. I'm a C++ programmer and haven't programmed ASM or C in 15 years, so I still got to get the hang of the SDCC syntax and data types.

SDCC is basically just ANSI-C, right? So, is the following correct?

Data-types:

http://www.nextdawn.nl/c-reference/data-types-declaration.php

Functions etc:

http://www.nextdawn.nl/c-reference/program-structure-and-functions.php

http://www.nextdawn.nl/c-reference/flow-of-control.php

I guess the "j5_io" module is also very appropriate for parallel control via J5 (I just found it...):

http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fmodules%2Fj5_io%2F

> I don't see what's so bad about using serial control?

Indeed, I also have no problems with a serial control via DOUT or something like that. I think that if one writes a few handy helper functions, controlling the MT8816 either serial or parallel is just as easy or "long". I was reacting to what chuck posted about his reservations on it:

http://www.midibox.org/forum/index.php/topic,10247.msg94497.html#msg94497

"I used 74HC595 shift registers to switch the MT8816, and connected them just like the DOUT module.

This was a mistake, I should have interfaced the 8816 better to the PIC, but I afraid of having to write a driver since I don't know assembler well enough to do so.  It really needs a parallel interface because the commands needed for the "serial control" just get too long."

@Chuck: Perhaps, if you don't mind, you can explain your reservations on the serial control some more?

> this is exactly what we're doing in that other thread that you said was too complex hehehe... why not join the party?

Ah, ok I'll take another look at it. I guess you mean:

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

http://www.midibox.org/forum/index.php/topic,11262.0.html

[stryd_one]

SDCC is basically just ANSI-C, right?

It has a few differences, have a look at the manual, there's a section on compliance.

I guess the "j5_io" module is also very appropriate for parallel control via J5

Well yes and no... J5 is spread across two IO ports (A and E) so it's not the greatest for that. As soon as I get a fix from the SDCC guys for inline functions, I'll be releasing the driver, schematic and PCB layout for an extension that shares the LCD like I mentioned, you could maybe use that as a reference... should be a few days away.

You got the right thread. If you're thinking about writing a mios driver then we can make that app compatible with the driver. It'd be great to be able to use it in both hardware designs :)

[flo]

Sorry for being slow but:

> "J5 is spread across two IO ports (A and E) so it's not the greatest for that."

I do find J5 a bit messy but I thought the "j5_io" module was written to hide that complexity?

You prefer to share the J15 jumper between LCD and other hardware like a MT8816 extension?

When you say "mios driver" does that mean a bunch of functions that can be used in a MIOS program to control the MT8816 chip?

> "then we can make that app compatible with the driver."

Sorry, I don't understand exactly what is meant by "app" compared to "driver", both sound like software. What is the distinction between the two in this case?

Does that mean trying to get a MT8816 extension working via the J15 shared usage solution that you are developing?

> "It'd be great to be able to use it in both hardware designs"

You mean using the software developed by you for the shared usage of J15, with both the AD75019 and MT8816 hardware extensions?

Thanks for being patient...  :)

[stryd_one]

> "J5 is spread across two IO ports (A and E) so it's not the greatest for that."

I do find J5 a bit messy but I thought the "j5_io" module was written to hide that complexity?

It hides it, sorta, but it's still there, slowing things down a little. Kinda depends on the application, but for 8bit parralel communications, it's naturally best to use an 8bit port :)

When you say "mios driver" does that mean a bunch of functions that can be used in a MIOS program to control the MT8816 chip?

That's right. You can see examples of it in the SVN modules/ directory. For example, we could provide something like

void MATRIX_SetXPoint(Unsigned char row, unsigned char column);

In all of the drivers for crosspoint switches, so that the app only has to make this function call, and whichever driver is included (easily configured at the makefile) takes care of the rest of the concerns with flipping the switch. This is a simplified example but I hope it gives you the idea.

Does that mean trying to get a MT8816 extension working via the J15 shared usage solution that you are developing?

The only trick with that, is making sure the pins are handled correctly so as not to mess with the LCD. The LCD is not interrupt driven, so the two devices are not accessed simultaneously, so it's mostly about leaving the pins in a safe state when you're done interacting with the chip.

> "It'd be great to be able to use it in both hardware designs"

By this I meant, I'd like to see your driver as a mios module like above, so various apps can make use of it :)

[flo]

Thanks for that info, a great help.

Are the "public" interface function prototypes that need to be implemented per driver for an audio switch matrix extension already defined?

Or, to put it differently, what are the functions that the "apps" expect/need in order to work with an audio switch matrix?

I guess that each specific driver will need to implement that set of functions?

[stryd_one]

No they aren't already defined, that's part of the other project. I've got a pretty good idea of what functions will be available but it's nothing final yet. The tricky part is handling that some chips update one crosspoint at a time, while others must reload the entire matrix, and others can do both, so there needs to be optional support for all three methods of loading any one type of chip. I discussed the way this will be handled in the other thread.

[Ashiman]

http://www.commonsound.com/kits/doku.php?id=commonsound:bend_matrix

is there a better topic for this? I'd prefer the integrated LDR (Fairchild) version though.