A most intriguing possibility came up recently in relation to my efforts to set up an easy-to-use Home Media Centre. As many of you have already found - if you're really cheap and are simply trying to reuse a WindowsXP machine as your home theatre, then the biggest problem is with the remote. The traditional PC will need keyboard and mouse for you to be able to be able to do things with it, but imagine the frustration of having to sit in front of your big-screen TV every time you need to select a new playlist on iTunes.
Around one of these moments of frustration, I happened to think of the ease with which my Nintendo Wii allows me to do things using the Wiimote. It'd be fantastic, I thought, if the Wiimote could be used with the PC? Well a quick Googling session revealed that quicker minds had not just thought of the same thing but had actually created libraries of software around possible solutions...
Last night using a combination of motej and the Java java.awt.Robot class, I was able to get a rudimentary mouse interaction going on my PC using the Wiimote...there are ready built solutions already out there, but I couldn't resist trying to add my own twist to things :)
This is an exciting area to explore...more on this asap!!
As an active developer, I feel the benefits of open software every day. At the same time, having worked for several large corporations, I'm constantly reminded of the vast chasm dividing those of us who believe in the power of 'open', from those who think it is just another nutty hobby. This weblog is a running commentary on my experiments with various open products and libraries in an attempt to bridge this gap...
Showing posts with label Saikat Ghosh. Show all posts
Showing posts with label Saikat Ghosh. Show all posts
Thursday, October 2, 2008
Saturday, September 27, 2008
Time Code Breaks and MpegStreamClip
For those who have played around with video editing - by now all the illusions about just how easy it is supposed to be with all the tools around must be broken. For me it was a big surprise to learn just how fragile and laborious this supposedly simple task can be. Leaving aside the multiple gotchas in the whole process, let me describe just 1 significant one.
While trying to import a movie clip that played normally in VideoLan into Windows Movie Maker(WMM), I found that WMM would import only the first few seconds of the clip. Repeated attempts failed and while investigating further I found that the movie duration was being misread for some reason. Even VideoLan, while playing it correctly, showed the total duration to be just the number seconds that I was able to import into WMM. Further investigation led me to the world of 'time code breaks'.
My investigations also provided an excellent tool to fix this problem - just in case you face it too. MpegStreamClip is a free tool that makes short work of time code breaks enabling one to import files broken this way - a truly significant life saver...
Incidentally the latest version of VideoLan has fully integrated file transcoding facilities. However, it looked like the codecs used were still not very stable.
A really capable alternative to VideoLan transcoding turns out to be NCH Prism Video Converter. Modular in design and function with a good capable UI - Prism functions like a charm mostly...
While trying to import a movie clip that played normally in VideoLan into Windows Movie Maker(WMM), I found that WMM would import only the first few seconds of the clip. Repeated attempts failed and while investigating further I found that the movie duration was being misread for some reason. Even VideoLan, while playing it correctly, showed the total duration to be just the number seconds that I was able to import into WMM. Further investigation led me to the world of 'time code breaks'.
My investigations also provided an excellent tool to fix this problem - just in case you face it too. MpegStreamClip is a free tool that makes short work of time code breaks enabling one to import files broken this way - a truly significant life saver...
Incidentally the latest version of VideoLan has fully integrated file transcoding facilities. However, it looked like the codecs used were still not very stable.
A really capable alternative to VideoLan transcoding turns out to be NCH Prism Video Converter. Modular in design and function with a good capable UI - Prism functions like a charm mostly...
Labels:
converter,
MpegStreamClip,
NCH,
Prism,
Saikat Ghosh,
time code,
video editing,
VideoLan
Tuesday, July 15, 2008
OpenMoko Vs Android
For those who lauded Google's explosive entry into the mobile phone market riding on the Android platform - the sheer weight of Google's push must seem enough to set things on fire. That and their market savvy in garnering a lot of strategic support for the platform up front.
But if being an open source platform for developers was a big factor in getting the 'wow' in for Google, then think again. OpenMoko has been kicking around for almost a year and with the release of FreeRunner Google's right to the title of Open Source Champion in the mobile phone market may be in serious jeopardy. OpenMoko gives you access not just to the API, but to the software implementation and even the bare metal - pretty much all there is to the concept of a mobile phone other than the cellular network. If you haven't already looked into it, think twice before starting to develop on Android. As for me, I'm waiting to see Android running on the FreeRunner... (as of the last reading, Google's implementation of Android has been compiled for ARM processors that are incompatible with the FreeRunner's specs)
Dave's thoughts on this issue
Happy news! The Android platform has been successfully run on the OpenMoko phone - http://wiki.openmoko.org/wiki/Android This is absolutely sensational for those looking for the ultimate in open solutions...
But if being an open source platform for developers was a big factor in getting the 'wow' in for Google, then think again. OpenMoko has been kicking around for almost a year and with the release of FreeRunner Google's right to the title of Open Source Champion in the mobile phone market may be in serious jeopardy. OpenMoko gives you access not just to the API, but to the software implementation and even the bare metal - pretty much all there is to the concept of a mobile phone other than the cellular network. If you haven't already looked into it, think twice before starting to develop on Android. As for me, I'm waiting to see Android running on the FreeRunner... (as of the last reading, Google's implementation of Android has been compiled for ARM processors that are incompatible with the FreeRunner's specs)
Dave's thoughts on this issue
Happy news! The Android platform has been successfully run on the OpenMoko phone - http://wiki.openmoko.org/wiki/Android This is absolutely sensational for those looking for the ultimate in open solutions...
Labels:
Android,
FreeRunner,
Linux,
mobile phone,
open source,
OpenMoko,
platform,
Saikat Ghosh
Saturday, February 16, 2008
Jackrabbit 1.4 and Problems with Failed Document Uploads
For those who prefer to live and bleed on the cutting edge of things, you must have already started experimenting with Jackrabbit 1.4 that came out in Janurary, 2008.
Well then most of you must have alse encountered a problem with uploading documents that worked perfectly with previous versions but fails. The upload succeeds, but unless the repository is manually restarted, attempts to access the newly uploaded document throws an exception with the following stack trace :
javax.jcr.RepositoryException: Internal error while retrieving value of /SecondTest/nb/field/*Value3*: name can't be null: name can't be null at org.apache.jackrabbit.core.PropertyImpl.getValue(PropertyImpl.java:470) at org.apache.jackrabbit.core.PropertyImpl.getStream(PropertyImpl.java:479) at com.sun.portal.cms.mirage.service.custom.impl.ContentServiceImpl.getFieldValue(ContentServiceImpl.java:677) at com.sun.portal.cms.mirage.service.custom.impl.ContentServiceImpl.getContentFromNode(ContentServiceImpl.java:393) at com.sun.portal.cms.mirage.service.custom.impl.ContentServiceImpl.getContentByNameAndType(ContentServiceImpl.java:351) at com.sun.portal.cms.mirage.service.custom.impl.ContentServiceImpl.getContentsByType(ContentServiceImpl.java:434) at com.sun.portal.cms.portlet.ccd.beans.ContentCreationBean.changeContentType(ContentCreationBean.java:220)
Well thanks to the following my problem is at least temporarily solved:
http://www.mail-archive.com/users@jackrabbit.apache.org/msg06191.html
A better understanding of the problem is called for so that I can address it more appropriately in the future.
But for now setting the system property org.jackrabbit.useDataStore to false fixes it immediately.
Well then most of you must have alse encountered a problem with uploading documents that worked perfectly with previous versions but fails. The upload succeeds, but unless the repository is manually restarted, attempts to access the newly uploaded document throws an exception with the following stack trace :
javax.jcr.RepositoryException: Internal error while retrieving value of /SecondTest/nb/field/*Value3*: name can't be null: name can't be null at org.apache.jackrabbit.core.PropertyImpl.getValue(PropertyImpl.java:470) at org.apache.jackrabbit.core.PropertyImpl.getStream(PropertyImpl.java:479) at com.sun.portal.cms.mirage.service.custom.impl.ContentServiceImpl.getFieldValue(ContentServiceImpl.java:677) at com.sun.portal.cms.mirage.service.custom.impl.ContentServiceImpl.getContentFromNode(ContentServiceImpl.java:393) at com.sun.portal.cms.mirage.service.custom.impl.ContentServiceImpl.getContentByNameAndType(ContentServiceImpl.java:351) at com.sun.portal.cms.mirage.service.custom.impl.ContentServiceImpl.getContentsByType(ContentServiceImpl.java:434) at com.sun.portal.cms.portlet.ccd.beans.ContentCreationBean.changeContentType(ContentCreationBean.java:220)
Caused by: java.lang.NullPointerException: name can't be null
at java.io.FilePermission.init(FilePermission.java:171)
at java.io.FilePermission.(FilePermission.java:264)
at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
at java.io.FileInputStream.(FileInputStream.java:100)
at org.apache.jackrabbit.core.value.BLOBInTempFile.getStream(BLOBInTempFile.java:145) at org.apache.jackrabbit.core.value.InternalValue.toJCRValue(InternalValue.java:366) at org.apache.jackrabbit.core.PropertyImpl.getValue(PropertyImpl.java:466) ... 97 more
java.lang.NullPointerException: name can't be null
Well thanks to the following my problem is at least temporarily solved:
http://www.mail-archive.com/users@jackrabbit.apache.org/msg06191.html
A better understanding of the problem is called for so that I can address it more appropriately in the future.
But for now setting the system property org.jackrabbit.useDataStore to false fixes it immediately.
Sunday, February 10, 2008
Echo2 and GWT
I've had a fairly good experience with Echo2 so far and relatively less so with GWT - but I thought I'd just record my biggest gripe with GWT so far.
As I noted in my previous blog - Google effectively creates their own JVM in the browser. This results in non-trivial differences for a developer:
Incidentally none of these are issues for Echo2. Since all the code you develop (aside of course from any custom scripting) is run on the server side - you can use all Java features without any issues.
As I noted in my previous blog - Google effectively creates their own JVM in the browser. This results in non-trivial differences for a developer:
- You have to remember that the code you write has to be compliant with the 1.4 Java spec. This means that although you may write perfectly compiling code using your Eclipse IDE (set to 1.4+ compiler compatibility - after all we're all on Java5 now if not Java6) the GWT compiler will throw errors if you use any of the Java5+ language features
- Even within Java 1.4 limits, fairly innocuous things like System.arraycopy() are not supported.
- You lose the ability to use something as useful as Java's built-in logging feature - Eclipse based debugging is all very fine, but we all know that debugging is only useful for the last mile. Logging is the the meat and potatoes of most trouble shooting for most developers and GWT does not give us a good way to do that yet.
Incidentally none of these are issues for Echo2. Since all the code you develop (aside of course from any custom scripting) is run on the server side - you can use all Java features without any issues.
Labels:
compatibility,
Echo2,
GWT,
JVM,
limitations,
NextApp,
Saikat Ghosh
Subscribe to:
Posts (Atom)