Project Logs

Collapse

• That's a wrap!

  Jeremy Weatherford • 12/11/2014 at 19:08 • 0 comments

  Got everything recorded today with the help of two awesome people, Mike Anderson on audio and Josh Etheridge on video. I felt kind of useless at this stage, since I was just there to push the play button and make sure nothing caught fire. Mike and Josh have volunteered their time to record, mix, and edit the video, so now I get to take everything apart and daydream about how epic the finished product is going to be.

• Limit switches would have been awesome

  Jeremy Weatherford • 12/11/2014 at 15:14 • 0 comments

  Somewhere along the line I considered and rejected the idea of wiring up the limit switches on the scanners and inkjet, thinking it would be too much trouble. Instead I've been moving each of the motors to a reasonable starting position before starting playback. After several near-misses (always keep a hard-wired "motor power off" switch handy!), I'm reconsidering that position... there are simply too many ways for the software to break and potentially cause something to run out of limits. Additionally, re-homing the motors each time is getting pretty old.

  In order to mitigate the homing problem, I taught the Arduino to reposition the motors at the end of the song (or when it's stopped by ejecting the floppy). That should make it a little bit easier to run headless (without a laptop driving). I had several more near-misses in the process of programming that function, though, which tells me I should have just wired up the limit switches in the first place! I don't know if any of the scanners or inkjet could physically self-destruct by hitting mechanical limits, but I'd prefer not to find out. The floppies are a little smarter and won't step past their limits.

  Got a director lined up, hopefully recording today, woohoo!
  

• Major timing improvement

  Jeremy Weatherford • 12/10/2014 at 14:42 • 0 comments

  The weak point in the playback chain for this project and the music box has always been the PC (or RPi) sending note data to the Arduino. Most of the time it worked great, but occasionally a timer wouldn't get called in a timely fashion and the playback would glitch. That's not a huge problem for a one-off project, but this time I'm planning to record the audio and video tracks separately and then sync them, music-video style, so I need the performance to be as repeatable as possible.

  So yesterday I finally dug into the docs and figured out how to put the 10kbytes of note data into PROGMEM instead of RAM so the Arduino could hold the entire song without needing an external source of note data. By the way, I think it's criminal that the Arduino IDE can't detect when you're allocating too much SRAM for variables -- the sketch just silently fails to boot. Or is that fixed in newer bootloaders now? I was worried about the flash access being slow, but it's fast enough to index through the note data every 0.4msec. Playback is now bulletproof and doesn't require an external laptop.

  To add the finishing touch and make the rig completely self-contained, I now have it triggering playback when a floppy disk is inserted in the top drive, and stopping when it's ejected. :) I'm also planning to have it re-home the motors to the start position when the disk is ejected, so that I don't have to do that manually every time (since that does require a laptop connection at the moment).

  If all goes according to plan (and how likely is that, really?) we should be recording tomorrow.
  

• Getting close

  Jeremy Weatherford • 12/08/2014 at 21:11 • 0 comments

  After several hours of soldering to extend cables, everything is wired up and waiting in the studio... won't be too long now!

• Some improvements on pitch accuracy

  Jeremy Weatherford • 12/04/2014 at 06:48 • 0 comments

  Took a look at Moppy (the floppy music program for Arduino) and identified some improvements that could be made. Rewriting everything to count 40usec cycles instead of comparing micros() improved efficiency, as did being careful about data types -- changing unsigned ints to bytes where possible, and getting rid of the unsigned longs that I used when everything was measured in microseconds. I'd love to get an even faster cycle time, but 40usec is decent, and it seems to crash at 35 when things get busy, so that may be the working solution for now.

• Initial commit

  Jeremy Weatherford • 12/03/2014 at 14:41 • 0 comments

  Project is well underway, so I thought I'd publish some work-in-progress photos and information.

  So far I have the RAMPS board happily driving three different scanners. Two of them have their CCFL lights hooked up to the MOSFETs on RAMPS for blinkenlights. Apparently I blew up the CCFL driver on the third scanner by connecting it backwards, so it has some LED strip lighting instead.

  The four floppies were the easiest part, since they have their own electronics onboard. They just need +5V and GND on the power connector, then ENABLE, DIR, and STEP pins connected to the microcontroller. With the pins configured as OUTPUT, their sense is inverted, so digitalWrite(LOW) means to ground the pin, which makes the floppy actually do something. ENABLE needs to be LOW in order to do anything with the stepper (and it turns on the light, as a bonus). The floppies I have are 80 steps in each direction, and have built-in limits (electrical or mechanical) so it doesn't hurt them too bad to run into the limits (I hope, since it's the only way I have to home them).
  

  I have the PC software mostly done, it reads raw MIDI files this time (instead of needing a MIDI-to-XML conversion), maps channels to instruments, reduces them to monophonic note sequences, applies octave shifts as needed and some post-processing (like a staccato effect to repeated notes) and sends commands out via serial to the Arduino.

  I'm a little worried about the Arduino software because it's struggling with pitch accuracy when driving 9 instruments (go figure). Some more optimization is definitely in order. I may also have to punt and drop the higher parts down an octave where the timing accuracy isn't as important. I'm already dreaming about using an FPGA as a frequency generator to get the timing more accurate... maybe next time.

  Tentatively planning to set up and film this the week of December 8th, stay tuned for updates!
  

View all 6 project logs