About
Often known as nitro2k01
Addicted to reposting reposts of reposts on soup.
Also try my regular blog
Make soup a better place! Add a descriptive text to each image you post, or if needed repost!
Friends
-
Loading…Marindin about 1 year ago -
Loading…bittin 4 days ago -
Loading…iber 3 months ago -
Loading…kaminari about 14 hours ago -
Loading…fungi about 8 hours ago -
Loading…jeaneric 1 day ago -
Loading…resocjalizator about 7 hours ago -
Loading…apoc 44 minutes ago -
Loading…optimus6128 11 days ago -
Loading…gammagoblin about 3 hours ago - +6
Click here to check if anything new just came in.
January 17 2012
(Well, I guess that's what you're referring to...)
December 23 2011
A working, although glitchy white noise generator. Should I banned from ever handling a soldering iron again for creating this monstrosity?
December 04 2011
Korg monotribe Firmware 2.0 analysis
As has already been established, Korg monotribe is MIDI capable. Howver, it is still limited with regard to certain things, such as being able to use more than 8 seqeuncer steps for the synth part or using a filter envelope separately from and LFO. All things that should be very much technically possible on the microcontroller device in the unit. One thing I’ve considered is to modify or even rewrite the firmware of the ‘tribe. Apart from the obvious work of actually rewriting the firmware, you need a way of flashing it onto the device. And preferably a copy of the original firmware, so the ‘tribe won’t be a useless brick until development is done. The microcontroller in the monotribe does support JTAG, a protocol for reading and writing firmware data, among other things, but this function may be locked down for security reasons.
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.
November 25 2011
Fun with a LED spotlight, a camera, my hand and some fruit
I recently bought an IKEA spotlight. (JANSJÖ Clamp spotlight, product number 80163192) For fun I tried cupping my hand around it in a dark room to make the light shine through my hand. I could see my own veins. Pretty cool. I used to this with flashlights as a kid, as well.
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.
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?
October 17 2011
September 28 2011
Syncing monotribe to LSDj using the sync jack (no MIDI)
Monotribe has jacks on the back for sync in and out. The sync output outputs 15 ms 5V pulses, which can either be rising or falling. (There’s a setting for this.) The sync input can also trigger on either a positive or a negative edge. (There’s a setting for this as well.)
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.
September 10 2011
Wireless monotribe MIDI
Made by a Japanese person using the name air_variable. He’s using an XBee for wireless serial communication. This just gives you a serial line, which can be interfaced over USB. This is not real MIDI, but you can use a serial to MIDI converter for this. For example, BlipBox MIDI serial or Spikenzie Labs Serial MIDI. Or why not Korg’s (!) PCIF-NT driver, as suggested in Lady Ada’s MIDI Zigbee tutorial. There are even more serial MIDI converters if you use Google.
Source: air_variable posts tagged monotribe (Japanese)
August 28 2011
August 22 2011
August 14 2011
Monotribe, MIDI and me
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
MIDI, the electrical side of things
MIDI, the mechanical side of things
What can you do with MIDI on the monotribe?
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 R1 and R2 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 8Quirks/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
August 12 2011
July 21 2011
Why dead horizontal lines are harder to fix…
There’s a (relatively) well-known method of fixing dead lines on the DMG-01 (classic Gameboy) LCD screen which consists of dragging a hot soldering iron across the connection of the brown plastic connector with an epoxy blob, and the glass. The right spot in underneath where there’s normally a black rubber strip. This will reflow the glue, solder or whatever is used for the attachment, and the method can usually successfully fix dead vertical lines.
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.
Why dead horizontal lines are harder to fix…
There’s a (relatively) well-known method of fixing dead lines on the DMG-01 (classic Gameboy) LCD screen which consists of dragging a hot soldering iron across the connection of the brown plastic connector with an epoxy blob, and the glass. The right spot in underneath where there’s normally a black rubber strip. This will reflow the glue, solder or whatever is used for the attachment, and the method can usually successfully fix dead vertical lines.
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.
July 20 2011
July 14 2011
July 11 2011
June 25 2011
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...







































