April 24th, 2005

I havn't entered anything in my journal recently primarily because I havn't done anything with the project recently. However I recentely implemented a zoom, allowing the user to zoom in for more accurate timing, or zoom out to see the "big picture". This was easy to do because from the beginning I was planning on adding a zoom, so all I needed to do was change the constant to an editable value.

This will probably be the last change before my presentation, but watch out for documentation to start showing up on the site.

March 17th, 2005

Since I last wrote I finished creating the outlet box. It still needs sides, some sanding and a coat of paint, but other than that it is exactly as I want it to be. In summay my box takes power from a standard wall outlet and spreads it across 8 outlets. The flow to each outlet can be controlled by a computer via the Gadget Board and relay switches. I decided to connect the Gadget Board to my outlet box with a network cable, providing an easy way to disconnect my box from the computer, and allowing greater distances between the two. I have included some screenshots of my box as well as a video of it in action ( although the sound was added to the video, it was the actual song playing during the video, I just don't have any way to capture audio and video at the same time. )

Images
  
  
 
Video

March 14th, 2005

First off, I must apologize for the missed week. It was missed primarily because nothing really happened with my project that week. This week however is a much different story. As I mentioned before I am shifting my focus to my application of my project instead of the editor for a while. What I ended up deciding to do is to create a series of outlets (4 couples, or 8 total) that can be individually controlled by the computer. Then I can use the controlling application along with SoundSync to create a light show (or some other electrically powered show) that goes along with music.

This application added a whole new element to my project, a physical element. The actual programming was done in about 2 hours, including research. However I have spent many many hours doing electrical planning and wiring as well as creating the box for all the wiring to be hidden in. For a while there was some concern dealing with using power from an existing outlet, fearing that it may be too much (and in turn dangerous). I have put these fears aside, deciding to be extra careful. My other major issue that I ran into is that I don't want my outlet box to be right next to the computer. To solve this I decided to connect the Gadget Board with the outlet box using a standard cat5 (network) cable, and then ground the switches using the outlet's ground. I have tested this on a small scale and it worked great. I'm still waiting on all 8 switches, but am confident that it will work.

The greatest moment this last week was when I finally plugged it in and got lights turning on and off to music. I think that that has been the greatest moment in my project so far. I finally manipulated something outside of the computer.

February 20th, 2005 (current source)

I have my first real release!

This week I have primarily been working on the features that I wanted to include in my first real release. The main features that I wanted were icons for commands in the tree view that correspond with the color of the triggers in the editor, a text box to display the current time that the trigger is at and for all of the buttons to always be available.

The first of these problems was the most difficult. In order to set an icon in a tree view, you must use a CBitmap. Unfortunatly the functions provided by MFC for CBitmaps are quite limited, only allowing one to edit the bits directly. So in order to create the bitmaps I wrote a function that would manually set all the bits to the correct colors, then this bitmap would be used in the tree...in this function lies a major problem though (one that I have yet to solve). In order for the tree to display the bitmap correctly the bitmap must be set up to be device dependant, and I can only guess as to how the device stores bitmaps. On my computer and the computers in the lab, each pixel has four bytes: blue, green, red, and then a byte that seems to be useless (I have tried various values for it with no change). However there seem to be some computers that use only three bytes for each pixel, resulting in inaccurate colors and striping in the icons. I may eventually solve this bug, but since it is very difficult for me to accurately test, it is a low priority.

The next of these problems was a very easy one to solve, and that is simply adding a text box to the toolbar and having it update as the audio is being played. Adding the textbox was simple (using a sample program from CS350 (Event programming) as a guide. Getting it to update was a bit trickier, since neither the view nor the document can get a handle to the main window (which has the toolbar) and the main window can't get the document. What I ended up doing was simply adding a ON_UPDATE_COMMAND_UI for the textbox in the document, that sets it's text to a user readable representation of the position of the cursor., this allows the time to always be accurate.

My last problem was relatively easy as well, but had some frustration. Only the toolbar buttons for the active view were able to be clicked, but it is important that all buttons be active at all times. Unfortunately MFC will only pass messages to the active view, and through all the routing they will never reach an inactive view. This means that I must manually reroute the messages. In the frame window I added handlers to catch the messages, set the active view to be the one that should have received the messages, and then send it the message. Initially I was quite confused as to why it wasn't working, but eventually realized that I don't need to send the message number of the command message, but instead send a command message with a parameter of the message number, (I'm sure that sentence makes little to no sense to anyone but those well versed in windows messages and how they work)

Overall I'm very happy with how my editor turned out, and I may eventually add more features, but any other features (such as copy-paste and zooming are a relatively low priority for me right now). I also hope to get some user documentation up soon so all you folks out there can become experts with my program ;-)

I am also going to be starting one of my "applications" of this program before too long. I plan to build a series of lights that can be controlled by a program, which in turn will be controlled by my SoundSync program.

February 13th, 2005 (current source)

This week I spent all of my development time working on expanding the features of the editor. The first step was to be able to add/edit Event processes and commands. I found it most logical to use a tree view to display those, with the processes as root elements, and the commands as elements of the processes.

The next big step was to allow saving files. For me it made most sense to have all the command information on the top of the file, and the bottom of the file to contain the mp3 file. When opened it first processes the command information, then copies the remaining part of the file into a temp file, opening it as an mp3.

At this point the editor was completely functional, but lacked important features, such as the ability to easily tell which command a trigger belongs to. To solve this I first decided to add text to the triggers that includes the process name, and the command name. I also greatly improved the random color generation.

I'm quite proud of the color generation for it's simple design. I decided to take available information (process name and message number) to create a random number seed, from this seed I generate the red, green and blue. This means that everytime the same message number is used on a process, it will be the same color, for example, a command with message number 2001 for process "Yahtzee!" will always be the same color, even if you start a new document and re-add the command. On thing that I plan on doing, and put considerable time trying to do it is to have the icon in the tree also be the color of the command.

One last feature that I added was to allow the user to select multiple triggers to delete and move them. This isn't quite done exactly as I want it to in the end, as of now the user can hold down ctrl (or shift) to select multiple triggers, and must continue to hold it down to drag.

Also, today my girlfriend, Jennifer Matucheski, provided me with this pretty new look for the site. :)

February 5th, 2005 (current source)

This last week my main focus was on implementing the editor interface. All in all it has gone quite smoothly, with only a few minor catches. My primary influence for the interface comes from a music composition program called Cakewalk' Sonar. I allow the user to see visual representations of the music track as well as all the events. They can just click and drag the events to where they want them. In addition to being able to drag the events on a horizontal time-line I allow them to place them on different tracks (think to tracks as rows). This will allow the user to not only place events where they want them, but to organize similar events on the same track.

One early decision that I had to make was to use MFC for implementing the interface. This was a relatively easy decision seeing as I have taken CS350, and am pretty comfortable with MFC. The next, and a bit more difficult, decision was whether I would use a SDI architecture, or do all of the document/view stuff manually. In the end I feel that the ease of saving and opening files, as well as the well organized nature of an SDI application, I chose to go with using SDI.

My main struggles during this last week were of the "I have no clue why this won't compile/I don't know what this error even means" type, with a fair share of, "Well...the code is there to do this, so why isn't it doing it". There have been those problems mainly when implementing the window splitter and doing the drag and drop, but I eventually figured those out.

The joys from getting it to work though have been far greater than the problems. At each little step that I made I would get quite excited, running around my house, hoping to find someone who was willing to come look. I think the greatest joys came when I would finally fix the problems that were causing me frustration, primarily the drag and drop problem. The day that I finally got it working I literally went up to people (that I knew) and would tell them that I got it working. Needless to say I was met with many blank and confused stares, but I didn't really care too much (I did get it working, so not much could bother me).

My next steps are to be able to add/edit both the applications to send events to, and the events you can send to it. I also hope to be getting into reading/writing files soon, but I want to wait until the editor is finished before I get into that.

January 30th, 2005 (current source)
This week I did planning. As soon as I was given this assignment I began thinking of three unique problems:

What is meant by "command" and what is the best (most easily expandable) way to do these commands. How will I play/control the audio. How will the file be formatted.

For the first of these problems I first thought of having a class that will be dynamically imported, but quickly realized that would be a challenge, and be quite sloppy, especially using C++. This would force others to use C++ and be familiar with the class format. My next thought on this problem was to essentially have my program simply just execute other programs. This would allow developers to be able to write plug-ins easily, and in their language of preference. However a big downfall for this solution is that it lacks the speed needed for sychronation, especially for bigger programs. My final solution is to have my program run other programs, and send them messages. For example, my program will run another program that will handle the turning on and off of lights. All my program will do is run the program, and send it a signal to turn the lights on/off, and the program will have to handle the signal. This will allow for any existing application to be used and sychronized with music.

For the second problem I was very confident that there already exists a library for C++ for playing audio(at least .wavs), and I just needed to find it. As I suspected, there are many ways and I just needed to pick one. I ended up settling on MCI (Microsoft Media Control Inteface). This will allow me the control I need, with a simple interface that should work plenty well on any newer computer.

For the third problem I have decided that at least for now it will be easiest to have my files be formatted with the commands on top, and the audio track after. I have also decided to use mp3 compression for the audio to prevent the files from being huge. I would like to eventually have the commands interwieved within the audio track, but I would rather get a working solution before testing my brain, and especially my patients with a more complicated file format.