First of all, I’m very sorry for the lack of frequent Übercaster updates lately. Also I regret the stability problems some users have.

I’d like to explain some of the reasons for the recent slowdown on Übercaster’s updates in a bit more detail:

First and frontmost I’d like to emphasize, that we didn’t abandon Übercaster at all! We still support Übercaster, we still develop Übercaster, and we have exiting plans for Übercaster’s future.

Übercaster v1.6.3 was supposed to be released back when Snow Leopard came out, providing full Snow Leopard compatibility.

Unfortunately some unexpected additional problems with v1.6.3 on Snow Leopard occurred, shortly before the official release. This is why there is still gist a beta of v1.6.3 available.

If you have not downloaded it yet please give it a try. I just released v1.6.3 beta 7 and, although it is still tagged as beta, it’s probably much more stable than v1.6.2 (on Snow Leopard as well as on previous versions of Mac OS X).

You find a link to Übercaster v1.6.3 beta 7 on Übercaster’s download page.

The best way to fix a lot of the current problems with Übercaster would be to completely overhaul its code base and switch to “Snow Leopard only”.

Übercaster still runs on Tiger and this means that there is a lot legacy code in there, bloating up Übercaster’s code base. This makes it very hard to maintain the code.

A lot of problems would just disappear by simply throwing all legacy code away and replace it with new technology provided by Snow Leopard. Of course, Übercaster would greatly benefit by being “Snow Leopard only”: More lightweight, better performance, more stable and last but not least by providing a refined UI.

This has been (and still is!) exactly the plan for Übercaster:

1. Release Übercaster v1.6.3 as a baseline for future bug fixes on the legacy code.
2. Start the “Übercaster 2″ (Snow Leopard only) project.

Unfortunately there have been some unexpected obstacles and drawbacks in the last few view months.

A recent loss in the family definitely slowed things down. There are a lot of things to handle and even after most of them are done, it’s definitely not easy to go “back to normal”.

Then, the unexpected additional Snow Leopard problems mentioned above. This prevented us from releasing v1.6.3 so far (but we’re close to a release now!).

Last but not least, we have unexpected success with one of our iPhone apps. Although this basically is a good thing, it increased the time-consuming process for handling support requests considerably. Unfortunately, this really took me by surprise and caught me straight to something that you could call a “support trap”: More than 3/4 of my day I have been busy to handle support requests. So far, I’ve handled over 2500 support requests in 2009, most of them consisting at least 2 or 3 mails. There has been hardly enough time to do most basic bug fixing and updates.

We approach this problem by extending the “Pleasant Software Team” with a new member, dedicated to handle support requests.

We hope that this step lifts a lot of pressure off me in the long term and gives me much more time to advance Pleasant Software’s projects.

Ok, that’s it for now.

Sorry again for the lack of blog posts lately! That’s another thing I try to find more time for…

And don’t forget to check out Übercaster v1.6.3 beta7!

We just added new content to the Developer section on our site: Creating a Microphone Enhancer for Übercaster.

Übercaster comes with a default MicEnhancer for Microphone panels and another one for Skype panels.
But it’s no problem to add additional MicEnhances with other characteristics or specially designed for specific devices. If you like to create your own MicEnhancer for Übercaster, please have a look on the new documentation.

We recently introduced a new section on the Pleasant Software homepage: “Pleasant Software Developer Tools“.

Currently there are two free developer tools/frameworks available from Pleasant Software:

• “iMBiPhoneView”, an open source framework for transferring files and data between Mac and iPhone applications
• “TagDefaultImage”, a command line tool to tag text to Default.png images during a build phase in XCode.

There’s also a new sample movie of iMBiPhoneView in a real world application on the iMBiPhoneView page.

To access the Developer Tools page, click onto the “Developer” icon in the upper left of the Pleasant Software homepage:

We recently introduced a new section on the Pleasant Software homepage: “Pleasant Software Developer Tools“.

Currently there are two free developer tools/frameworks available from Pleasant Software:

• “iMBiPhoneView”, an open source framework for transferring files and data between Mac and iPhone applications
• “TagDefaultImage”, a command line tool to tag text to Default.png images during a build phase in XCode.

There’s also a new sample movie of iMBiPhoneView in a real world application on the iMBiPhoneView page.

To access the Developer Tools page, click onto the “Developer” icon in the upper left of the Pleasant Software homepage:

With the release of v1.1 of Birdie we encountered the following problem: where to put a user readable version number without introducing some kind of “splash screen”?

One solution for this is, to put a text with the version number on the “Default.png”. This is an image which is displayed immediately when launching an iPhone app until the application is fully loaded and initialized. Usually this image is a “neutral” screenshot of the application itself.

The problem with this solution is, that the developer has to edit the Default.png each time in a grafic editor to set a new version number. This gets even worse, when the application uses mutliple localized Default.png files.

To solve this issue, I wrote a small command line tool, which takes a “blank” Default.png, writes some text on in (usually the version number) and writes the result back to disk. This way this process can be easily integrated into the build process of the application. The only thing which has to be changed between releases is the version number itself, which may be a build setting.

Here’s an example of how this works in Birdie’s Xcode project:

In the application target a new script build phase has been inserted as the first build phase. It contains the calls of TagDefaultImage for each localized Default.png in the project:

(click on the thumbnail for a full size view)

I use a user defined build setting variable “BUILD_VERSION” for the version number. So all I have to change is only this variable in the target’s build settings. Of course, this BUILD_VERSION variable is also used in my Info.plist to define the application’s bundle version.

If you’re interested, you can download TagDefaultImage for free.

Call TagDefaultImage without any arguments to see a list of available options:
Usage:
TagDefaultImage [args]

args:
--fontname (-f): fully specified family-face name, such as Helvetica-BoldOblique or Times-Roman.
--fontsize (-s): font size in Point.
--posx (-x): x position of text.
--posy (-y): y position of text.
--text (-t): text.
--in (-i): path to background image file.
--out (-o): targetpath.
--color (-c): font color 0. - 1. (black).

If you like it, please leave a comment below. Also any feedback is highly appreciated!