The last month has been running at a furious pace. In addition to the Christmas and New Year holidays, a lot has happened in Jamoma and TTBlue. The results of this leaves Tap.Tools in a somewhat unsettled state, but more on that later…

Leaving the Jamoma Workshop a lot of clean up and bug fixes have been done. Trond and Nils have also been contributing to the expansion of the Dataspace library. I also have been spending a lot of time on the next big Jamoma version, 0.5, which is the version that will support Max 5 when it is released.

Over the last couple of weeks focus has also shifted back to TTBlue (a framework for building audio objects). TTBlue has been feeling a bit lost lately. A year ago it started wandering into a more convoluted C++ direction to try and address a variety of architectural problems (version 0.3.x). This past fall TTBlue then changed shapes and started to become an Objective-C library (version 0.4.x). The woes that I experienced with ObjC on Windows (which was confirmed by Dave Watson, among others), and the need to have TTBlue available in Jamoma (which is cross-platform) ultimately saw the Objective-C version fall out of favor.

The answer to all of this is the new line of TTBlue development (version 0.5.x). This version takes us back to C++ again, but starting over with a lot of fresh ideas taken from the Objective-C version. In particular, this new TTBlue doesn’t simply used c++ function calls. It has it’s own message sending system to mirror what is done in other dynamically-bound languages such as Objective-C. Trond Lossius and I have been working on this in some real-world applications and it seems to really be coming along and working well.

Much like we introduced =jcom.map= in Jamoma last month as a swiss army knife for applying functions to data, this week we have introduced tt.filter~. This is an audio object that can be dynamically changed between a number of different filters.

Once version 0.5 of TTBlue stabilizes and is bit more fleshed out then we will switch Jamoma to using it.

Tap.Tools will also need to use it, which means throwing out everything that has been done on Tap.Tools 3. Not writing in Objective-C also means that 64-bit objects are in jeopardy. Finally, one of the really nice new objects that was going to be a major feature of Tap.Tools 3 was a dynamically changeable audio filter object for any number of channels—but now that Trond and I have created that and it’s open-source/free I’m not sure how that impacts things. So Tap.Tools 3 is surrounded by question marks, but I personally believe that this type of things is much better off as an open source project anyway, so I have no regrets about it.

Perhaps development on the Tap.Tools front will be scaled back to a Tap.Tools 2.5 release which is solely focused on Max 5 compatibility. We’ll see.