Want a box to send patch changes - questions...

[jstoecker]

I'm looking for something to simplify my gig setup, which has two keyboards

and six midi modules. The first keyboard sends to four modules (right now

they're all daisy-chained via MIDI thru's), the second to the other two.

I want to be able to select a patch on the 'proposed gizmo' and have each module

change patches (each module receiving its own bank select and patch number). 

For example, selecting patch "1" might cause the first module to receive bank #1,

patch 7; the second module, bank 11, patch 14, the third, bank 1, patch 9, the

fourth, bank 3, patch 120.

This gizmo would have one MIDI input for each keyboard, and a MIDI output for

each module,  and all note data and controllers would be "echoed" from the first

input to the first four  outputs, and from the second input to the last two outputs..

No sysex or MTC or song position stuff would be passed through or processed.

Patch changes seen on the input would be filtered out, or possibly mapped onto the

patch setups within the gizmo.  So, sort of like a glorified "through" box for two

keyboards.

I'd like to be able to easily change the patch configuration from a "front panel"  (LCD

display and buttons e.g. up, down, select/enter, and exit/esc) and have the gizmo

remember setups from one usage/gig to the next.

Am I correct in thinking I could build essentially the equivalent of four  "MidiFilter"

(http://www.ucapps.de/midifilter.html) units for the first controller keyboard, all

sharing the same MIDI inputs but having seperate outputs? 

Am I correct in thinking I'd need additional modules, e.g. the LCD, DIN (for the buttons),

and BankStick (for remembering setups) modules?

Also, I want to be clear on one other thing: is it correct that the MIDIFilter project does not use MIOS, so if I want to take advantage of MIOS I have to port or build from scratch the MIDI

message processing capabilities present in the MIDIFilter project?

TIA,

John

[TK.]

Hi John,

the documentation of the MIDI filter project is a little bit outdated. It refers to an old PIC16F solution, but can currently be replaced by a PIC18F452 core + MIOS, with all it's advantages (integrated low-level drivers for all peripherals you want to use)

MIDI processing is very easy with MIOS, especially when you are using the C wrapper. There is a special "hook" (C function) which is called each time when a complete MIDI event has been received.

Let's say you want to send a program change + bank message when a program change is received, the appr. code is:

/////////////////////////////////////////////////////////////////////////////
//  This function is called by MIOS when a complete MIDI event has been received
/////////////////////////////////////////////////////////////////////////////
void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam
{
  unsigned char pc;
  unsigned char bank;

  // expect program change on channel 1 (-> 0xc0)
  if( evnt0 == 0xc0 ) {
    // program change number (0..127) is in evnt1

    // we've stored the "mapped" p.c. + bank message in BankStick
    // the address is 2 * received p.c. number
    pc   = MIOS_BANKSTICK_Read((evnt1 * 2) + 0);
    bank = MIOS_BANKSTICK_Read((evnt1 * 2) + 1);

    // send these MIDI events out
    MIOS_MIDI_TxBufferPut(0xc0); // Program Change, Channel #1
    MIOS_MIDI_TxBufferPut(pc);

    MIOS_MIDI_TxBufferPut(0xb0); // Bank Change, Channel #1
    MIOS_MIDI_TxBufferPut(0x00); // or 32 or 0 and 32... depends on sound module
    MIOS_MIDI_TxBufferPut(bank);
  }
}
[/code]
This is only a simplified examle, I'm sure that you will extend it once you are able to play with the hardware :)
A LCD and DIN module makes sense (for the DIN, 8 buttons are propably enough, so you could build a single 74HC165 on a breadboard). 
For the BankStick I'm not sure, because if you only want to store 128 settings, and if each setting contains a program change and bank number, then the internal 256 byte EEPROM would be sufficient. In this case use the MIOS_EEPROM_* functions instead of MIOS_BANKSTICK_*
Best Regards, Thorsten.

[jstoecker]

Thorsten:

Wow ;D  - that's *really* nice for MIOS to be event driven like that.

I'm looking forward to rolling up my sleeves and building some stuff....

Thanks a lot!

John

[istephen]

Hi Ian,

(can the LTC unit send seperatly messages on the second midi out?).

unfortunately not - the PIC has only one UART.

But in theory it should be possible to route the Tx output to different MIDI outs with a multiplexer (74HCxx... don't remember the type number).

This requires one (for two MIDI outs) or two (for four MIDI outs) dedicated PIC output pins for the multiplexer select inputs (see http://www.ucapps.de/mios/mios_pin_list.txt for adequate pins)

Before selecting a new MIDI output, it has to be ensured that an ongoing transmission has been finished. This can be done with the MIOS_MIDI_TxBufferFlush function.

General program flow (example):

  - MIOS_MIDI_TxBufferFlush

  - select new MIDI out

  - send data with MIOS_MIDI_TxBufferPut

this will do the trick

Best Regards, Thorsten.

[istephen]

Thanks for clarifying this.

Multiplexing like this wouldn't help with midi conguestion, as say you wanted to layer a sound on two modules you'd still need to send it twice, and it would take just as long as sending it on two channels down one cable. The same amount of data still has to go through the uart.

However... suppose you had 8 midi outputs, all wired in parallel. Add an 8 bit latch and 8 And (Or? are the isolators active high or low?) gates. Anyway you could then have each device on it's own cable, listening on channel 1. When you receive an event you look up a channel mask for that event, and load that into the latch, the output of which gates the signal to each midi out. You could then layer a sound on 8 devices by sending it once, or send it to any subset of devices with little overhead (other than waiting for the stream to flush).

On the other hand this is problematic for devices which are themselves responding on multiple channels, as the software would need to find a neat way of selecting devices by both device and channel (so for example sending to all ch1 devices is easy, but sending to midi1/ch1 and midi2/ch3 is a real pain).

I'll probably just do a soft solution first with one midi out, but I think this is could be a neater solution than having to deal with it in software.

Ian