Here’s a fun one. On some Macs the screen brightness keys are actually recognized as the F14 and F15 function keys. Which means when you build your own keyboard with those keys they change the screen brightness. Yuk. I found a post that explained how to change that, which involved going into System Preferences -> Keyboard -> Shortcuts -> Display, except… it’s not there. (See the image above? Not there.)
But wait, it is there after you plug in a device you built that has F14 and F15 keys. (See below.) So once you plug in a device you built that has F14 and F15 keys, the Display option will appear and you can disable the brightness thing by deselecting things. And yes, you can still totally adjust the screen brightness by using the keys on your normal keyboard.
This post is about 95% for future me, and 5% for someone who needs to figure it out and finds this post. You’re Welcome!
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!?
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.)
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.)
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…
