I finally have a functional email client, and a basic file output.
This should end up being my primary means of receiving sms data. It needs some polish.
Ideally this will be a stand alone sketch,
that listens to the email server and stores the emails for use by a
secondary sketch that will be managing the graphics side of the application.
The sms trigger for my test client (pictured above in an early version), is partially complete. The issues of receiving the message have mostly been resolved and the remaining issues are as follows.
1) There is a problem retrieving the message string when passing it from the email client to the graphics application. A possible resolution suggested by the oscP5 library is to use the oscPlug class to manage the typecasting of the message.
2) There are existing problems/bugs within Processing's implementation of the JOGL bindings to openGl. OpenGl is most functional on OSX (which is a bit odd. It worked better in Windows last semester ).
3) There is a persistent problem connecting to the gmail account that is acting as the repository for all received sms messages. After a period of time the authorization used to connect to Google's server expires or is simply rejected. It may be possible to modify my existing code to only connect once, and then take steps to ensure that the connection is kept alive for the duration of the program's run-time.
Got a wiimote working as standin for a computer mouse. Which makes interfacing to processing really easy. It looks like the same interface can be modified to act as a midi controller. Or game controller, so there should be a way to get all of the pertinent data to and from the wiimote.
Solved at least half of the problems with the mail server. Now at least I only get kicked off occasionally. That was solved by remembering that I was never closing the connection I had with the server, and gmail didn't like having a bunch of concurrent connection attempts when there was still a live session from an earlier run of the sketch. In the process I also figured out the how to pull the messages out and attach it to the class definition of the graphic object without throwing errors (most of the time). Now on to the contains method in 3-d. Ideally this should interact with the mouse so that it is easy to manage across platforms, but the goal is to integrate the proControll library into the graphics application, so that the wiiMote can be used as the primary tool for interacting with the running sketch. Also did a test of threading in processing, I think this has potential for some of my project as far as integrating the multiple components Threading.
This is the big week. Major goals are the integration of the proControll interface for the wiimote. I'm starting to run into the performance limitations of the processing environment, but I think I can pare down some of my excess to increase the speed my data-structures. The bulk of the lag occurs on start-up when 10-20 objects are instantiated at one time and begin their random walk. This is not a problem during the intended run time of an installation as the insertion time of each object will be staggered. There is a very definite upper limit on how many objects the application can handle before it fails.