jbartee

wow, this is really picking up: http://www.synthtopia.com/content/2010/02/25/behold-the-commodore-64-keytar/ I wish I'd spent more time on the video, or just waited to release a video. Giana isn't done yet! Not that I mind the praise of course...

Leave it to me to miss an obvious joke!

A diagram for the softpot circuit? It might not help you very much since what I'm doing is really simple. I just need the softpot to behave exactly like a pitch wheel, in other words outputting constant 2.5 volts unless it's being touched. I'm going to implement some simple smoothing, but it won't have any of the elaborate sample and hold circuitry of something like the appendage for instance. I'm working on this circuit with a professor of mine, so out of courtesy I'll have to check with him about sharing it, but I'm sure he'd be cool with it.

Thanks so much Thorsten! It's really an honor to be featured on the blog. I will have more documentation up after I finish the softpot circuitry, and I'm of course happy to share my patches, although I only have a few at the moment.

Here's a super ghetto, very basic video of the thing: http://www.youtube.com/user/crudface#p/u/0/1LZUH0p6cXc

Thanks to all for the kind words. Sorry about that and a big thanks to nils for cleaning up the post. I tried to attach the images to my post but it didn't seem to be working, I must have just screwed something up. My direct inspiration was Ghostbusters, but Mad Max works just as well! The whole 80's cyberpunk "guts on the outside" approach is something I'm really in love with. The external ribbon cable running up the side (which is completely non-functional btw, it's purely aesthetic) is directly lifted from the back of the proton packs: Steve Jobs is an idol of mine, even though I'm sure he'd completely hate my design aesthetic!

Hi everyone, So I'm just putting the finishing touches on my build and thought I'd share some pics. I wanted to thank TK for developing and maintaining such an awesome platform, Smash for the excellent service and quality products, and everyone on the forum for answering my questions. A full work blog style thing will be up eventually with video and a bunch of other stuff. For now here's what I've managed with my crappy iphone camera! edit by nILS: I fixed the topic and attached the pictures (offsite doco bad...)

While in principle using a sound producing toy to test continuity might work, it really isn't a good idea and I definitely wouldn't rely on it (although it's a clever idea!). Just buy yourself a decent multimeter -they're not that expensive. You're multimeter probably already checks for continuity anyway, even if it doesn't have a beeping function. This just means you'll have to keep one eye on the multimeter display when doing continuity checks.

Just wanted to update that I solved the problem, but the transistor schematic I posted ended up being unnecessary. I simply ended up using 64 220 ohm resistors so that the current gets controlled uniquely for each LED, instead of using one resistor for each column. This is better practice anyway, and it completely eradicated my dimming. I guess the problem had nothing to do with current limits at the shift register, and everything to do with slightly different operating parameters on each led, which was causing the current to branch strangely across the parallel circuits.

This should really be stickied somewhere, or better yet rolled into the official docs. I had the same trouble with Smash's din boards. This issue is actually just the so/si pins, which are only functional in one row, while all others are functional in both rows. To make matters worse, I seem to remember that the orientation is exactly mirrored between the dout and din boards, I guess to correspond with the row orientation on j8/9 on the core module. It's super confusing.

This might not be your problem, but depending on the encoder brand you're using, they can be quite twitchy. I had several of my alpha brand mouser encoders stop working after the pins got just *slightly* bent. Bending them back straight fixed the issue. I actually had to open up one or two and bend the contact wipers inside the encoders. They're very simple mechanically, so if the issue is with the encoder and not with the wiring, they're easy to fix.

Just to clarify what I mean, here's a crude schematic. This way, when the pin is high then 5 volts are supplied to the column directly from the power rails instead of via the shift register. I implemented a simple version of this on a breadboard (just one LED) and it works in principle. Guess I'll throw it all together and see if it fixes the issue!

Okay, after thinking about this a little more I think I should be able to fix this using 8 npn transistors switching plus five volts through the columns. Since I'm working with forward voltage to the anodes, no inversion should be required for the dout. Does this make sense? Edit: actually, it seems like I'll need 16 transistors in order to invert the output... so two npn transistors to each column. Unless I'm totally off my rocker.

Thanks Wilba and TheProf for getting back to me so quickly! This basically confirms what I thought was going on. Using transistors makes a lot of sense. However I have two questions: First, my matrix is arranged with common anodes in a column, not cathodes. It's all wired exactly as described here: http://www.ucapps.de/midibox_sid_cs/mbsid_v2_dout_default.pdf How would this change what I need to do? It seems that this implies the problem is not with how much current can be sinked, since lighting up a whole row (common cathodes) gives me no trouble... or perhaps I'm fundamentally misunderstanding something? Second, when you say I need to invert the outputs of the DOUT, I assume you mean in the setup.asm? urggghhh..... well, one more reason to go through the arcane process of setting up the development environment I guess.

So I'm nearing the completion of my midibox sid, and I've run into a strange issue. All the LEDs in my 8*8 matrix are a nice even brightness, but only if there is no more than one led lit per column. As more leds are lit in a given column, the brightness of all the leds in that column begins to dim. Adjacent columns are not effected, and neither are the other leds running off the same DOUT module that are not in the matrix. There shouldn't be a problem with my power supply as it's capable of outputting 2 amps. In fact the current before the shift registers seems not to matter; I tried putting a couple thousand uF capacitance directly behind the power input of the concerned dout module to buffer the current, and it had no effect; therefore it seems like this is an issue with the current throughput of the pins on the shift registers, or something to do with the duty cycle of the multiplexing. I'm curious though because I haven't seen this behavior on videos of other completed midibox sids. I'm using 5mm red leds from SmashTV. I've tried a variety or resistors and the issue persists no matter what. So what's going on here? Is this a limitation of the chips? Some other problem? 5mm a no no? Any help at all would be truly appreciated...

I had the same thing happen to me recently when I was troubleshooting midi connections. As philetaylor pointed out to me in the blocks indicate that the lcd isn't being initialized because mios has been corrupted, which most likely happened during your setup.hex upload.

Okay. Just in the interest of being absolutely sure, do you get the same measurements at RD1 and J9:SI when the PIC is removed? It sounds like you've already narrowed it down; If you measure 5 volts before R9 and less than 4 directly after, then the problem must lay with R9, either at the solder joints or somewhere along the traces. Check for cold joints, reheat or desolder as necessary.

Glad the analog inputs are working properly! as you can see from this schematic, J9:SI runs through R9, which should be a 10k pull up resistor. Unless there's something wrong with your power rail further up stream (do you measure 5v at other points on the board?), I'd start by double checking your work around R9.

just to clarify what I mean: http://www.ucapps.de/mbhp/auaimbctg.pdf

I'm not sure about the missing step in -64 to 63 or 0 to 126, but the spurious CC's sound like a noise issue. Have you grounded all unused analog inputs on the AIN module? If you have and the issue persists, it's possible that the wires you're running to the pots are too long, cross something introducing interference, or both. The length of the wire might also be producing a small voltage drop, which *could* explain your missing steps as well.

Well, that sure beats the hell out of the dremel I've been using for my plastic cuts. A saw like that is a little out of my price range, but it's hard to argue with your results. Beautiful work!

This looks great! What did you use to cut the case like that? That's a very precise, tight seam.

Interface in should go to MIOS OUT, and interface out should go to MIOS IN! Disregard that, I'm completely wrong. What you have should be correct. Dyslexia! Unless this is a hardware problem of some sort (which seems to be mostly ruled out), something is different between our computers that is making/breaking midi java compatibility, but since the relevant applications/libraries seem identical, it's hard to say what that is. Maybe Wilba's suggestion to borrow a windows box is the best option here, although it would be great to figure out what's going on with OS X, since I recall a couple other people having major problems with snow leopard as well, despite the mandolane fix. I wonder, do you have any other third party libraries installed that might be causing conflicts? mmj for instance? I've heard reports of the new 64-bit mmj actually breaking midi under 10.6.2.

Hmm, we seem to be running the exact same version of java as well as the same version of snow leopard. v2_96 of mandolane is also what I'm using. As Wilba said, the 8 byte hex string is a good sign and is probably the core sending its periodic upload request. This would definitely indicate some kind of problem with mios studio and java, but it's strange that it works on my setup and not on yours, since they seem equivalent. Forgive me if this is completely out of line, but are you sure you have the ports routed correctly in the mios studio midi setup? It's not as intuitive as it could be, and I had it incorrectly configured when I first started using the program.

Sorry to bump an old thread, but I just wanted to chime in that I'm also experiencing this exact issue. Definitely weird.