This is the current state of the program. The pretty little graph display is displaying the path of the selected motor (Eyes U/D) throughout the entire animation. This will be displayed below the waveform display (when I finally get that working) and will give you a good idea of what the motors are doing during points in the audio.

The wierd little box in the upper left, is the beginnings of a "Simulator" which will allow you to play back the animation and watch the movements on an animated head. This is going to be pretty complex, but so far it's been easier than figuring out how to display the waveform. :)  If I still have some energy when I am done with this program, I may work on changing the simulator over to a 3D model and animating that. Also, another "maybe" that I am interested in attempting, is to allow the program to load profiles, which convert it over to another animatronic. I will decide this when I see the final look and complexity of code already involved. Making it configurable like this means essentially building the forms at runtime, which is not a simple thing to do :)

I will put a full size screenshot in the gallery.

I now have a "spectrum" display running in the main form. But, currently it is not formatted the way it will be when finished. However, it does allow you to see the waveform frequencies while playing back. Also, the routines to display this will be needed for lipsyncing routines later.

I have also added a toolbar and status bar to the bottom. To process the audio, I need to freeze the form and play back the audio to get all the samples from the audio. I am working on trying to make the playback rate 2 to 4 times faster than normal so that you do not have to wait the entire length of the audio.

Anyway, this will only happen once at load time, or if you change the audio clip. Then all needed information will be in memory.

Also, with the new spectrum routines, the sliders are starting to lose track towards the end. But, once all this is loaded in memory, it will be much much faster.

Here's a screenshot as of 10 minutes ago:

Still no PMs from anyone offering to test this out. I could really use some feedback as it is difficult for me to remember to try everything. :) But, again, if you are not able or willing to deal with a little frustration, then now is still not a good time to get involved.

However, any feedback or suggestions from just looking at the screenshots would also be helpful.

Oh, You can also choose not to open an MP3 to associate with a new animation, if you like. I may add the ability to add an audio file separately.

Is it maybe complaining about Fmod? You will probably need to copy fmod.dll to your windows system32 folder.

Other dependencies (that I know of) are windows common dialog control, and windows common controls SP 5 and 6.

All depencies files are in the output/support folder.

The output folder contains an installer, which will copy all the dependencies to the proper places and register them. This is probably the easiest way to make sure that you have all the parts in the right places.

Anyway, so much has changed since the package I gave you on Friday, that you really should get an update anyway. I will package it up for you in the morning and get it posted.

Just to let you know, though, I have decided (actually tonight, just before leaving for work) to completely rebuild the program. So much of it was designed by trial and error (I had even forgotten how to open a file in VB when I started on this.) The code is an absolute mess with fragments all over the place and some really odd (but working) program flow. But, mainly, it is just getting to be almost impossible to maintain. Every time I make a small change, I have to update the code in 8 or 9 different places. And this is just bad coding practice. Also, I have practically no error trapping in the code, so it will just go nuts, leak memory, and crash if something gets off on the wrong path or if you do something I hadn't planned for. This is an absolute must if I am going to release the program to the public.

Now that I am far enough along and all major and most important functions are working and *mostly* stable, I should be able to rewrite all the routines that I am happy with cleaner and slimmer and freeze these parts.

Regardless, the new code will be built off mostly the original routines, so it is still useful to check out.

I'll update the package in the morning and let you know when it is ready.

I have pretty much gotten my old code ported over to a new project. I have managed to clean up my code quite a bit and slimmed everything down so it will run much faster (The playback works like a charm now.) I have also gotten rid of a few quirks that had been driving me nuts and ended up on my todo list.

This required me to go through every single procedure and line of code and determine if there was a more clear or more simple way to do it. It's still not perfect, but I am satisfied for now.

So, here are some updates:

1. I am implementing a project methodology to the program. This means, that you will be able to load or create several animations in one single sesssion and store them in your project. Since the files on the cartridge belong to 4 different categories, this made sense. You will be able to save and load a project, as well as "build" it to an output folder (such as an xD card in your reader) Building the project will name all of the files properly and collect them from whereever you have them stored.

2. I have mostly worked out the waveform and spectrum displays. I will be allowing the ability to switch between them at any time.

3. I am moving to image toolbars for the menu system including some custom icons that I made

4. Random fill routines still need lots of improvement

5. Frame routines like insert, delete, copy, paste and trim still need to be done. Should just be simple math routines

6. I am really not happy with the slider interface and am developing a much better interface. Still working on it though, and I am not 100% sure which way it will go, so it will probably end up in version 2, not version 1.

7. I have not worked on the simulator, or lipsyncing features yet. The lipsyncing, I think should be pretty easy once I get to it, because we are only modifying one or two motors (Lip and Jaw.) What I will need to calculate, I think, is just the amplitude and energy of certain frequencies. I will be getting that data to plot the spectrum anyway.

8. Some big features that are planned are joystick control, importing and exporting of motion capture formats, and real-time PC control (once I get the custom firmware working.) I will be outputting this to a serial port, so others could use it for their own controllers (GWJax) if they just implement the handler in their microcontroller. I am not sure which, if any of these features will make it into the first version.

I don't think anyone is really in a hurry since I have yet to hear about anyone with a custom cartridge besides me yet, but I would like to get the first version out there so I can get some people to provide feedback. I am a little disappointed that I haven't gotten any more offers to try it out. I know making a cartridge is tough for most people, but this is really just running a program... no cartridge needed. :) It might not run for you at first, or it might crash when you try to do something I didn't expect you to try, but it will not eat your operating system when it does. Well, I can't promise that, I guess, but it is very highly doubtful.

I just had to do some calculations and for cartridge filled with 100 animations for each category (completely maxed out) just the animation files alone would be 1.8GB. This would last for nearly 15 days, so obviously the size of the matching MP3 files would be very very large.

Of course, the max limit for FAT16, the format used by the cartridge, is 2GB, so really, you could never reach this limit.

So 600mb of just the animation script files for one maxed out category, with max duration.

Honestly, though, I cannot imagine someone programming an single animation that would last for 4 hours :) Just thought people might find the numbers interesting

Let's see if I can describe the picture above...

What you are looking at is a concept image for a manual motion capture system.
The idea is that you record some video of your own face acting however you want Elvis to act.

You start with a nuetral pose, which you use to place the markers (white dots) at the features on the face.

You line up your centerline, leftline, and rightline with your face so it has an idea of the scale of your face.

After you get all the markers placed, you press step and this will advance the video approximately 200ms (1 frame) Then you move the markers again to match the position of your face in that frame, and so on throughout your video.

The markers (white dots) are measured in relationship to each other to determine the expressions of the face. All of those lines you see are linked in a hierarchical stucture in relation to root (Red dot)

For example when you nod your head, the distance between then chin and root will shorten, but the position between nose and chin will not. When you open your mouth, the distance between nose and chin will increase but not nose to root, and so forth.

When you turn your neck, the angles of the link lines will change as well as all of the markers in relation to the center,left,and right lines.

It's not perfect, but I have been trying to develop a concept for simple motion tracking. There doesn't seem to be any free programs to do this, and even the ones you can buy are very complex. The facial movements of Elvis are very limited so a simpler approach was needed.

Really, when this is finished, the framework of it could be used for automatic optical motion capture, if you put real markers on your face.

The overall idea, is to use the capture as keyframes and then process this data to derive tweens (transistion frames)

The picture above is just a prototype UI designed in a paint program, so don't be misled into thinking I have it all working yet :)

Even though this is much simpler than commercial systems out there, it is still pretty complex. But, really this method is on scale with the simulator (and many of the routines will probably be shared between them) so it is at least feasible with alot of work.

You don't care for my bald Elvis, Nocturnal? :)

Now, we are talking! This is a comparison of my display versus the display of the same MP3 in audactiy. We are getting there. I can certainly make it prettier, but at least I have the basics down now. Each of the red lines in my display is *supposed* to represent 200ms of time. Why 200ms? Because that is how long one frame of the animation lasts. The final display will scroll a bar along the waveform to show you where you are at in the animation and will highlight that section of the waveform. So, the red lines are mainly just there now for debugging to be sure I am seeing the entire waveform and not scaling it funny. The previous picture was only displaying the first half of the waveform, but now it is all displayed, and it is pretty fast!

When I am finished with this code, I will probably post just the display code somewhere, because I have found hundreds of people trying to figure out how to do this, but nobody actually had any answers for them other than *theory*.

The next step is to build a proper spectrum display of the entire MP3 so that you can switch between the two. I also need to reduce the number of samples to display so it is faster and prettier. This will require a routine to interpolate the wave form data to only display large changes in values throughtout each 200ms "chunk". I have a general idea how to do it, but need to nail some numbers down to build a proper algorythm.

Here is another one demonstrating the editing of frames.