Well it looks like my efforts to fix the problem haven't worked. I've re-installed the software and basically done everything I can think of bar re-installing my operating system to fix the problem. Mysteriously this bug has arisen with no major alterations BUT I do think a few MS updates may be the culprit.
Thankfully I found a set of flash files that do the job I am trying to do for me and I know they already work because I did a test run on these files before using tbeta. So this will be my method of delivery for the time being, though I'm hoping when I migrate to a laptop it will fix my issues, as the code I had looked pretty neat.
So now I have to set up the final bit of this project, with a projector and laptop free standing so it can be taken a part and moved around easily. I also need to test the software on some level, so this is going to be undertaken as well.
Ultimately conclusions and outcomes are purely qualitative and very subjective, but one thing I have seen so far with this software is a massive movement toward a new type of electronic art, which is quite amazing and has endless possibilities. I see the medium moving less toward technical areas like games design or production and more toward this free flowing creative area, though I think that really both areas would come to fruition if the right people were interested in using this hardware/software. However Autodesk are working with Multi Touch screens so we will see!
Monday 23 March 2009
Moving on...
Labels:
art,
autodesk,
bug,
C++,
code::blocks,
creativity,
error,
multi touch,
openframeworks
Thursday 19 March 2009
Touch Sensing Woes
For the past few days I have been trying to get one of three examples running effectively.
I'm having big problems getting my touch sensing software (Tbeta) to work in harmony with the application. When I build and run the executable I get an error where it won't even load the opengl window, it just stops in DOS stating the same error code.
I'm switching now to touchlib and praying that works. I've also added some forum posts to the NUIG group and OpenFrameworks forum, but most of this software works in the Xcode C++ coding application on a mac, not on a win32 machine. But this isn't the culprit.
I've made extensive changes to the code, just got a working re-install of code blocks on the go tonight to try and rectify a litany of issues. Other issues concerned where major problems with VideoGrabber.cpp and quicktime, but these were localised around a set of functions which had not been initialised. Commenting seemed to do the trick, but I think it only broke the file to be honest.
The annoying thing is that this has all started to happen even though the workflow worked a month ago, but now it seems to have stopped working altogether. My deducement is that the FLOSC java application that is part of Tbeta (It sends out touched coordinates from tbeta to a localhost server which then fires them back out to any program that asks for them) is the culprit causing a networking crash. A thread on the openframeworks forum appears to back all this up.
More to come...
I'm having big problems getting my touch sensing software (Tbeta) to work in harmony with the application. When I build and run the executable I get an error where it won't even load the opengl window, it just stops in DOS stating the same error code.
I'm switching now to touchlib and praying that works. I've also added some forum posts to the NUIG group and OpenFrameworks forum, but most of this software works in the Xcode C++ coding application on a mac, not on a win32 machine. But this isn't the culprit.
I've made extensive changes to the code, just got a working re-install of code blocks on the go tonight to try and rectify a litany of issues. Other issues concerned where major problems with VideoGrabber.cpp and quicktime, but these were localised around a set of functions which had not been initialised. Commenting seemed to do the trick, but I think it only broke the file to be honest.
The annoying thing is that this has all started to happen even though the workflow worked a month ago, but now it seems to have stopped working altogether. My deducement is that the FLOSC java application that is part of Tbeta (It sends out touched coordinates from tbeta to a localhost server which then fires them back out to any program that asks for them) is the culprit causing a networking crash. A thread on the openframeworks forum appears to back all this up.
More to come...
Labels:
C++,
code::blocks,
openframeworks,
tbeta,
touchlib
Tuesday 17 March 2009
More to come...
Well it's nearly time to start looking into completing the hardware setup and getting the programming to work together in effective synergy. So far as posted this has been difficult, but attempts will be made to adapt open source examples to try and see if an effective application can be created.
Wednesday 11 February 2009
openframeworks
I've managed to get tbeta to work with openframeworks the C++ framework for touch interfacing. But interactivity is an issue. I learnt openGL 2.0 a few years ago before I went to University, but my understand is a little to basic.
I have to find a way of allowing the user to switch modes (To do different things), though I could have this interactivity placed onto a key on the keyboard. But even if I did I wouldn't be sure how to change modes, as this involves looping and use of boolean (true false) arguments...which I used to get wrong.
Hopefully I'll find some working code for an image loader, or something similar soon. I will post more when that time comes.
I have to find a way of allowing the user to switch modes (To do different things), though I could have this interactivity placed onto a key on the keyboard. But even if I did I wouldn't be sure how to change modes, as this involves looping and use of boolean (true false) arguments...which I used to get wrong.
Hopefully I'll find some working code for an image loader, or something similar soon. I will post more when that time comes.
Tuesday 10 February 2009
Surface...more important than I thought
Program tests were good today, albeit it limited. I now see why the surface (Material) is so important. The surface material has to allow a finger to slide over it with ease (Acrylic provides too much friction) and currently I am interfacing directly onto the acrylic. I even tried gloves to get that down, but they didn't displace the IR field.
So I need to come up with a few project flows and then try working on an application to bring together a few features. As always the community is fantastic. I'm now using openframeworks with tuio which is part of TBeta's blob tracking element. This is what allowed me to interface with the software running on the PC.
Testing all this will be difficult in the time I have available, but I hope to get a program up and running soon for show.
So I need to come up with a few project flows and then try working on an application to bring together a few features. As always the community is fantastic. I'm now using openframeworks with tuio which is part of TBeta's blob tracking element. This is what allowed me to interface with the software running on the PC.
Testing all this will be difficult in the time I have available, but I hope to get a program up and running soon for show.
It works!...again
Right, so I've fixed the first programming problem. First of all I should say that the screen is working properly now and I can configure it properly as well. I am still missing a projector, which isn't great and I am also missing a laptop for portability, but that can wait. One less thing to worry about though.
The hardware interfaces with the infra camera, which is interpreted by the software on the computer. I had already been notified of an API framework (Call it what you will) called openFrameworks by developers at Autodesk and so I went to check it out. To cut a long story short I chose this as my end solution. I used tbeta and mtmini software to configure the hardware and test the principles of infra red hardware, before progressing.
Yesterday I found out that I couldn't just interface directly with openFrameworks (Which is built in C++) without having something else handle the multi touch interaction, which was being picked up by the infra red camera. Thankfully the community is fantastic and someone had already had this problem.
Tbeta software handles multi touch movements on screen and configures them and it has a facility to send these movements out through a localhost service (This basically picks up the movement information sent out by tbeta and waits for another application to ask for it) using a specific port. So this was the fix to my problem, because it would do all the hard work for me...famous last words! haha
Well it wasn't so bad in the end. After a full day of tweaking and trying to figure out why the libraries weren't linking properly in Code:Blocks (The C++ shell I am using), I finally got it to work. But I had to update the framework, the addons that I needed to get it to work and my project links.
So now I have a lovely blank window, but hope to have paint or something much more interesting to show for it, very soon!
The hardware interfaces with the infra camera, which is interpreted by the software on the computer. I had already been notified of an API framework (Call it what you will) called openFrameworks by developers at Autodesk and so I went to check it out. To cut a long story short I chose this as my end solution. I used tbeta and mtmini software to configure the hardware and test the principles of infra red hardware, before progressing.
Yesterday I found out that I couldn't just interface directly with openFrameworks (Which is built in C++) without having something else handle the multi touch interaction, which was being picked up by the infra red camera. Thankfully the community is fantastic and someone had already had this problem.
Tbeta software handles multi touch movements on screen and configures them and it has a facility to send these movements out through a localhost service (This basically picks up the movement information sent out by tbeta and waits for another application to ask for it) using a specific port. So this was the fix to my problem, because it would do all the hard work for me...famous last words! haha
Well it wasn't so bad in the end. After a full day of tweaking and trying to figure out why the libraries weren't linking properly in Code:Blocks (The C++ shell I am using), I finally got it to work. But I had to update the framework, the addons that I needed to get it to work and my project links.
So now I have a lovely blank window, but hope to have paint or something much more interesting to show for it, very soon!
Monday 9 February 2009
The acrylic frame
Well this weekend I finished the frame that will hold the acrylic screen (See picture). It cost me about £5 from the timber yard + alterations and cutting. If I had more time I would build a table like so many others have, but I don't.
I would have got more done but I was working on a novel this weekend, which I'm glad to say is finished, but I am currently re-drafting (see Dominic Took.com)
Today I am going to re-calibrate the screen using the software provided by Tbeta which interfaces with a flash application to provide interactivity in the form of a multi touch screen (It's pretty neat!). I hope to get a half decent video up on youtube sometime soon.
I will let you know how I get on...
I would have got more done but I was working on a novel this weekend, which I'm glad to say is finished, but I am currently re-drafting (see Dominic Took.com)
Today I am going to re-calibrate the screen using the software provided by Tbeta which interfaces with a flash application to provide interactivity in the form of a multi touch screen (It's pretty neat!). I hope to get a half decent video up on youtube sometime soon.
I will let you know how I get on...
Subscribe to:
Posts (Atom)