Midifilter

I was lucky to get a midibox FM recently. This awesome thing is kind of diy-community project to reactivate the OPL3-Yamaha-chips in the early SoundBlaster-times. The midiboxFM is a completely and very comfortably editable 6 voice 4-operator frequency modulation synthesizer. It also got a built in drumsynthesizer, i love the sound of the whole thing because of its cheap DA-converters, no way to emulate this in software.

ok, what has this to do with the midifilter? Easy: the midiboxFM cna be remoted by midicontrollers. This is a cool feature but is cannot be disabled on the unit. I digged all the menus, found a parameter to DISable controllersending but it always receives them. That alone woulnd bother me, but there are 2 controllers which interfere with controllers sent by the mc909 in normal operation. So i could NOT use the mc909 together with the midibox, even fruityloops made problems. The problematic controllers are 10 (panning) and 88. On the midibox 10 alters the audio-output of the operators and 88 the intensity of LFO1 on LFO2. As a consequence when muting/unmuting a track on the mc909 on the midichannel of the midibox, the operator outputs of the midibox were scrambled.

Consequence: 'i need a filter for thecontroller 10 and 88' ! I didnt find a product on the market. The anatek Pocketfilter is not produced anymore and hard to find. And it cannot filter special controllers. I had to make one on my own.

I used the atiny2313 again. It runs on 4MHz. It has a complete 8pin-port for reading the dipswitches where you can set, which data to be filtered. I wanted to keep it a simple as possible. That means, the controllers to be filtered are hardwareprogrammed. To add or change the special controllernumbers, the unit needs to be attached to the programmerjack.

I used an old screwbox i had flying around, i like building new things out of junk.  

use an old junky screw-box to build new things instead of buying a new 'professional box'

Thats the way it looks after putting it in the box. Top left is the programminginterface. The red-LED sais 'i have voltage to operate'. The green LED sais 'i am filtering something, but it is NOT common or realtime message because filtering that would result in a nearly steady on and if there would be another led solely for common or realtime-message this whole filter would consume another 20mA more' - hmm, you see, the green LED has a lot to say :)

(Just) Some words about midiprotocol:

Most midimessage (Pitchbend, Note-On/Off, Controller, Pressure) consists of 3 Bytes: statusByte, dataByte1 and dataByte2.

Common- and Realtimemessages (ActiveSensing, Start/Stop/Continue/Clock, ...) only consists of ONE statusByte.

Programchanges consist of 2 bytes and are sometimes accompanied by 2 controller-triples for CntrNr 0 and 32 (MSB and LSB).

Midi is slow and to save data, it has something called 'running status' which means, there is only one statusByte followed by altering dataBytes like this:

statusByte, dataByte1, dataByte2, dataByte1, dataByte2, dataByte1, dataByte2, ... until a statusByte is snet which is different from the first statusByte.

This results in some distinguishing-trouble when trying to separate individual controllers, which definately was the hardest part in the whole project.

I found some good information about midiprotocol in this place (sorry, its in german).

Look from below. Took about 1-2 hours to solder this. Layouting and etching a professional pcb would have taken longer i guess.

Some words about the software

In the mainloop the status of the dip-switches are stored in a register.

I also reserved a register for 8 flags of the current filteringstatus.

Another register is used to save the current midistatus, just one bit is used to save 'running status'.

The processing of incoming midibytes is of course handles in an interruptroutine. At the end of the routine are two jumppoints:

• 'sendByte' (which puts the byte in the sendbuffer ans sends it out though TXD)

• 'filterByte' (which skips a)

First, the incoming byte is examined if its a Common/Realtime-Byte. If the Bit in the dipStatus-Register is not set, we jump to 'filterByte' else we jump to 'sendByte'. (you might wonder why i filter if dipstatus is NOT set. Thats just because of the direction i soldered the dipswitch onto the board. I wanted the dipswitch to say ON if the filtering for this switch is ENABLED. ON means -> Pin is pulled to gound, means NOT set.)

Second we distinguish between 'statusByte' or 'dataByte', we finds that out because only statusBytes have their MSB (MostSignificantBit) set. The statusByte is cleaned from its midichannel, we dont distinguish channels and filter on all channels.

Third we detect runningStatus by comparing a 'byteCounterTotal' with 3 which is set to 0 on every statusByte. If 'byteCounterTotal' exceeds 2 we set runningStatus to ON. We need this flag later.

Then the filtering of messages>2bytes starts:

Note, Pressure, (all) Controllers, Pitchbend are all the same:

____________________________________

is dipSwitch set for this message?

    yes1: is statusByte suitable to actual message ?

        yes2: set filterFlag for this message

        no2: continue testing with next message

    no1: jump to 'filterByte'

filterBit for this message is set (this must be a dataBye)?

    yes3: jump to 'filterByte'

    no3: continue testing with next message

____________________________________

Sysex starts with a statusByte of 0hF0 and ends with a 0hF7 - easy to filter.

At the very last place, the filtering for different controllers is made. The principle is, to hold back 3 Bytes beginning with the statusByte and send them after they were examined. In the examination there are also the Bank-Controllers for Programchange filtered out (if ProgramChange should be filtered).

One important issue is to send the statusByte if you are in runningStatus and the Controllernumber changes from a filtered Number to an UNFILTERED number. Runningstatus is NOT ended when changing controllernumbers inside runningStatus. Took some hours for my brain to got it solved. To the right you find the functiondiagram.

project finished.

The cables directly go into the midibox.

schematic

functiondiagram interrupt starting

functiondiagram 'filtering special controllers'