I'm just going to admit it up front: I am a complete sucker for a good UI. UX is important as well but if you give me a really ugly UI and say "But the UX is amazing!" I'm less likely to be interested. Love it, hate it, whatever, the new Windows style of interface is attractive. Live tiles are a clever method for content consumption that is far more interesting than a straight feed reader. Even though that's basically the purpose.
Sure you can put whatever you want there, but essentially it's a feed. The ease of programming for the Windows 8 style of application is also welcome. Granted, I really don't know anything about XAML. I can mostly read what's going on but I'm currently having to read up on what it is I want to do if I'm not going to be dropping things in from the toolbox. But it's fun. And you get Visual Studio.
I like Eclipse a lot. My Java class and C class both had me using Eclipse (IDE was optional but Eclipse was a natural choice) and I found myself productive in it and all that. But when it came to playing with Android, the experience felt extremely clunky. I know there are many that will disagree, and that's fine. Preference is subjective. Visual Studio feels streamlined. When I drive a car, gadgets are fun but I really only care if they enhance my driving experience. I don't need a million buttons to do things. I don't have to have volume control on my steering wheel, but it's handy. I don't need extensive configuration. My car's purpose is a point A to point B type of thing for me and I like to feel the drive. I feel the same about the tools I use to fulfill my role of code monkey.
Visual Studio deploys easily between tests for Desktop (windows 8 store), Tablet, and Phone. The simulators are clean for tablet and phone. And you don't have to wait for what feels like an eternity for them to boot. That's my favorite part.
As for the operating system itself, I don't understand all the complaints. Granted, I'm an individual that hits the windows key and then immediately begins typing to get my desired program. I don't like having to run through context menus to find it. So for me to use Windows 8, I had almost no learning curve. Yes to get to my wireless settings I have to go through the charm bar. So what? Hide the stuff I don't need to see all the time. I'm fine with that. I spend most of my time on the desktop. I really don't see the Start menu dash unless I'm doing a search to find the program I want.
This isn't some sort of colossal failure or a war on users. Why is it we idolize the screens we see on Star Trek and such and then when we're presented with something that moves more toward that direction we reject it?
I've never been a fan of the ribbon for Office, but I actually like it for Windows Explorer. New folder? Boom. Dedicated icon for that. Search filtering. Dedicated icons. I feel like it's an improvement. It adds a little bulk to the top of the window but it isn't an unwelcome feature.
Windows 8 really shines with touch interaction though. I like the paradigm shift. The choice of blending tablet with desktop is nice because you can grab a tablet PC (that is, one running Windows 8, not WindowsRT) and have it on the couch while you're watching television, but then snap it in to whatever docking method your particular hardware supports and you're back to your usual mouse and keyboard. Love that.
Thursday, January 31, 2013
Friday, November 2, 2012
New Project - Active/Responsive Ambient Lighting
So, while browsing the wonderful web one day recently a friend of mine, +Clint Shuman, sent me a link to an RGB LED grid that acted as a responsive ambient light for a TV. Awesome right? I love stuff like this. It's simple, but it really adds an interesting touch to movie night. Naturally, we immediately set out to program our own version.
The concept of active ambience is pretty interesting. The fire in that Avatar video link really enhances the feeling of having that torch flipped around. I definitely like that but there are a few limitations to this implementation of ambipi.
First, it is Windows only. Although Windows is a perfectly pervasive and acceptable OS, it is not the only one - nor is it frequently the choice of my media enthusiasts. A home theater build using Linux is often a less expensive and adaptable solution. Further, the limitation of using XBMC that is specially compiled for this feature limits the playing pool to a release cycle based on this feature. One can't simply update to the latest and greatest XBMC the whenever they please (ambipi extensions, not boblight for those thinking of it).
Which leads to the main hurdle: what about active ambience for other uses of the machine? VLC? Video conferencing? And the list continues. I want a solution that works with the display output and not only one application (although it has plenty of extensions). Adalight and others certainly have achieved this, but I would like to solve the problem in python and make it as cross platform/device as possible with additional configuration. Ultimately, how nifty would this type of thing be on displays, at trade shows, etc? Pretty eye catching.
So enter python and some good fun playing with websockets to test the results. I don't have any LEDs to plug into my Raspberry Pi, so Clint and I setup a cherrypy server with a websocket to communicate back to the server. The webpage has a configurable grid of squares. Although we started with a 3x2 grid, we have moved on to a 5x3 as we feel it'll produce a better ambience. The test with 8x8 went well but for now I just want to focus on getting a basic setup working flawlessly. Originally we made a full grid with all pieces of the screen updating (that is, all 15 boxes in a 5x3) but then decided to do a perimeter only since we won't have LEDs in the center behind the display. A perimeter of boxes on a 5x3 results in a 12-count. The grid generation algorithm was changed to simply build a full row if it was the first or last row and since the algorithm is only run once, there's no performance hit.
At first, we were at about 8 fps using screencaptures for each individual grid. This is super slow (200-300 millisecond response time based on grid size). So we changed the algorithm to capture the screen once and then resize it before sending it off to be analyzed by bounding box. This significantly improved performance and currently we're around 15-20 fps depending on how tempermental my CPU is feeling. Oddly my computer at work runs at about 45 ms pretty consistently while at home I'm more consistently in the 80-100 ms range. I still haven't figured out why that is, but I did just upgrade to Windows 8 so maybe there are some issues I haven't found yet relating to that (work is Windows XP).
Ultimately, I'd like to move to the win32api and see if I can get any improvement over the Python Imaging Library (PIL). For linux, we currently have GTK being used. It's possible we'll go to native C and use X to grab the window if needed, but we'll need to run some tests. GTK is staying pretty consistent with where PIL is (45 ms). I thought GTK would be far faster, but perhaps there's room for improvement with the algorithm.
The current plan (for me, Clint will use an Arduino) is to have my computer serving the image data over UDP to a Raspberry pi. Alternatively, could leave the Pi plugged in but that does involve the limitation of putting the computer next to the pi and therefore next to the tv. I don't currently have any spare computers lying around so a network method is preferable.
The concept of active ambience is pretty interesting. The fire in that Avatar video link really enhances the feeling of having that torch flipped around. I definitely like that but there are a few limitations to this implementation of ambipi.
First, it is Windows only. Although Windows is a perfectly pervasive and acceptable OS, it is not the only one - nor is it frequently the choice of my media enthusiasts. A home theater build using Linux is often a less expensive and adaptable solution. Further, the limitation of using XBMC that is specially compiled for this feature limits the playing pool to a release cycle based on this feature. One can't simply update to the latest and greatest XBMC the whenever they please (ambipi extensions, not boblight for those thinking of it).
Which leads to the main hurdle: what about active ambience for other uses of the machine? VLC? Video conferencing? And the list continues. I want a solution that works with the display output and not only one application (although it has plenty of extensions). Adalight and others certainly have achieved this, but I would like to solve the problem in python and make it as cross platform/device as possible with additional configuration. Ultimately, how nifty would this type of thing be on displays, at trade shows, etc? Pretty eye catching.
So enter python and some good fun playing with websockets to test the results. I don't have any LEDs to plug into my Raspberry Pi, so Clint and I setup a cherrypy server with a websocket to communicate back to the server. The webpage has a configurable grid of squares. Although we started with a 3x2 grid, we have moved on to a 5x3 as we feel it'll produce a better ambience. The test with 8x8 went well but for now I just want to focus on getting a basic setup working flawlessly. Originally we made a full grid with all pieces of the screen updating (that is, all 15 boxes in a 5x3) but then decided to do a perimeter only since we won't have LEDs in the center behind the display. A perimeter of boxes on a 5x3 results in a 12-count. The grid generation algorithm was changed to simply build a full row if it was the first or last row and since the algorithm is only run once, there's no performance hit.
At first, we were at about 8 fps using screencaptures for each individual grid. This is super slow (200-300 millisecond response time based on grid size). So we changed the algorithm to capture the screen once and then resize it before sending it off to be analyzed by bounding box. This significantly improved performance and currently we're around 15-20 fps depending on how tempermental my CPU is feeling. Oddly my computer at work runs at about 45 ms pretty consistently while at home I'm more consistently in the 80-100 ms range. I still haven't figured out why that is, but I did just upgrade to Windows 8 so maybe there are some issues I haven't found yet relating to that (work is Windows XP).
Ultimately, I'd like to move to the win32api and see if I can get any improvement over the Python Imaging Library (PIL). For linux, we currently have GTK being used. It's possible we'll go to native C and use X to grab the window if needed, but we'll need to run some tests. GTK is staying pretty consistent with where PIL is (45 ms). I thought GTK would be far faster, but perhaps there's room for improvement with the algorithm.
The current plan (for me, Clint will use an Arduino) is to have my computer serving the image data over UDP to a Raspberry pi. Alternatively, could leave the Pi plugged in but that does involve the limitation of putting the computer next to the pi and therefore next to the tv. I don't currently have any spare computers lying around so a network method is preferable.
Sunday, October 28, 2012
Learning C
I don't have years of programming experience. The time that I devote to learning languages tends to be allocated to Python or something work related (.Net). However, I'm currently enrolled in a course focused on introductory C. At times I feel as though I have stepped into a time machine.
I used to play this video game and the people who were really obsessed maxed all their stats as much as they could. There were intense calculations that could be done. People could spend hours figuring out the best way to spellcraft their armor or weapons so that every possible point or stat could be claimed. More hours would be spent "farming" locations for "drops" to create the perfect armor set. It sounds like a complete waste of time, and maybe it was, but it was certainly fun. I was one of those obsessed people that did everything they could to maximize their "utility."
C reminds me of this mindset. I can completely see how people who are obsessed with performance or being in control of as many aspects of a program as possible would love C. You get to control almost everything so you get to optimize almost everything. You manage your memory. You fine tune everything. No doubt C is fast, but for once in my life I find myself enjoying the automatic management I get from lots of other, higher-level languages. Obtaining input in C presents a good example:
#include <stdio.h>
void main ()
{
int inputChoice;
do {
printf("Please make a selection from the choices (1-4): ");
scanf("%d*[\n]");
if (inputChoice < 1 || inputChoice > 4) {
printf("Error - you have entered an invalid choice.");
}
} (while inputChoice < 1 || inputChoice > 4);}
I used to play this video game and the people who were really obsessed maxed all their stats as much as they could. There were intense calculations that could be done. People could spend hours figuring out the best way to spellcraft their armor or weapons so that every possible point or stat could be claimed. More hours would be spent "farming" locations for "drops" to create the perfect armor set. It sounds like a complete waste of time, and maybe it was, but it was certainly fun. I was one of those obsessed people that did everything they could to maximize their "utility."
C reminds me of this mindset. I can completely see how people who are obsessed with performance or being in control of as many aspects of a program as possible would love C. You get to control almost everything so you get to optimize almost everything. You manage your memory. You fine tune everything. No doubt C is fast, but for once in my life I find myself enjoying the automatic management I get from lots of other, higher-level languages. Obtaining input in C presents a good example:
#include <stdio.h>
void main ()
{
int inputChoice;
do {
printf("Please make a selection from the choices (1-4): ");
scanf("%d*[\n]");
if (inputChoice < 1 || inputChoice > 4) {
printf("Error - you have entered an invalid choice.");
}
} (while inputChoice < 1 || inputChoice > 4);}
This is how we collect input in C. We have to protect ourselves, and an easy way for a beginner like myself in C to protect against bad data is to use a do loop. Oh, that section with *[\n]? Yeah. That prevents the system from trying to store the newline character (\n). Yep. You have to handle that.
The thing is, I completely understand how awesome this must have been for a long time. But now it's just not necessary to me to spend a lot of time doing all this when I can literally do it in one line of code in another language. Take python for example:
inputChoice = input('Please make a selection')
I'm cheating because there's no error handling. But we can add that with a couple of lines admittedly. The point isn't so much the length. It's having to handle things like the newline character. You also can't test data types in C.
Subscribe to:
Posts (Atom)