Start: 9:00

• Made a new class to help link the gap between the ComMgr and the DataDictionary called ComUtil.  This has all the methods that I wasn’t really sure where to put because they required both types of objects.
• The system should give normalized data to the arduino of the collision so the arduino can decide what volume to set.  This seems to be much better then having the computer give the volume data because who knows what application will be using this.
• Changed the volume data to collision data, removed response for now, set up commands for changing the instrument and note for the fingers, and changed all the data being passed to be an array except the command data because there are multiple parts to it.
• Fixed a problem with the loadBuffer method which was causing random crashes.
• Simplified the initialization of the Arduino side by using for loops instead of setting things individually.
• Took out obsolete code in the arduino sketch

End: 4:00

Start:  9:00

• Finished setting up the test to have the new midi controllers added
• Tried it there was still a tremendous amount of white noise.  I turned off the power supply and noticed that the power led on the Midi shields was still on from the Arduinos power.  I looked up the different Arduino pin modes and found that if its set to OUTPUT, it can put out as much as 70ma.  INPUT mode, on the other hand, has high impedance so it produces much lower current.  The reset pin has to be set HIGH or the chip is in off mode, so I tried switching it to INPUT mode so it didn’t output excess power.  This resulted in the white noise being almost completely eliminated and the chip’s power led now turns off when the power supply is off.  For some reason, both examples on the sparkfun page show this pin being set to OUTPUT.  I posted this solution on their page so hopefully others will be helped.
• Setting multiple channels to play the same note on the same instrument gives it a fuller sound.
• There was a problem that I had with the end of the buffers data.  Clearing the buffer after each import solved it.
• Changed the volume to accept doubles between 0-100 instead of decimal percentages.
• Added the an instance of the interface to the main.  Was able to get the pressure sensors to show up.
• Changing things around so that the simulation runs through the computer instead of autonomously on the arduino.

End: 5:00

Start:  1:00

• Tinned the leads which kept slipping out of place.  Everything is much more secure now.
• Hooking the wires to the power supply was a bit annoying.  Once I get everything working I will make a power bus so only two lead need to go to the contacts.
• Everything is powering up without issues.

End:  5:30

Start: 9:00

• Add the midi controllers to the board.
• Put back together the stuff I took apart when I was testing stuff.
• I was a little confused with the interface code.  I figured out how to set the display values though.
• The interface seems to be working in the testing sandbox.  I need to add it to the main now.
• There’s a few issues with the hardware.  Mostly wires are just not staying secure.  I need to tin some leads When I get in tomorrow to make them more secure.

End: 5:00

Start: 9:00

• Tested out the new midi controllers.  Tried it with only the Arduino and my headphones and there is still a buzz.  Now I know I didn’t damage the other ones.
• I tested the balance and pan, same issues.  Oh well, I will just have to use one controller per finger.
• All the variables are now passing properly between the arduino and the pc.  Its set to do one send and recieve per cycle.  The buffer has a hard limit but you can easily add objects to it for transmission.
• In the process of integrating the data into the interface.  I started changing it into a class.  I figured this was best in order to keep the main from getting cluttered.

End: 5:00

Start:  2:30pm

• Spent the first half of the day putting up our office window insulators.
• Added methods to the interfaces class to change the data which has pointers in the datadictionary.
• Added methods for displaying the volume and pressure data.

end : 6:00pm

Start: 9:00 am

• Tutorial for openGL in FLTK:  http://www.fltk.org/doc-2.0/html/opengl.html
• Added the boxes for GLwindows in the interface
• 
• Named the components to make it easier to program.
• Made note of the position and size of the components because I may want to make the finger parts a class
• Made it so double clicking on any of the GL boxes initiates a bigger window.

End: 5:00pm

Start: 9:00

• Today has been a bit slow on progress with the company lunch and having to leave early.
• I  continued the work I started yesterday with integrating the interface to work with communication classes.  I will probably have this working by some point tomorrow at least to where the sensor and volume data appears in the appropriate boxes.
• I wrote a sketch to test the new midicontrollers when we get them to see if somehow I damaged them.  I am going to use the other arduino and isolate it from all other electronic by using my headphones.  If it turns out they were blown I’ll have to figure out how to connect them in a safer way.  This could be amperage problem or the way they were connected to the amplifiers.  Otherwise I will just use 1 controller per finger.

End: 2:00

Start: 9:00

• Ordered two more midi shields.  This will help with the problems i’ve been having as well as make the programming a bit easier.  Balance and Pan seem to work but not perfectly so its better if each finger has its own.  I will also make sure I test with headphones these to see if the distortion is something I did.
• Edited the code to accommodate one midi controller per finger
• Added more error checking to send receive methods of the commgr class.  It kept crashing when the buffer was empty before.
• Exported the code files for my interface from FLUID.  Started changing it so it can accept the data from the arduino.

End: 5:00

NOTE:   The previous version of our midi controllers had voltage  regulation problems.  It is possible that its sensitive to the amperage and when I hook it up to our power supply it overloads it.  I think I only used the arduino or powering the first one though so I don’t know.  Voltage issues would make sense but its supposedly fixed.

Start: 9:00

• Tried to solve the sound distortion problems
• Found out that in order to pan or balance the most significant bit is the sign.
• Took another shot at trying to resolve the hum which seemed worse now.  It just occurred to me that this might be because two channels are at max volume now, instead of just one.  I will have to remember to check this tomorrow
• After many failed attempts to fix the problem, as well as the pan and balance function not being able to completely isolate the channels, I think its best to get two more midi shields and just have one for each finger.  The sound is pretty clear when only one channel is playing.  Not sure why this issue is happening, I even tied to isolate it by using the arduino that isn’t hooked up to anything.
• The headphones port makes the same noise when not hooked up to the amplifiers.  It seems to have something to do with the ground not being isolated but everything I try either makes it so the midi commands won’t execute or theres not enough power for anything.
• The reset pin has to be set high or the device is off.
• I can eliminate the some of the noise by putting the channels on low volume til they are needed the main amplifier already does this though so its more a problem of the two channels.

end: 5:00

Start: 9:00

• Changed all the buffer sizes to accommodate more data.
• Was able to get multiple structs to pass and import properly
• Added a check command function to the arduino side.  This checks for a new commands and executes them.  Commands are in hex so that the first number can be the finger number.  example 0x11 would send the change volume command to the index finger.
• There was something the sparkfun guy sent me to help wire the midi shields to an amplifier.   For some reason the page isn’t coming up,  I’ll try again monday or have it sent to me again.  http://www.sparkfun.com/datasheets/Widgets/MP3Trigger/vs10XXan_output.pdf
• Phil said he could help me get the pressure to volume plotting working using openGL.
• We put rubber feet on the stand which helps it not metalically rattle the desk.  I am not sure how much this helps because I haven’t fixed the distortion problem yet.

End: 6:00

Start: 9:00.

• Showed Clift the prototype.  He liked it.
• Figured out what was causing the index and thumb to short out when pushed at the same time.  One of the amp lines had the polarity of the capacitors reversed.
• There are some sound quality issues.  I will try tinning the leads tomorrow to see if it just a weak connection
• Figured out part of the quality issue is some of the fingers had their input lines reversed.
• Another thing to look into tomorrow is if the quality is bad simply because it keeps getting noteOn commands.  The pervious better sounding sketch made sure it only did this on initiation.
• Worked on building up the communication stuff.  Realized that I was only able to send one struct at a time, so I added a loadBuffer method so that I can send all at once.  Before the buffer was in the main now its part of the commgr class.  The DataDictionary import method seems like it should work as is because it should continue parsing the buffer til it hits a null.

End: 5:00

Start: 9:00

• Built the interface.  A little strange but it seems FLUID does not have a standard label that isn’t attached to anything.   I didn’t really need it but still found it strange.
• Currently the PC side is a sandbox so I’m building it out to have a more defined purpose.  Now that I have things a bit more together I found that I really don’t need to pass as much data as I thought.  All it needs is sensor data to the pc and command + data going to the arduino.
• Still needs a bit more done before I can link the data with the interface.

End: 5:00

Start: 9:00am

• Had some trouble getting FLTK to build.  Usually I am able to track down binaries for things like this, but in this case, there is a project file in the ide folder which allows Visual Studio to build it easily.  A note for the next time I run across source code with no project files is that I should be able to run command line compiles using the .make file.
• Still lots of files and no .lib/.exe files in sight…  I thought maybe it just wasn’t set up right but when i look at the project property files it properly tells it to build exe/lib files.  For some reason all I getting is the object files.  I was able to run demo from the IDE but still don’t see the .exe file anywhere.
• Finally found where everything built to.  Its in the test and lib folders of the root directory.
• Lots of cool demos, looks like you can do a lot with it.  One of the cooler ones involves fractals.  I didn’t know how useful fractals were in making blocky graphical objects more detailed.  The code for this example will help me when I try to figure out how to add a gl window within GUI.
• The callbacks were a bit confusing to me.  The one for buttons accepts two parameters.  The first is the function name you wish to call and the second is void pointer to the data.   The second parameter is optional and is limited to only passing one void pointer.
• Very good tutorials for both setting up the IDE and manually coding, as well as using FLUID: http://seriss.com/people/erco/fltk-videos/
• The videos also cleared up .make files for me.  I tend to use VS for the most part, so the make files are built into the project.  I am not sure make files can be imported  into VS, but it would save manually setting up project properties every time.
• Should be ready to build the UI

Planning

• Things needed for the UI:  Sensor data, current volume(optional), instrument selection(slider/numeric entry), note selection(slider/numeric entry), disable button, menu bar with a save/load function to save/load the current settings
• I think these controls will run across the bottom.  The majority of the window will be for the openGL simulation.
• The DataDictionary will be used to hold/sync the data on both sides.
• Change the color of the text box to show if the force is neutral negative or positive from baseline
• Something that might be useful for analysis is if we could graph the increase in volume/pressure.

End: 5:00pm

Start: 9:00am

• I am pretty confident the electronics are working well enough to move to communicating with computer.
• Reviewed the pc and arduino side classes for data transfer.
• Passed a string from a sandbox sketch to the computer to refresh my self on how to do this.
• Got the sensor data to display in my pc console.
• Considering making a graphical ui for adjusting the instrument and tone of each finger so we can experiment better.  Not sure how hard it is to integrate this into a console application.
• Looking into how to do this I found you that you can’t simply add a gui to a console app but it can be done in a MFC application.
• Asked Phil about the GUI.  He recommended FLTK.  (http://www.fltk.org/)
• I forgot about the thumb and index finger shorting out when used at the same time.  Will have to remember to look into this tomorrow.

End: 6:00pm