Categories
Uncategorized

SoundProp – Sound Effects with Processing & MIDI

Sometimes you forget to document things, and sometimes you try to get ahead of the game. Back around 2009 I was one of the organizers of Web414, Milwaukee’s Web Community Meetup, and at some point Gabe and I turned it into a live talk show. Yeah, I don’t know how we managed to do that, but… it happened. We had guests and we interviewed them, and even had a musical guest once! Anyway, one of the things I did was add sound effects to things because… well, I love that kind of shit. So yeah, my first “Sound Effect Board” was a web page on my web site I called ShowProp which used Flash to play some sound effects at the push of a button. (Still there, still mostly works. Here’s another silly web/sound thing from 2010, Evil-O-Mator.)

Where was I? Oh yeah, sound effects! Typically I was the co-host while Gabe was the primary host, so I would work the sound effects board at the appropriate (or inappropriate time.) It was fun.

And then I started messing around with Processing in 2010 and eventually started a re-write of ShowProp that would run locally on my computer rather than a Flash-enabled web page. (Flash is Dead! Sort of…) Processing is still very much alive, and I use it fairly often for creative coding, and hey, I figured since it’s 2020 it was time to update things.

I should mention that in 2019 I got my first “real” MIDI device, an Arturia Beat Step. A local synth guy was selling it for… wow, less than half the price of a new one. (I guess I got a deal!) I say my first “real” MIDI device because I’ve built them before, for myself, for museum exhibits, etc. but I had never bought a commercial unit before. Since I had this around, and I enjoy screwing around with MIDI, I dug into MIDI support in Processing, and…

I ended up redoing my old ShowProp sketch to be SoundProp, which is a Processing sketch that accepts MIDI input and plays sounds. It’s the second fanciest sound board style device I’ve used this year. (Yeah, I use others.) I also discovered the sound playing capabilities of Processing have greatly improved over the years, so that was an added bonus.

So basically, my sketch has a bunch of audio files, and each is mapped to a MIDI pitch which is sent by one of the 16 pads. Now, because it’s MIDI and not key commands it always works, no matter what application is in the front. No fumbling around to pull up the right window before you press a key or click a mouse. All the Sounds! All the Time!

The UI is quite minimal. It’s just a window that is 250 pixels by 130 pixels. I typically just launch the application and minimize it. (And hey, this will run as a native—well, Java—application on macOS, Windows, and Linux… in theory.)

If I get around to it I’ll clean it up and upload the code, and maybe create a video showing it work, though it’s not really that exciting, but hey… 2020, whaddaya want!?

Categories
Uncategorized

3D Printed Skull

I printed this skull back in 2019. The original file is this skull from Thingiverse. Now, it’s October 2020, so yeah, this took a while. I mean, I had it all printed long ago, and then I did an experiment where I covered one half of it with wood glue, and the other half with Smooth-On XTC-3D High Performance 3D Print Coating. I did this because I hate sanding prints (or wood, for that matter) and I wanted to test both methods of coating. For this application, I don’t know that it made much of a difference, but that might be due to the organic shape, and the fact that I primed and painted it afterwards…

Somewhere I’ve got photos of the coating process, but since they are nearly a year old now, I forgot to locate them. I do remember that the glue method took many more coats than the Smooth-On method, though of course glue is a much cheaper material…

You’ll notice the skull also looks a bit “weathered” and yeah, that was another test. I am not an “authentic movie prop maker” so I don’t know all those methods, and what I did was actually rub mud/moist dirt all over this thing and then let is sit for a long time. I eventually washed off a lot of the dirt because, well it was really dirty looking.

There are a few delicate parts of the print, and I’m pretty sure I broke off at least one piece and glued it back together. Again, since this is a pretty organic shape, no worries. And yes, it is pretty much life size.

I printed it in two pieces after slicing it in half, which means the surfaces touching the print bed are not visible as they are in the center of the skull, glue together. There’s a pretty bad seam that I never managed to get that sanded down quite right. I probably should have just taken a Dremel to it.

Overall I’m fairly pleased with how the skull turned out for a 3D printed object. It’s rare that I print “decorative” or “sculptural” prints since most of my prints are internal to some sort of enclosure with electronics inside.

Remember, the great thing about skulls is that we’ve all got one! (At least I hope.)

Categories
Uncategorized

micro:bit Powered Xylophone

A recent fun project over at Brown Dog Gadgets is this automated xylophone controlled with a micro:bit… Check out the build guide.

Full instructions including code and some helpful tips on choosing a (toy) xylophone that will work for this project. (There’s maths and angles involved.) We’re basically controlling two servos to move a mallet left and right and then down (and back up) to strike a bar.

You can control it by playing it like a keyboard, just press the buttons, or you can program and store songs for automated playback later.

The (toy) xylophone isn’t really tuned very well, so we may be working on a larger project that uses a larger instrument. Also of note is the fact that the micro:bit out of the box can only handle three servos (without extra hardware) so we might switch to another board for the next iteration.

As usual, and since we’re using LEGO compatible servos, there are LEGO bits involved, which made building things quick and easy. (And don’t worry if you don’t have the needed LEGO parts on-hand, we’ve listed the parts we used and linked to where you can get them for cheap.)

Here are a few slightly out of tune songs…



Categories
Uncategorized

The LED Burns Bright

Disclaimer: I have destroyed light emitting diodes (LEDs) in the past. Typically on purpose, by feeding them too much voltage until they burn out in a bright flash. It’s fun to do if you’ve got a variable power supply with a dial and can slowing crank up the voltage.

That said, this is about trying to destroy an LED without trying to destroy and LED. (Or maybe, trying to not destroy an LED but still breaking the rules.)

The rules you say? Yes. As in, you need a resistor when connecting an LED to an Arduino. This is just, like, a fact. You can get away with putting a resistor-less LED on an Arduino for testing, or learning, or a quick demo, but to do it right, always add an appropriate resistor inline.

There’s a web site called LEDCalc.com that helps you determine the appropriate resistor for the LED and voltage you are using. Tell it you’ve got 5 volts, one LED with a voltage drop of 2.0 volts, and want to give it 20 milliamps and it will tell you to use a 180 ohm resistor. (There’s fancy maths to figure this out as well, but I’m an artist who does not excel in maths.)

In the photo above you’ll see a (very bright) yellow LED connected to an Arduino Nano. (This Nano specifically is manufactured by Elegoo.) I have no resistor in my circuit, I have nothing else connected, just a single LED on a single pin, with a digital write to turn it on at full power. (As it were.)

Okay, so at some point the LED will be destroyed, or the pin on the Arduino will be destroyed, or the Arduino itself will be destroyed, or some component will fail. But… when will that happen? I’m a week into this experiment, and so far, all is well. Will it take a month, a year, a decade? Is the time to failure completely unknown, and completely random. Is it pure luck that this works, and it could fail any second now? Do I need to blink it on and off to get an inrush of current to the LED to stress it more?

I found this Arduino MEGA with 27 LEDs connected to 27 different pins, which I used for testing, and it seems fine as well. Granted, I don’t have all LEDs on at the same time for any real length of time. It’s a blinkenlights thing so lots of off time and some on time.

I’m now really tempted to change the code so it just turns on all 27 LEDs at once for an extended amount of time. I’m a bit curious about this whole thing now. I understand the reasoning behind current limiting resistors, but I’m wondering how that comes into play in the real world. One of the trickiest things I’ve dealt with when designing circuits is that they should work, they work on paper (or on the screen) but in the real world something goes wrong. EMF, physics, gremlins… whatever. Something you don’t expect comes along and screws things up… But this seems like the opposite, where we plan for what should/could go wrong, but then it doesn’t.

I probably need an actual Electrical Engineer to walk me through this one…

Categories
Uncategorized

Game Boy Camera Dumper

As previously mentioned, I finally got my Game Boy Camera up and running with the ability to transfer images to a computer. In this post I’ll outline the method I am now using to do that, which is an update from the first post.)

I put the code I am using on GitHub in a repository called Game Boy Camera Dumper. (I wasn’t sure if I should use the word “transfer” or “capture” instead of “dumper” but I’ve always been a fan of Perl’s Data::Dumper module, so that clinched it.)

You’ll need Python3 installed, along with the pySerial and argparse libraries. pip (The Python Package Installer) should get those installed easily enough.

Once you’re ready you type python3 gbc-dumper.py /dev/tty.wchusbserialfa440 in the terminal (after you are in the right directory) and wait for the magic to happen… (And yeah, you don’t type /dev/tty.wchusbserialfa440 part unless that’s the USB port on your computer that your Arduino shows up as. On Windows it’ll be COM3 or something else, on Linux… if you use Linux you’ve probably got this part figured out already.)

The script will echo back the serial port you specified (yeah, I should add something more useful there in the way of feedback) and then wait for you to “print” the photo from the Game Boy.

You may also notice a new file appear. Our output file gbc-output.txt has been created, thought it’s still empty at this point.

So move over to your Game Boy Camera Unit and do the print thing! Send that data, and the Game Boy screen will show a “Transferring” image…

Here comes the data! You’ll see the data from the Game Boy/Arduino flowing into the terminal. It is also being saved to the gbc-output.txt file as well…

At some point the data will stop flowing. You can either end it here, or continue to “print” photos. The script will keep adding to the output file and easily hold all your images until you decide to stop. I usually transfer all of the photos on my Game Boy. (Though I don’t delete them all until I’m sure I’ve got them all safely on my computer.)

How do you end it? Hit Control-C to stop the script. It will end, the file is written to and closed, and you’re done. For now. (I should add that bit of instructions into the script.)

Here’s our output file. You’ll want to open it and copy the contents to the clipboard. (Or you can just cat gbc-output.txt | pbcopy on macOS.)

You can head over to the decoder (choose V1 or V2 depending on what firmware your Arduino is running) and then paste in the text you copied and translate all that text into beautiful low-resolution images! (And then save them.)

Because I try not to rely on anything that isn’t running on my own computers if I don’t have to, I run a copy of the decoder locally, and I’ve stripped it down a bit to just show me the essentials. (Big thanks to Brian for publishing and sharing his work.)

Oh, there is one more thing I do. I upscale the images to 1280 x 1152 using another Python script. I made it a drag ‘n drop application on macOS using Playtpus for ease of use. (The Python code is pretty simple, and you can see it here.)

That’s my process for now. In a discussion with another Game Boy Camera enthusiast I suggested that it might be possible to write a Processing application to dump the image data, display the image, and then save the image to disk, but I don’t know that it’s something I’ll take on anytime soon.