When I saw the skittles website I admit I didn't fully get it. I thought it was cool that they could float their presence over various social media sites, but it seemed more like a novelty than anything and it didn't support the customer the way a large brand needs. It took the clever guys over a UnHub to make the connection for me. (I guess I'm getting slow in my middle age.) Skittles isn't injecting themselves into various social media sites, they are building their own web portal out of them. UnHub lets anyone build a portal our of their presence across various sites as your single link you give to people. Take the typical personal home page. Where there used to be a guestbook (now thats web 1.0) there is now your facebook profile. Instead of a gallery, your flickr page is embedded. Resume? LinkedIn. Music player (ugh, how MySpacey) gets replaced by your lastFM or pandora profile. I know I probably sound ridiculous to everyone who saw into this already, but sometimes it just takes an elegant implementation of something to see the true value of it. Worth checking out.
So now my "homepage" is http://unhub.com/dthree/
Friday, March 20, 2009
Thursday, March 19, 2009
Camera Update
Just an update to the camera post, we ended up going with a Canon ZR900 for the kid's first video camera. Picked up a refurb for 40% off the going rate and there is not a scratch on the thing. Only accessory missing was a $4 watch battery to keep the time. Since there are so many cameras in the price range, we had a hard time choosing, but this one had a few features that other cameras in the price range don't usually, have and of course Canon's own great optics. First off, we decided that he didn't need HD. We looked at submission requirements for film festivals and summer camps, and none of them required HD, some even specifically required miniDV. Secondly, this was the only DV camera under $400 with a mic-in. This gives him the option of using any microphone which can greatly improve audio quality over the built-in. Last, it has the ability to manually control exposure and focus, important for learning how to set up shots and dealing with light. The body is nice and compact but still has a decent-sized 16x9 ratio LCD screen and color viewfinder. Four days after it arrived, he was shooting a project for his 10th-grade history class. Next we have to get him a tripod so he won't steal my expensive manfrotto again.
Wednesday, March 11, 2009
The web sampled, remixed, warped, chopped and screwed
The amazing kultiman youtube remixes have been all over the blogosphere, twitterscape and other various webiverses, so I haven't felt the need to comment or linkify. Like other viewers, I though it was interesting and illegal, and I was going to let it stew a while before posting anything, but i don't think I can solidify my thoughs any better than what I read from Merlin Mann over at 43 folders. Here's the pull quote I choose that hit me with laser-precision:
Can we figure out a way for musicians to be paid that allows this kind of creation to be legal WITHOUT jumping through a myriad of legal hoops? Why can't the whole web be a playground for remixing? If everything is meta-tagged, our tools just need to hold on to the metadata throughout the remixing/revisioning process. Then when we stick it back on youtube, all the original artists get a few more pennies of the general copyright fund™ each time it's played. Why aren't we ALREADY doing this?
Because, this is what your new Elvis looks like, gang. And, eventually somebody will figure out (and publicly admit) that Kutiman, and any number of his peers on the “To-Sue” list, should be passed from Legal down to A&R.
Can we figure out a way for musicians to be paid that allows this kind of creation to be legal WITHOUT jumping through a myriad of legal hoops? Why can't the whole web be a playground for remixing? If everything is meta-tagged, our tools just need to hold on to the metadata throughout the remixing/revisioning process. Then when we stick it back on youtube, all the original artists get a few more pennies of the general copyright fund™ each time it's played. Why aren't we ALREADY doing this?
Tuesday, March 03, 2009
Did I ever mention I like relative paths?
I recently worked on a flash project that another developer started. His folder structure was a little different than I was used to but made perfect sense. Rather than keep the FLA and SWF in the same directory, the source FLA files were in one directory, and the full published project ready for deployment with swf, html, css, etc. was in a separate directory. Not too unusual, but this meant that the swf path in the flash publish settings had to be manually specified to that publish directory. This is fine when there is only one person working on the project, but we had 3 so when I get a file from someone else, the SWF path fails when I publish. What I didn't know, because I am occasionally stupid and don't read manuals, is that relative paths work in the publish settings.
So instead of:
which fails if I move "project" to another drive, I can instead specify:
and now I can move "project" anywhere I want, and it is even cross platform.
So then I though, what if this could work in Shake? I have been wrestling with broken filein paths for a while. It's not just that it's time-consuming to update all my filein paths if I move a project to a different folder or drive, but that sometimes it causes Shake to quit before the file even finishes opening. My workaround before was to edit the filein paths with a text editor, and I have had some success automating this process with find/replace or grep, but it still meant editing them every time the project gets moved around. Some of these projects have 50 or 60 shake files with 5 or more filein nodes.
Using relative file paths for both filein and fileout nodes eliminated that process completely. Just like in my flash example, if I set all my paths relative, and don't change my directory structure within each project, I can move the project folders anywhere I want and the filein nodes all stay linked and the fileout nodes don't fail. I never though that a simple ../ would save me so many headaches.
So instead of:
c:/project/pub/my.swfwhich fails if I move "project" to another drive, I can instead specify:
../project/pub/my.swfand now I can move "project" anywhere I want, and it is even cross platform.
So then I though, what if this could work in Shake? I have been wrestling with broken filein paths for a while. It's not just that it's time-consuming to update all my filein paths if I move a project to a different folder or drive, but that sometimes it causes Shake to quit before the file even finishes opening. My workaround before was to edit the filein paths with a text editor, and I have had some success automating this process with find/replace or grep, but it still meant editing them every time the project gets moved around. Some of these projects have 50 or 60 shake files with 5 or more filein nodes.
Using relative file paths for both filein and fileout nodes eliminated that process completely. Just like in my flash example, if I set all my paths relative, and don't change my directory structure within each project, I can move the project folders anywhere I want and the filein nodes all stay linked and the fileout nodes don't fail. I never though that a simple ../ would save me so many headaches.
Subscribe to:
Posts (Atom)