Yesterday Three years ago axolotl asked on 8bc whether it is possible to invert the monochrome palette in LSDj, for use with backlit screens with an inverted polarizing foil. And it’s very much possible to do, and it’s even possible to modify an existing ROM image. So, I’ll show you how I did it using a copy of the LSDj ROM, BGB, and optionally a hex editor. I’m using XVI32, but any hex editor would do.

The palette value is change by a hardware register, which is a place in memory that a Gameboy program can be write to, to change things. So I look it up in the Pan Docs, which is a manual to the Gameboy hardware. Let’s look in the section LCD Monochrome Palettes. There we see that the address is $ff47 in hexadecimal and how the value is constructed.

For this tutorial, right click the BGB window and choose options (or press F11), go to system and choose the Gameboy option. This will run the ROM in DMG mode, which is needed to find where the palette change happens. Open the ROM image, press esc to go to the debugger and open Debug>Access breakpoints and enter FF47 and make sure “on write” is checked. This tells the BGB to track any writes to that address so we can find the place where the palette is initialized and change it.

Click ok and press F9 to begin execution. (Or reset the emulator)

BGB stops and show a bunch of machine instructions. The interesting part is the instructions at 019C and 019E. The instruction at 019C takes the hexadecimal value $E4, stores it in the CPU register A then writes it to the hardware register $FF47. This is the code we’re looking for. The value $E4 is the standard palette. Go back to pan docs and check again how the value is constructed.
Then let’s split the value into its individual colours.

$E4 = 11 10 01 00

11 is the lightest palette value and 00 is the darkest. Since want to invert the palette we’ll reverse the order.

      00 01 10 11 = $1B

Great. You may now right click the line at 019C, choose modify code and enter ld a,1B. The line that said ld a,E4 should now say ld a,1B. Choose run, reset to confirm that the palette is inverted and that LSDj doesn’t crash or anything. You may now go to file, save ROM as and save the file anywhere you want, preferably with a new file name.

Alternatively, you can use a hex editor to edit this value. This part of the tutorial was left unchanged from the first version, because no$gmb can’t save changes made to a ROM and thus needed a hex editor to modify the file.
Open the hex editor and replace the $E4 at position 019D with the value $1B. This address will vary depending on LSDj version.

Lastly, open the ROM in an emulator to confirm that the modification worked.

What does this number remind you of? You’re right, the US gross public debt. So hear me out on this modest proposal. Use this money to pay back the public debt. Then give each of the million people a 400 year prison sentence (not unheard of in the US) and let them work their asses off for 400 years to pay back the debt that is now on their shoulders. (Should anyone try to die from natural causes prior to the end of the sentence, you simply threaten to kill the person in question, which is usually enough to make him or her want to stay alive.) Putting another million people in prison won’t even double the US prison population, so the relatively small increase would hardly be a strain on the American correctional supervision system.

It’s doubtful whether anyone could object to this modest proposal which would instantly solve the two biggest problems America is facing today, copyright infringement and rampant public debt.

Korg recently announced the 2.0 firmware for the monotribe, which actually gives you 16 step, velocity control and a few other new features. More full information and download available on Korg’s homepage.

But what’s interesting about this upgrade is how you install it. You hold a secret key combo of three buttons on startup to go into upgrade mode, and then play a special audio file into the sync jack to perform the actual upgrade. This is potentially an easy way to hack the firmware of the monotribe (although with the same risk of bricking.)

Below, I’m posting the first step towards that goal, to extract the firmware image from the audio file. First, a big thanks to Th0mas for doing the initial groundwork of figuring out how the data is encoded. In fact, my code below below relies on having a transformed and cleaned up version of the audio data.

How is this data composed? The audio file encodes individual bits as little square wave pieces that are longer or shorter depending on whether a bit is low or high. The problem then becomes to figure out what is high and what is low, and how individual bytes are arranged. Th0mas quickly found out that short pulses mean a logical 1 and that bytes are transmitted with least significant digit first.

The problem, then, was to align the different data packets in the file, which both me and Th0mas spent some time trying to bruteforce by inserting bits at variious places to make the bytes appear correctly. To your you have two plaintext text strings saying KORG, and also a few other patterns. You feel like you’re trying to solve the GCHQ challenge. Eventually I gave a up bruteforcing and made an assumption about the encoding that turned out to be correct.

My starting point was a file with a list of individual bits. The data is transferred in packets with a 256 byte payload each. Normally, a number of 1 bits a retransmitter. To initiate communication, one 0 bit is transmitted, followed by starting signature of 0xA9, then 256 bytes of data are transferred. Then, 3 byte signature, 0×55, 0×55, 0×55 is transmitted (a “checkerboard” pattern, or alternating 0s and 1s.) Lastly, there’s a byte that I’m not sure what it’s for. It’s probably some form of checksum, but I can’t figure out what it is. (I’ve tried a number of xor combinations to see if I could figure it out, but no luck so far. Suggestions are welcome.)

Between every packet, there’s a number of bits skipped, or transmitted as simply 1. 344 to be precise, or 43 bytes. This was probably chosen to get a nice-looking number of cycles for (256+43=99) However, I would still assume that the ‘tribe is triggered by the start bits coming after a pause, rather than counting cycles.

Two packets are different, however, the first and the last. Both have the 0xA9 pre-data signature, and both lack the 0×55 post-data signature. The first, “greeting” package is much shorter than 256 bytes, and the rest is filled with 0xff. It looks like this:

I have not figured out what the 27 D8 value is. I couldn’t find any way of making it match the size of the rest of the dat. The 02 and 01 probably denote that this is version 2.0, first revision.

The last packet is also missing post-data signature. All the regular data adds up to a total of exactly 32768 nytes, or 32 kB.

Below is my version of the decoder program, which takes a “bits” file generated by Th0mas’ scripts, see the link above. It doesn not save the additional data, only the 256 byte payload of each packet.

Code, written in Python: (Or as a pastebin.)

from struct import pack

class TribeDecodeError(Exception):
    def __init__(self, value):
        self.value = value
    def __str__(self):
        return repr(self.value)

# Seeks a 'tribe fw bit array for the next packet start.
# Takes an iterator
def packetseek(it):
    numbits = 0;
    while(it.next()):
        numbits += 1;         # Loop through all the junk bits

    # print "%d bits skipped." % (numbits)

# Fetch next byte from bitarray.
# Returns an int.
def fetchbyte(it):
    tempstr="";
    for x in range(0,8):
        #print it.next()
        tempstr = str(it.next())+tempstr;

    return int(tempstr, 2)

# fetch a number of bytes to extract a full packet
# The second optional argument is to ignore the post-signature check, needed for the initial greeting packet
def fetchpacket(it, ignorepostsig=False, packetindex=0):
    tempbyte=0;tempstr = "";temparray=[];

    tempbyte=fetchbyte(it);

    # Confirm pre-signature
    if(tempbyte != 0xA9):
        raise TribeDecodeError(”Invalid packet pre-signature! Should be 0xA9. Found: ” + hex(tempbyte));

    # Confirm post-signature
    for x in range(0,256):
        tempbyte = fetchbyte(it);
        tempstr+=pack(”B”, tempbyte);
        temparray.append(tempbyte);

    if not ignorepostsig:
        # Confirm post-signature
        for x in range(0,3):
            tempbyte = fetchbyte(it);
            if(tempbyte != 0×55 and packetindex != 0×80):
                raise TribeDecodeError(”Invalid packet post-signature! Should be 3*0×55. Found: ” + hex(tempbyte));

        # Print the mysterious checksum byte
        tempbyte = fetchbyte(it);
        print “Packet %s has checksum (?) %s” % (hex(packetindex), hex(tempbyte));

        # Sanity check
        tempbyte = fetchbyte(it);
        if(tempbyte != 0xff):
            raise TribeDecodeError(”Sanity check. Packet should be followed by 0xff but isn’t. Found: ” + hex(tempbyte));

    return tempstr;

# main function
def tribefwdecode(infile, outfile, invert):
    f = open(infile, “r”);

    bitarray = f.readlines();  # Fetch the array of bits

    # Validate the bit array and convert it to bool
    for i,b in enumerate(bitarray):
        b = b.strip();
        if (b != “0″ and b != “1″):
            raise TribeDecodeError(”Only 0 and 1 in the bit file, please! Found: ” + b);
        else:
            if invert:
                bitarray[i] = 1-int(b);
            else:
                bitarray[i] = int(b);

    bititer = iter(bitarray);

    # Seek for the greeting packet.
    packetseek(bititer);
    fetchpacket(bititer, True)

    f = open(outfile, “w”)

    packetidx = 0;

    while True:
        try:
            packetseek(bititer);        # Try to get a packet
        except StopIteration:
            break;                      # Detect end of file.

        # Parse packet and write it fo the file.
        packet = fetchpacket(bititer,False,packetidx)
        f.write(packet)

        packetidx += 1;

    # If we’re done, close the file.
    f.close();
    print “File %s successfully parsed and written to %s” % (infile, outfile)

tribefwdecode(”bits”, “firmware2.bin”, True)

If you have questions or suggestions what the unknown values might be (27 F8 and checksum) please leave a comment below.

Of course, I felt the need to document it. But these pictures look considerably different from what I could see with my naked eye…

The photo has a pink tint and the sensor is saturated in the area between my fingers. (There was no open gap between the fingers.) What the how, you might ask? Let me tell you, the camera is picking up infrared light. The human doesn’t react to IR light, but digital cameras generally do react to near-red IR to some degree. There’s typically an IR high pass filter to remove the mostly unwanted IR, but it’s not perfect. Handy tip: You can also use this effect to test whether a remote control or Wii sensor bar is working by pointing it toward the camera, pressing a button/turning it on and looking at the screen.

So the LED is apparently emitting quite a lot of IR, and my flesh is apparently pretty transparent to it. What about some fruits? For this experiment, I made hole in various fruits and mounted to the lamp head, making sure no light escaped out the back. I put a plastic bag over the lamp head so it wouldn’t get dirty, of course.

An apple:

The effect on the apple is certainly not as pronounced as on my hand, but you can see it in the shadow, as well as some fringing around the edge of the fruit.

The last fruit to get this treatment was a kiwi. As one might expect, the thick skin and colored pulp made this shot less interesting from an IR point of view, but they are still included below. The difference in color is from experimenting with different ISO values. The last picture shows where the lamp head is shoved into the fruit with the “condom” on.

And lastly a semi-unrelated photo: This is some form of residue in my sink that I couldn’t remove easily. I think it’s a drop of grapefruit juice that has dried out. Pretty cool pattern. A moon with a big crater?

Untitled from _-_- on Vimeo.

You can trigger this input from LSDj. There are two things to think about:
1) The signal from the headphone jack is too weak. You need a ProSound modded DMG with the volume turned all the way up. (Other models untested, may or may not work…)
2) The monotribe requires a single clean rising edge to trigger correctly. The pitfall when using LSDj is that for example a square way, or a sawtooth wave, or even the noise generator, will trigger multiple steps. For this reason, you cannot use the pulse channels for this without getting a lot of false triggers. But you can use either the wave channel or the noise channel with somewhat predictable results (almost no false triggers) using a couple of tricks.

In this video I’m showing you how. As you can see, the video also shows which buttons I were pressing at any one time in case anything is unclear. Below is an explanation for the things show in the video.

1) Using the wave channel

The idea of this method is to create a wave that doesn’t oscillate. Instead of a sawtooth wave or a sine wave, you have a constant voltage. The easiest way to do this is by creating a synth with zero volume and moving all samples to the top.
Select+B, right until everything is selected, up until the samples are at the top.
(After recording this I realized that an even easier way to do the same thing is to set the VSHIFT parameter to 80, but this is good exercise in using the wave editor.)

The instrument used needs to be a wave instrument and have PLAY set to MANUAL. At this point, the instrument hould be ready to use. Place a note on on each step in the sequencer where you want to trigger the monotribe.

2) Using the noise channel

The Gameboy noise channel actually doesn’t produce real noise, but pseudo-random noise by changing amplitude between 0 and 1 in ways that sound random to humans. The Gameboy allows you to control the pitch of the noise, and at very slow pitch settings, it can take a second between the changes. This can be to sync the monotribe by first turning on the sound quickly to trigger the sync function, and then turning it off again, so the noise channel’s oscillations won’t trigger any more steps after that.

The way to do this is by setting the shape to 54 and usinng a table that turns off the sound output with the O command. (Trust me, I’m a professional.) I also changed the envelope to F8 to get the maximum amplitude possible.

General instructions

Use either the wave method or the noise method, not both. Both methods should give you OK stability from 40 BPM to 255 BPM, but sometimes you’ll see glitches, especially if you adjust the tempo.

If you have an appropriate left/right splitter cable, you can pan the sync instrument to the left and all other instruments to the right, to get both sound and sync out of one Gameboy. If any sound instrument is panned to the sync channel, the monotribe will start rushing.

Always start the monotribe first (or stop/start it before you restart LSDj) if you want things in sync. Otherwise, it will start at the step where it received the last pulse before it stopped.

Even when following all instructions, it may happen that the monotribe misses a beat when you press play, in particular the first time you press play after turning on the Gameboy. If so, stop LSDj, stop/start the monotribe and try again.

Tip 1: Adding some swing

You can add some swing in LSDj, just like when using Korg’s iOS app SyncKontrol. Swing, or shuffle, basically means that you delay every second note to get a more natural and less straight feel.

For this, I’m using the groove function in LSDJ. Since I laid out the the sync notes as 1/8th notes, I need to make a groove pattern that is 4 steps for it to have any effect. This is an LSDj technique that doesn’t need the monotribe to work. Go here to learn how the groove function in LSDj works.

Tip 2: Using the noise channel as a random trigger source

If you want to get random trigger pulses that are not synced to the tempo, or anything else, you can create a noise instrument with a low shape value, just like in the noise example below. If you let it play, it will trigger the monotribe at seemingly random intervals.

If you have any questions or thoughts, ask below.

Source: air_variable posts tagged monotribe (Japanese)

Introduction

Voilà Korg monotribe, the successor to its little brother, the monotron. The Monotron is a cheap, squeeky, and easily moddable toy synth with an MS-10/20-like filter topology. It has a ribbon keyboard an audio oscillator, an LFO, a lowpass filter, and not much more. The monotron was an instant hit, and Korg released schematics for it to aid modders further.

When I heard about the monotribe, I had my doubts. Mostly that there’s only one pattern, which is 8 steps long. Well, there are 8 extra steps for the drums, as well as a “flux mode” which records your movements on the ribbon continuously. In that sense, it is limited, and is an instrument made to be played with your hands, rather than be programmed. But as it turned out, this was a design choice, and not a technical limitation. I can easily imagine why. They wanted it to seem as analog and playful as possible.

Same thing with MIDI. Officially, the monotribe doesn’t support MIDI. It does however offer a sync pulse output and input. This allows it to be synced to other monotribes, modular synthesizers or even Korg’s own virtual iMS-20/iElectribe, using a special sync app on a second iPhone/Pod/Pad. However, the lack of MIDI is still a slight limitation.

TOC

Opening it up

Hackability and MIDI

MIDI, the electrical side of things

MIDI, the mechanical side of things

What can you do with MIDI on the monotribe?

Videos

Where do we go from here?/Final thoughts

Opening it up

Before I get to the part everyone has been waiting for, let me remark on something I noticed when I opened up the monotribe. The whole bottom side of the main board is covered in some form of residue, maybe flux or one of the liquids used in the manufacturing process.

This is even nastier. In the top two pictures, there’s some black stuff that I’m not sure what it is. Could be corrosion of some kind, or parts of a chip that was crushed by the pick and place machine. Or something. In the bottom picture, notice how IC17 (an LM324 opamp) as well as the Q2 transistor, are covered in this gunk. Also notice that there’s too much solder on some of the SMD resistors. (Original hi-res photo, 4320 x 3240) None of that is an immediate risk to the function of the device, but depending on what that residue actually is, there’s a very real risk of an increased failure rate over a decade or three, due to corrosion. I’ve seen better soldering, and I’ve seen significantly worse soldering, but all-in-all I expect better from a factory-made product. Maybe mine was a dud, but it makes you wonder.

Hackability and MIDI

I doubt Korg is going to release a schematic for the monotribe anytime soon, like they did for the monotron, but the monotribe board does have a number of useful points for modifying parameters and separating outputs, marked on the board. See the Monomodder blog for inspiration.

However, monotribe is quite a different beast compared to monotron. Even though the sounds are generated with analog circuitry, the heart of the monotribe is a microcontroller. The microcontroller is used as sequencer and, I think, LFO. The microcontroller is a Toshiba TMPM332FWUG. It has an ARM Cortex-M3 core, 128 kB of flash memory and 8 kB of internal RAM. It is clocked at 10 MHz. It has, like most microcontrollers these days, support for UART (serial communication) which means that software running on the microcontroller could theoretically easily implement MIDI, which is really just a quirky variation of UART. As I, and air_variable (Japanese) before me have discovered, there is something going on there, and it turned out to be actual MIDI. All you need to do is hook a few points on the board.

MIDI, the electrical side of things

Upper schematic: MIDI out. Lower schematic: MIDI in. NC means “no connection”.

Note that this schematic is looking at the back of a panel mount style MIDI jack, similar to the one seen in my other images.

The schematic is drawn so that you’re looking at the chip from above. Place the chip so that the little notch is pointing up. Pins 2 and 3 are on the left side of the chip. Ground is the bottom right pin. +5V/+3.3V is the upper right pin on the chip. The things inside the dotted rectangle is what’s inside the chip.

The unspecified diode on the left of the chip is a small signal diode, not a LED. 1n4148 or 1n914 will work, for example.

MIDI is designed in such a way that individual bits are transferred as a current that lights up a LED in an optocoupler, on the receiving side. This LED, in turn turns a phototransistor on and off. In a MIDI circuit, the LED in the optocoupler should be connected between the +5V line and the signal line. Normally, the signal line is high, which means there is no difference between it and the +5V line. To communicate, the signal line will go low, which in turn will light the LED on the receiving side.

A MIDI circuit should have a number of resistors both on the transmitting and receiving side. This design gives MIDI better noise immunity, and protects the gear in case of a number of things that can go wrong, such as a short-circuit between any individual pins, connecting an output to an output or reversing the pinout of the plug.

Let’s first look at how to do MIDI out with the monotribe. The microcontroller is using a 3.3 V power supply. MIDI is normally using 5 V, so if we wanted to be correct, we would convert the signal from 3.3 V to 5 V. However, we don’t strictly need to do this. As long as we can light up the LED on the other side, we’re fine. (You might need a real +5 V supply if you want to connect a MIDI hub that is powered by the MIDI host, however.)

To be guaranteed to light up the LED from 3.3 V, we’ll need to decrease the resistor values slightly. I found that replacing R₁ and R₂ in the schematic above with 150 ohms each works fine with my MIDI interface, but my calculations are suggesting that around 60 ohms may be needed, depending on the optocoupler. Bigger value resistor is safer, so try 150 ohms first.

There are two ways to do MIDI in, either with an optocoupler or without one. If you want to be cheap, you can simply connect the signal pin (the lowest one) from the MIDI jack and connect it through a 820 ohm resistor to the RX pin (see below) of the microcontroller. The resistor is needed to protect the microcontroller chip from the signal which is using a +5V signal level, which is outside of the chip’s specified limits. If you do it this way, you also need to connect ground from the MIDI jack (the “NC” pin) to ground on the board. Do not connect +5 V pin (the upper pin) anywhere.

If you want to do it properly, you can use for example a 6n136 or a 6n138. If you choose to use a 6n136, connect it as pictured above. (Connect +3.3 V, the red wire in the picture, instead of +5V in the schematic.) If you’ll be using a 6n138, you can use the connection below, according to Wooster audio. The part of the circuit that is to the left of the diode is the same as in the 6n136 circuit.

The picture above shows how I connected MIDI in with an optocoupler. The blue wire is ground. The red wire is +3.3V. The yellow wire is where the signal comes back (MIDI in.)

The MIDI output is situated between the points with yellow and the red cables, i.e. 3rd from the top.

MIDI, the mechanical side of things

You drill a hole for the jack, simple enough. However, I’ll share these images as a cautionary tale that you need to pay attention where you drill the hole. Here I made two mistakes:
1) The hole was too high up, so the jack collided with the PCB. (You’re looking into the monotribe from the bottom, so up=down…) I solved this by trimming away a part of the PCB which was just a big ground plane.
2) The less obvious problem is that the hole was too far back, so one of the screw holes ended up behind the standoff. This is a problem because it makes it difficult to insert a nut behind the screw.
So, plan before you drill!

If you’re using an optocoupler you need to add a small PCB for the optocoupler and the other components. (2-3 resistors and a diode.) I found that one suitable place for attaching this board is on the interface board. There’s a hole drilled where you can attach a board with a screw, as pictured below. Once again, however, I slightly misjudged the measurements. The board stuck out too long and collided with the speaker.

What can you do with MIDI on the monotribe?

Simple answer: You can sync the internal sequencer, play notes, and control all parameters the EG type as well as all parameters relating to the LFO section. It also transmits those very same things, so it could be used as a MIDI sync source, sequencer or limited control surface.

Details

• Sync: It will both send and accept MIDI sync, start and stop messages, meaning the sequencer can be reset over MIDI, which can’t be done remotely if you’re only using the regular sync input.

  Quirks/problems: When you’re using the miditribe as a MIDI slave and remove the sync clock, it will keep waiting for a MIDI clock indefinitely. You can fix this by either turning it off and on again, or plugging something in and out of the sync in jack, which will restore it to the internal sync clock.

• Notes: It will send and receive notes within the limits of the sequencer. It’s using channel 1 for notes. Notes outside these limits will be ignored. It does not react to varying velocities. It does however react to pitch bend MIDI messages and is able to record and play back pitch bend in flux mode! I don’t have MIDI out hooked up at the moment, so I can’t confirm this right now, but I’m assuming it also transmits MIDI pitch bend messages when it plays notes in flux mode.

  Quirks/problems: It has a stuck note issue when it doesn’t receive a note off message for a note. Let’s say you send a note on message for D4 and then a note on message for E4, and lastly a note off message for E4. This can happen in Renoise, for example. In this situation, D4 gets stuck, and a new D4 note is played as soon as you release all other keys. Sometimes multiple keys can get stuck, and you need to go through each key to depress each one.

• Drums: It’s using the standard General MIDI specification for drums, which means the following notes on MIDI channel 10.
  

  Name	Note number	Note name	GM drum name
  BD	36	C1	Bass drum 1
  SN	40	E1	Snare dum 2/Electric snare
  HH	42	F#1	Closed hi-hat

• Control change messages (CC): It can send and receive CC for all the knobs and switches marked green above. The parameters are mapped as follows:
  

  Name	CC number	Values	GM parameter name
  LFO rate	16	–	General purpose controller 1
  LFO int.	1	–	Modulation wheel
  EG shape	80	32=decay 64=sustain 96=attack	General purpose controller 5
  LFO target	81	32=VCO 64=VCO+VCF 96=VCF	General purpose controller 6
  LFO mode	82	32=Fast 64=Slow 96=1shot	General purpose controller 7
  LFO wave	83	32=Saw 64=Triangle 96=Square	General purpose controller 8

  Quirks/problems: It’s practically useless as a MIDI control surface because it is really slow at sending CC messages. If you wiggle one of the knobs a few times really fast for a few seconds, it will continue to transmit CC commands for several seconds.

  I’ve noticed that when controlling the LFO rate/int. knobs remotely, the value will sometimes jump back to the value that the knob is at. I’m guessing that this happens because there’s a small fluctuation in the voltage that the microcontroller will pick up as a change in the value. If you only want to control these parameters over MIDI, you can minimize this effect by turning these knobs fully counter-clockwise.

Videos

These are two videos showing me play around with MIDI in and MIDI out.

MIDI in

MIDI out

Video advertising this post, basically

Music sequenced in Renoise, played back on Korg monotribe and fed back into Renoise’s effects, some distortion and some delay. The drums are not played by the monotribe, but are samples in Renoise.

Where do we go from here?/Final thoughts

Some people have been wondering why Korg didn’t just include MIDI support out of the box. First off, to be honest, I think the MIDI support is a bit buggy, and probably wasn’t ready to be released anyway. It might be something they implemented mostly for internal testing. Another possibility, which I don’t believe much in, is that they’re planning to release a MIDI-enabled “monotribe pro” later. I just don’t think that fits into Korg’s profile of how people will use the monotribe, so I don’t think there will be a pro version with MIDI.

But, phew! Hopefully this should be enough information to get some of you up and running and get MIDI working on your ‘tribes. So what can we use this for anyway? Hooking up the monotribe to a computer and just use it as an analogue synth, honestly doesn’t provide any real advantages over using, say, a good softsynth, in my opinion. The monotribe’s charm is its hands-on usage, so I think the modification will be most useful for syncing it with gear where it’s more convenient to use MIDI sync than the sync options at the back of the monotribe.

Another possibility for LSDj users, is to use Arduinoboy+LSDj MIDI out. You’ll be able to control the monotribe nicely and which will give you a nice analogue companion to LSDj’s digital sound.

Other than that, the fact that monotribe can be used with MIDI also opens up the possibility of an internal mod. For the price it’s sold for, it’s a fun toy but not an essential tool. If the thing could be extended to be more TB-303-ish (not going to hide my dreams) it would instantly become more appealing to a lot of people. My original idea was to replace the firmware on the unit’s own microcontroller, but that’s difficult and tedious.

My new idea idea is to add another microcontroller (’duino anyone?) which replaces the sequencer, and also gives the possibility to do things like slide (emulated with pitch bend) or accent (emulated by adjusting the LFO rate/intensity). You could also add a second LFO and all sorts of things. With some extra software and wires, this thing could become truly useful as a standalone unit…

Useful links:
Board photos and more on Flickr
My YouTube channel
Discussion on Muff Wiggler
Monomodder blog

It turns out there were two problems, both most likely caused by buggy interpretation of .htaccess files by LiteSpeed. The first problem came from these two lines:
Allow From All
Order Allow,Deny
As it turns out by experiment, LiteSpeed handles these statements differently from Apache. Apache will start off by making a list of all the applicable rules, and then evaluating them in the order specified in the Order statement. In this example, first all Allow rules will be evaluated, then all deny rules. If there are any matches, Deny will take precedence since it’s last in order. If there are no matches, Deny will also take precedence since it’s the second argument. Of course, in this case everyone will be allowed since there’s an Allow From All statement, unless there are matching Deny rules. This is well documented in the Apache manual and (hopefully) well understood by web developers.

LiteSpeed on the other hand is dependent on where statements are placed in the source code. In the above example, the Allow From all statement is ignored, or possibly overridden by some implicit form of Deny From all. Not really sure… Moving Allow From all to after the Order statement will make it work. Also, changing the Allow statement to something more specific, like Allow From 1.2.3.4 but still placing it before Order will suddenly make it trigger. Not sure what’s up with that. Perhaps the LiteSpeed authors are trying to make it work how they think people think it will work. Or maybe they’re trying to do some optimizations by trying to abort the evaluation of the file as early as possible. Or maybe they just don’t know how these rules are interpreted by Apache. In any case, fact of the matter is that it doesn’t work as it is supposed to.

The next problem is how LiteSpeed handles errors in .htaccess files. It seems like whatever you do, you can’t get a 500 internal error from LiteSpeed if your .htaccess rules are incorrect. Completely invalid rules will be ignored, whereas as they would give a 500 internal on Apache. Malformed rules will give you a 404 not found instead of a 500 internal error, making it difficult to pinpoint the exact error. I’m not sure if this is a “feature” of LiteSpeed so they can say that their server will never have internal errors, or if it’s a secondary error similar to the “Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request” errors that you sometimes see on badly configured Apache servers.

The culprit this time was the following rule:
RewriteRule ^(.*)$ wiki/index.php?title=$1 [PT,L,QSA,B]
LiteSpeed apparently doesn’t support the B modifier (escape characters like & when building the query string) which caused the server to barf. However, since what I got was a 404 error, and not a 500, I thought the rule somehow rewrote the URI to something that didn’t exist. It was not until I replaced the B with a bunch of random characters that I understood what was going on.

All in all, all of this may not seem like a very tough nut to crack, but there’s more. For some reason, an index.html file had its permission mask set to 400, or r——–, which in UNIX persmission terms means that the file will only be readable by its owner, and not by users in the same group, or “anyone”. This was a placeholder page that the web host had put their, but I’m not sure how it got that permission mask.

When the rule works as it should, the root URL http://packetsofknowledge.se/ should be rewritten to the MediaWiki index.php. However, when I tried simply deleting/renaming my .htaccess, I still got a 403 because of the permissions of the index.html. However, since I hadn’t noticed that, I assumed at that point that the issue maybe wasn’t .htaccess related.

To summarize, when you have different error sources, the number of ways something can fail increases exponentially.

Sometimes people ask whether horizontal lines can be fixed as well. I’ve always assumed that the connector on the right side of the screen, which would be at fault if there are dead vertical lines, is basically identical, and that the only problem with fixing horizontal lines is the more awkward position of the connection — the “ribbon” is connected on the bottom side of the LCD glass, so you need to fit the soldering iron into a small corner without damaging anything.

However, the ribbon connector on the right side is different and more fragile. If you look at the top image, you’ll see a connector that looks brown. Technically speaking, this is called a flexible PCB (printed circuit board.) Just like on a regular, rigid PCB — like the display daughterboard itself — you have copper traces for connections and a green solder mask. The black blob in the middle is an integrated circuit, not unlike the chips you would see on any other circuit board, only that this one is hidden within a blob made of epoxy, and the circuit on the chip is connected directly to the copper traces, rather than using external pins soldered to a circuit board.

The right side connector has a similar flexible PCB, but the last stretch of the connection is made by a flimsy white plastic material which is easily damaged by the heat from a soldering iron. The actual connectors are not made of copper but possibly carbon or some other conductive material. My advice is, do not try to fix dead horizontal lines. You’ll likely just mess up the connector as seen below.