7:30 – 4:30FP

• Adding in more sounds.
• Looks like the contact sound is never enabled.
• Sounds are all fixed and working. If too many characters come in, the Arduino crashes, but it seems pretty robust. I’m going to give each finger a different pitch tomorrow. For now, hit and movement sounds are off.

Interview at 10:00. Here’s hoping that I find out who it’s with and where it is before I have to leave. Yay. I have an address and contact info.

8:00 – 5:00 FP

• Added set and get byte methods to DataElement.
• Tested sounds. Things are working much better. Nice job, Tom!
• Working through note change/on/off logic in sim – done
• The midi boards need to have power cycled to get a reset?
• PAD lab meeting
• Got the collision sound working reliably. Calling it a day.
• >>{“nm”:f1Ht,”vol”:128,”nt”:84,”instrument”:116}<< // hit
• >>{“nm”:f1Ct,”vol”:128,”nt”:72,”instrument”:59}<< // contact
• >>{“nm”:f1Mv,”vol”:128,”nt”:60,”instrument”:20}<< // move

10:00 phone interview

8:00 – 9:30, 2:30-4:00 FP

• Probably going to take a few hours to go to Salisbury today. Tom needs the time to make the electronics work anyway.
• Adding the note on/off code to SoundWrapper
• Use pitch to set up note changes
• If a new note comes in (either as a new note or from pitch), then we need to turn the old not off, then add a new JSON string that turns the new note on.
• Start thinking about polyphony.

8:00 – 4:00 FP

• Back from the mini-vacation, which was fine until it became horrible.
• Working with Tom on getting sounds to behave. It turns out that a single channel/instrument can be polyphonic, which is very cool, but it means that you have to turn a note on and off. I adjusted the SoundDataObject.update() method so that a JSON element of {"nt":72} will play middle C, while {"nt":-72} will turn it off. Setting {"nt":0} will trigger a reset of the Midi for that finger. Or at least it should. Reset isn’t working. Tom thinks it may be a mislabeled pin.
• Cool thing for the day: https://live.leapmotion.com/. It strikes me that the Leap could be used as the basis for a finger chasing robot.
• Here’s a paper that addresses something like what I’m thinking of: http://www.cse.buffalo.edu/~jcorso/pubs/gyeSMCC2003.pdf
• And a video of some related stuff: http://youtu.be/jQjG1Wyr8Uk. Assume that the puck is capable of motion, and that the fingers of the users are tracked. Then the haptics can be there when the user’s hands touch the table.

8:00 – 2:00 FP

• Leaving early to prep for a long weekend of riding around the Delmarva. I’ll be back on Wednesday. Texting to my cell (410.300.7293) is probably the best way to get ahold of me
• Now that the framework is in place, adding in multiple sounds per finger.
• Got some sounds kind of working, but there may be some state problems. For example, I can turn the amp volume down, but only once. After that, sounds don’t seem to play, even though the volume is back up. Since everything can be testedthrough the serial console, I handed things off to Tom to see what he can do while I’m out.

8:30 – 4:30 FP

• Going to see if all the code I wrote yesterday actually works…
• Everything compiles and appears to be working. I’m going to increase the hysteresis on pitch so it doesn’t update continuously.
• Note that an individual sound that gets two sets of information in between a send will only send the last one. That means that on the Arduino side, a command like ‘sustain’ has to have an implicit ‘start’. Maybe sustain should just have no start required?
• Having a bit of trouble with the hysteresis function. It’s triggering on transitions between +0 and -0. Added an equals(double a, double b, double precision) to SoundWrapper to fix this. Better, but not entirely fixed. Ah – I was clamping the value for pitch and volume inside the toJsonStr() method, so the edge conditions would set newJSON = TRUE. Moved the clamp to inside the set().
• Ordered a cool case and power supply for the electronics
• Added a mapFloatToInt() method in DataElement so we can transpose the values from the sim to the midi easier. The code was looking *very* messy.

OH

• Updated my resume
• Interview for Jessie

8:00 – 4:30 FP

• The communications test ran all night and was still working and responsive when I came in. Time to make some sounds!
• Fixing up the messages, and eliminating redundant/unneeded info in the Json packet – all done, and the data transfer seems much happier
• Added clamping to keep volume and pitch from getting out of hand.
• Moving the hardware initialization from SoundDataObject to SoundController. I think I’ll also explicitly set up the sound objects, at least for now.

8:00 – 4:30 FP

• Working on the SoundController class. Going to try out the basic mechanisms in the sandbox before trying them on the arduino.
• Got the JSON key/value search working. Now I need to organize all the unique sound objects.
• SoundController class is working in the sandbox
• Meeting over at UMBC to go over SIGCHI
• Have SoundController on the arduino and am currently testing.  If all fingers are updating data, the communication gets bandwidth limited. This is ok to work out the sounds, particularly on a finger-by-finger basis, but it will need to be optimized to keep the refresh rate up.

8:00 – 2:30 FP

• Working on finger sound management
• Building the Hysterisis class – done
• Building sound class: volume, id, sound state, ..?
• Adding SoundWrapper into FingerIO

8:00 – 5:00 FP

• The wired network was down since yesterday around 3:30. Bounced everything which didn’t seem to work, but everything came back up in 20 minutes.
• Moving my DataElement/BaseDataObject classes back over to the Arduino for evaluation and testing.
• Grr. Memory leaks. Because I’m using strcat, I needed to ensure that the buffer[0] was set to NULL before starting.
• Looks like that did it. Need to test in the sim, and then it’s time to add the sound in!
• Sound is working. The system freezes after a few minutes’ use. I’m testing the communication in the sim alone now and it doesn’t seem to be breaking. I’ll run an overnight test.

8:00 – 4:00 FP

• More small-footprint, memory-safe JSON parser
• sprintf(buf, “%f”, 3.14) doesn’t work, although the %s and %d arguments do. Looks like you use dtostrf(double val, int WIDTH, int PRECISION, char* buf) instead.
• More perusing the foundations of software. Here’s a page on hashing algorithms: http://codesnippets.joyent.com/user/wastepixel/tag/hashing
• Got everything working on the PC side. No collections – I feel like I’m back in the ’90s:
• 

8:00 – 4:30 FP

• The kinetic sculpture race was a blast. Here are pix: http://www.flickr.com/photos/21701734@N04/sets/72157629972340647/
• Let’s see if we can get sound working today!
• And now a short pause while we install video driver updates…
• Looking through the port_test code
• Having problems with the serial code again. It appears that the arduino is getting into a condition where it thinks that there is always a character waiting to be sent
• I’ve gone back to the test harness, which is having the same problems. It appears that there is something wrong with the workingBuf[]. If I don’t put characters into it, then the rest of the code works fine. Nope, it seems fine. Moving onto the aJSON and DataObject classes.
• aJsonObject* jsonObject = aJson.parse(workingBuf); and aJson.deleteItem(jsonObject); seem to reliably crash things. I think it’s a memory leak. That would explain the randomness of the errors.
• Putting a parser in the BaseDataObject class. Going to see if I can use this hashmap: http://www.arduino.cc/playground/Code/HashMap
• I really can’t believe I’m hand-rolling a parser. Ah, well. Onward.
• Built a DataElement class (with static declarations!) Handles char[16], int and float. Mostly done. Integrate with HashMap and test tomorrow.

8:00 – 4:00 FP

• May the 4th be with you!
• PAD lab – spent some time going over the serial library
• Hooked up Tom’s full rig to the sim. The sensors work, and the sound works using his sketch. He’s going to comment his code and I’ll start to integrate sound on Monday.
• Bent the fingers on the hand to be a bit more ergonomic