Guitar FX switcher with MidiBox

[flo]

Hi,

I just found the MidiBox projects at www.ucapps.de. Looks great to get into Midi controlled applications. I'm a electronics engineer and programmer but I'm lazy so I'd rather buy and build the MidiBox kits from www.mikes-elektronikseite.de than to reinvent the wheel.  ;)

I'm trying to build a midi controlled guitar FX switcher using multiple DPDT relais (or a switch matrix chip) and a Behringer FCB1010 midi foot-controller.

I tried searching for a project on this forum but could not find a clearly described project for it.

I think I need a:

- CORE Module, that I can program to receive the midi from the footcontroller and translate midi program changes into on-off digital signal outputs.

- DOUT Module, the digital outputs that will be set by the CORE module and will control the relais.

- LC Display 16x2 with backlight

- PIC18F4620 (with the bootloader)

- DPDT relais switch board, controlled by the DOUT module each of these DPDT relais will bypass or enable one FX.

(probably need to diy that relais board myself or use something like a relais card from Velleman:

http://www.velleman.be/ot/en/product/view/?id=9069

€ 17.95)

OR

- MT8816 - 8 x 16 Analog Switch Matrix chip from Zarlink (Futurlec $4,50), controlled by the DOUT module this chip can switch FX outputs to FX inputs for a flexible programmable FX router:

http://www.datasheetcatalog.org/datasheet/zarlinksemiconductor/zarlink_MT8816_MAR_97.pdf

http://www.futurlec.com/cgi-bin/search/qty_price.cgi?part_no=MT8816AE

Any ideas or comments? Am I on the right track here?

[lylehaze]

Yes, that would work..

There is a larger project afoot here at

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

or you might just go at it yourself.

I have an old book here titled "Electronic Projects for Musicians" by Craig Anderton that details making an effects switcher using 4066 chips.

All the methods mentioned are possible, and a few more, I'm sure.

Have Fun,

LyleHaze

[flo]

Thanks for the reply.

So far I've read the following threads but none of them are "ready to go" projects.

Still an interesting read:

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

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

(Too complicated, too many features)

Program change to guitar fx gear controll

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

MT8816 based effects router

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

(interesting)

looking to make a effect box

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

Midibox amp switcher

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

Has this link but its dead:

http://216.250.178.122/will/midibox/signalrouter/index.html

programable midi to relay unit

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

Midibox as Switcher advice sought (newbie alert :-)

http://www.midibox.org/forum/index.php?topic=4836.0

Building Pedal Box / Pedal Board

http://www.midibox.org/dokuwiki/pedal_box

[flo]

To keep it simple, I can leave out any user-interface so I would not need a DIN module nor a frontpanel with knobs and stuff.

As long as I can program the foot-controller's midi program change messages that'll work I think.

Switching 8 relais with midi program changes can be done "binary":

Midi program 0  = 0000 0000 = all relais OFF

Midi program 1  = 0000 0001 = first relais ON, rest OFF

Midi program 15 = 0000 1111 = first 4 relais ON, last 4 relais OFF

etc.

[ilmenator]

Program change messages alone will give you access to only seven relais (0-127 == 7 bit).

Best regards, ilmenator

[flo]

Ah that's right, only 7 bit available. Hmmm So how to get to more "bits"?

Use two midi messages and combine that? Sounds a bit cumbersome.

Use the midi channel information also? Perhaps not a good idea when also using other midi equipment on the same midi cable but I could use two midi channels and use the program change messages from those two channels to get one extra bit of information. Then I could get to max 14 relais which is sufficient.

What was that midi message again for controlling parameters... not a CC message but a ... ? Something that was 14 bit or so... A RPN or NRPN! How about using that? Can the MidiBox handle NRPN gracefully?

Well, probably it all depends on what my foot controller can send. It's a Behringer FCB1010. Now where's that manual...

[slumgud]

Exiting project! Been looking for something like this to build for quite some time  :o

[flo]

Glad you like it but I've hardly scratched the surface here... Still need to get all the details clear.

Like:

- Requirements: What do I actually want/need? Need to get this really clear and minimized or else this project will only add up to something that is way too complex and a drag to build.

- Architecture: Block diagram, midi implementation.

- Schematics: Especially the wiring and relais boards. The rest is probably regular MidiBox stuff.

- Layout: Putting it into one enclosure or go "modular"?

- User interface: Need it or not? Currently I hope to do without it. Perhaps only some basic visual feedback with LEDs indicating what is enabled and a "midi-recieved" indication.

- Input and outputs: How to keep it simple, cheap AND flexible/usable enough. What do I need and what can I do without.

- Parts: Bill Of Materials. Were to get all components and parts.

- Relais: What kind, were to get them, how to hook them up, DPDT or something else, implus or latching. So many questions...

- Software: What programming do I still need to do to filter out the appropriate midi messages and control the relais via a DOUT board.

[slumgud]

just thought i should show you a commercial product for inspiration.

Have you ever seen the Gigrig switchers? http://www.thegigrig.com/acatalog/TheGigRig_MIDI-8_Black.html

[flo]

Thanks for the input.

Yes, I saw that Midi-8 GigRig. Nice, inspiring and almost what I want, except lacking the remote switching via midi using a midi-footcontroller. What is interesting is the question of wiring the loopers in a serial manner internally like the Midi8 does or to provide a input and output per looper like loop 4 of the Axess GRX4. A series chain would halve the amount of jacks but decreases the flexibility.

I guess the Midi8 remotely controlled via midi foot controller with some loopers wired as a series chain and some indepent ones is the way to go.

Midi-8 manual:

http://www.thegigrig.com/acatalog/TheGigRig_MIDI-8_Manual.pdf

GRX4 Guitar Router/Switcher

http://www.axess-electronics.com/sc/GRX4-Guitar-Router-Switcher-p-16135.html

http://www.axess-electronics.com/sc/axess/images/i_pdf.gif

[flo]

If I minimize it by not having a user-interface nor a LCD nor a DOUT module and use only the CORE module and drive port B directly when the MidiBox recieves a MIDI program change event on a specific channel (say 15 and 16).

There is a code example for something like that:

Driving PIC pins of port B via MIDI

http://www.ucapps.de/mios_c_pic_pin.html

I only have to change that code to react to a program change event on channel 15 or 16 instead of a note-on event.

I can then use the 8 pins of port B to control 8 DPDT switching relais combined with indicator LEDs for visual feedback. That would give me 8 FX true-bypass switches with minimal efford & components.

[lylehaze]

You might want to include the LCD during design and testing, and leave it off for the final rev.

It is very handy for seeing what you are doing.

LyleHaze

[flo]

Thanks for that tip! I hope I can test and debug it using my scope but if I need that LCD, would that also need to be connected to port B of the PIC?

Actually, I do not yet know which pins of the PIC make up "port B". I only read about it in the code snippet I have posted above. That snippet also states: "Note that Port B is normaly used for the LCD, in this example we have to unconnect it". If so, are there also other 8bit ports available in the MidiBox? Perhaps somebody can point me to the page containing that information of the MidiBox, thanks!

There are of course other projects available on the web that try to accomplish the same goal with some variations. So for anybody that is interested I have also checked the following:

The Looper

Mitch - Midi Switch

http://www.jimkim.de/html/index.htm

MIDI Change-Over Relay Units

http://tomscarff.tripod.com/relay_changeover/relay_changeover.htm

FX Switcher Project

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

The Crossbar Project, a matrix effects switcher

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

Geofex FX switching

http://www.geofex.com/Article_Folders/juggler/juggler.htm, 4 November 1999

http://www.geofex.com/Article_Folders/fxswitchr/fxswitchr.htm, 18 January 2000

http://www.geofex.com/Article_Folders/ASMOP/ASMOP.htm, 28 October 2001

http://www.geofex.com/Article_Folders/ASMOP/asmop1d.pdf

http://www.geofex.com/Article_Folders/ASMOP/asmop1e.gif

[flo]

I have been reading this:

http://www.ucapps.de/mbhp_core.html

but I can not find any reference to a "PORTB" as stated in the code snippet:

http://www.ucapps.de/mios_c_pic_pin.html

I think it is a MIOS "system variable" that is mapped to the "RB" 8 bit output port, pin [33, 40], of the PIC as displayed in:

http://www.ucapps.de/mbhp/mbhp_core_v3.pdf

On the CORE information page is a table that refers to "available ports" and then calls them "interfaces" which probably is the same as a "port". This inconsistent usage of terms confuses me a bit. Perhaps "port" is something of the PIC like "RA", "RB" and "interface" is the header on the PCB that is connected to "port" pins on the PIC. Can ports and interfaces both be addressed in MIOS?

I see there that the LCD should be connected to the 11 bit wide interface J15 consisting of 8 bit from "RB" as well as three pins from port "RD" (pin [28, 30]).

There is also a 6 bit wide interface J10: "Interface to application specific module extensions...". It made from pins of ports "RC" and "RD" where RD5 and RD6 are shared with J15. Looks a bit messy but perhaps I'm not getting it. Is this the preferred interface to connect my relais to? So how do I address this in MIOS, what is the name of the "system variable" for this interface?

So next to the interface J15 for the LCD the only 8 bit wide interface is J5, pin [2, 10]? The "interface" table states: "Interface to the AIN module for MIDIbox64 and MIDIbox64E. There are also some application which use this pin as digital in- or output".

How can this interface be addressed in MIOS as an 8 bit wide output that I can "set"?

I hope you bear with me and all these questions...

[stryd_one]

http://www.midibox.org/dokuwiki/mios_pin_list

For example, RB5 = PORTB, Pin 5

Not to be confused with the core module jumpers, which for that pin would be

J15:D5 = Jumper 15, pin label D5 (data 5)

Look for J5 as DIN/ J5 as DOUT, also the J5IO module on SVN..

[flo]

Thanks for the link to that MIOS pin list.

So a "Core Port" like J15 can be adressed in MIOS with predefined "system" variables like "RB5", "RB", "PORTB" and such.

Please, where can I find the the MIOS programming documentation about the definitions and usage of these "Core Port" variables?

> "Look for J5 as DIN/ J5 as DOUT, also the J5IO module on SVN."

Sounds interesting but please tell me, what or where is "SVN"?

[stryd_one]

How pins work 101: (I haven't done much doco lately, I hope this redeems me a little)

OK... Uhm crap where do I start... OK let's just talk about PORTB aka J15 aka the LCD data port. I'll start at the beginning, so this might get a bit geekey... but it'll make a lot more sense once you give it a shot I'll try to keep it as plain-english as possible. Likewise don't get me wrong, if I explain stuff you already know, it's just because I'm telling the whole story for everyone's benefit :)

Inside the PIC chip is a bunch of memory cells. These cells hold an electrical charge, LOW or HIGH, aka 0 or 1 in digital terms. Because this is an 8-bit uC, the cells are divided into groups of 8 (a byte) and each byte gets an 'address' which is just a glorified way of saying they get counted and numbered accordingly :) (these memory locations are all known as SFR's or Special Function Registers, they're a memory register dedicated to this special function of providing I/O)

There are 8 of these cells (one byte) who's charge is used to set the voltage, which is output at 8 of the pins of the PIC chip (yaknow, the legs of metal hanging off the sides). For convenience, seeing as 8 pins are grouped together, we give it a name: it's a "Port". We name the ports A, B, C, etc.

The bank of memory cells which controls these pins, is able to be accessed by the program you put on the chip, by referring to the address. In the case of Port B on a PIC18F4620, this address is 0xF8A. Instead of making you remember a bunch of hexadecimal addresses like that, we use a header file, which tells the assembler like, "when we use this name, we are referring to this address". Thus, we can give them a more convenient name. 0xF8A, is known as LATB, which is short for Latch B, or to be more verbose, the output latch of port B.

Latch? what the heck is Latch? I thought we were talking about a port?

Well, the latch register is the memory, where you write the data, which controls the pins, on that port - but what you write there, only takes effect when the pin is an output. When the pin is an output, the data you write to it's address, is latched to the pins, similar to the operation of something like a 74HC373 or 573 - but these pins can be inputs too.

When the pin is set as an input, it reads the incoming voltage at the pin, and stores it in an other different memory location. In this case, it's 0xF81 - and that is the location we have specified in our header file, as PORTB. By reading the memory stored there, we can see if each pin is HIGH or LOW/1 or 0/ON or OFF, etc.

It's also possible to read or write just one bit of the byte, which equates to one pin. This allows you to control or read a single pin, without effecting the others. in code, this can be done like:

LATB.LATB5 = 1;                //sets the 5th bit (counting from 0) as ON/1/HIGH
Mybutton   = PORTB.RB6;      // Sets your variable to 0 or 1 depending on whether the button is pushed in or not, driving the pin high or low

So, that's nice, but how can you tell if the pin is an input or an output? Well that's another memory location. This time it's 0xF93, which we call TRISB, which is short for Tristate B, the Tristate status of port B. When a pin is 'tristated', that means it's an input. So, if we set a bit within the TRISB byte to 1, then the corresponding pin is tristated, and it's now an input, and ready to read from the corresponding bit in PORTB. For example:

TRISB.TRISB5 = 1;             //sets the 5th pin as an input
TRISB.TRISB5 = 0;             //sets the 5th pin as an output
TRISB        = 0;             //sets the whole port as an output
TRISB        = 0x0F;       //sets the last 4 pins as outputs, and the others as inputs. 
                             //Hint: 0x0F = 00001111, and we count the pins from the right to left direction in binary!

What's more, the TRISx byte has a handy effect on the PORTx and LATx bytes. I should mention: Writing to PORTx doesn't really write to PORTx at all. It will actually write to LATx, because that's where you set the outputs, and writing to the port is an output operation right... The chip takes care of that. Reading from LATx will always show you whatever you last wrote there, it doesn't change, it just sits there waiting for you to output it, by setting TRISx to 0. How patient ;) Reading PORTx, will always show you whatever's on the pins themselves. It's an input. Now, when the pin is set as an output (TRISx = 0), that data will be latched from the memory onto the pins right away, so you'd be thinking, that reading PORTx and LATx will have the same value... Most of the time that will be true, but it is possible that some other part of the circuit outside the PIC, will drive the pin low, and in this case, LATx and PORTx will differ. So, that's how it works from the perspective of the PIC chip itself. Obviously, there are complex sequences of controlling these pins, involved in performing some of the real-world applications. For example, it takes a dozen or so changes of pin states, to output a single character on an LCD module. Who needs to worry about all that every time, right? That's where the operating system and it's built-in drivers come into play. Hooray for MIOS. For example, instead of having to code out this massive bunch of pin controls, we let TK do that for us ;) and we can then use a command to set the pins according to our needs, so we can just type some simple code like

MIOS_LCD_PrintCString("TK is the bomb!")

All of these functions are listed in the Function Reference. If you can use these, it's best to do so, as they guarantee that it will work, and not break anything. So, that covers off the PIC and MIOS, which leaves us with MBHP - the midibox hardware platform. You may have already noticed, that in addition to the 8 pins I've used in the above examples, there are three other pins required to use the LCD (enable - has to be low or the LCD does nothing; R/W, Low = Write, High = Read; and RS or register select, which tells the LCD whether you're sending it a command (like "reposition the cursor") or data ("like put the cursor over *there*"), which are LOW and HIGH respectively. As such, it doesn't just use PORTB, but also PORTA. All the required pins, go to one connector on the MBHP PCB, naturally. These connectors or "Jumpers" (same name as the cable you use to connect your car battery when you leave the lights on) are numbered for ease of reference. It so happens that the jumper for the LCD was number 15, so: J15. We also refer to the individual pins on the jumper by their purpose, such as J15:E (enable) or J15:RW (Read/Write) or J15:D0 (data 0 - that's PORTB:RB0). You can see how all the J*:* names correspond to the pin names, on that pin list I posted. You should always read the datasheet for the PIC though, to make sure you don't accidentally do something you didn't expect. For example a driver I am writing at the moment uses PortE. PortE is a bit different, it only has three physical pins. The PORTE and LATE registers are safe to write to as a whole, but the part of the TRISE register which doesn't correspond to a physical pin, is used for some other features. I can't just do

TRISE = 0; 

to make it an output, because then I will be overwriting some data that the PIC uses for other things. (Buffer ful/overflow flags for those of you who care).

Uhm... I think that covers it? Hint: I answered your question about SVN with the first link (to the header) have a browse around there, and don't forget to find the wiki page on SVN client setup so you can copy it to your PC if you need to.

I need to rest my hands!

[lylehaze]

The definitions for PORTx, LATx, and TRISx are in the PIC header files for that chip. In my case P18F452.inc.

Those are from MicroChip, the PIC maker.

How MIOS has assigned them further would be somewhere else. :-)

Sorry, I'm too tired after reading stryd_ones response.

LyleHaze

[flo]

@stryd_one:

Thanks a lot for that great post! Now I understand.  8)

I have just ordered the CORE, DIN, DOUT, AIN, AOUT kits, a PIC 18F4620 with the bootloader and an LCD from www.mikes-elektronikseite.de.

I'll just build the stuff starting with the CORE and the DOUT and start programming!

I'll post my progress.

[stryd_one]

The definitions for PORTx, LATx, and TRISx are in the PIC header files for that chip. In my case P18F452.inc.

Yeh that's the ASM source for the headers... I was keeping it in C for ease of reading :)

The ASM headers are part of GPASM, so you can find them in \Program Files\gputils\header or similar.

[lylehaze]

Oops, sorry if I confused anyone.

I'm so old I can't "C" anymore, I'm just an asm kind of guy.

Now if I could get that newfangled compiler ported to OS4, I might be willing to leave MPLAB behind..

Still, no matter your language, it's a good idea to read the processor-specific includes to better understand what you're playing with.

But these are just the ramblings of an old man. :-)

LyleHaze

[/tilted/]

Sorry to jump in, but did anyone else read this:

Those are from MicroChip, the PIC maker.

And think of this:

Or am I just crazy?

[stryd_one]

LOL, not at the time, but now that you mention it, that's funny :D

[flo]

  ;D 8)

[lylehaze]

tilted,

Thanks, I needed a good laugh this morning.

I wonder what happens if you drop a PIC chip in a

2 liter bottle of diet coke?

Back to writing documents..

LyleHaze