TTBlue 0.5.1 has been released over at the TTBlue project site.

It makes a few improvements to the way messages and attributes are handled within TTBlue. In turn, this fixes a bunch of crashes on Windows.

TTBlue version 0.5 is now released!

It still has warts, but the foundation is in place and it has proven to be stable over the last month. The details can be found @ http://code.google.com/p/ttblue/wiki/ChangeLog.

Having solidified this code over the last couple of months has been really good. Not only because of Tap.Tools 3, but also because it sets a good foundation for the upcoming Jamoma workshops following NIME.

If contributing to TTBlue is something of interest, please check out the resources at the development site, and/or join up on the TTBlue forum/mailing-list.

• http://code.google.com/p/ttblue/
• http://groups.google.com/group/ttblue

Currently TTBlue is being developed by a group of 3 of us, and it would be nice to grow the group a bit.

For a while now, TTBlue has been a sojourner. It was hosted solely on SourceForge for a couple of years, but then partially moved to being hosted on electrotap.net and partially remained on SourceForge. The main issue was wanting a wiki and an easier/better issue tracking system.

Today, TTBlue moved to Google. The issue tracking system is superior, as is the wiki. The new project site is here:

• http://code.google.com/p/ttblue

From that site there are links to the new mailing-list / forums. The info is all there for the wiki, issue tracking, and source code. As before, the current development is all happening in branches/active. The trunk will be updated when TTBlue 0.5 is released (hopefully next month).

TTBlue 0.5 is the critical underpinning of Tap.Tools 3 and underlies the upcoming Jamoma 0.5.

Thinking out loud here tonight…

When a TTBlue object is deleted, then it is simply gone. Poof. If some other code tries to call a method in then we crash. Poof.

What we need to add is notifications. Currently we have dynamically bound messages vis sendMessage() and attributes vie setAttributeValue(). These are for communicating things inside of an object. For communicating outside of the object we will need to add something like sendNotification().

How should this work?

It seems that TTObject should have a method like:

 subscribeNotification(TTSymbol& name) 

Which adds a function pointer to a list. This implies that we also need an unsubscribeNotification().

Then when the object calls sendNotification(), it looks in the list for anything subscribed to this particular symbol for the object and calls the function(s) it finds.

Do this will allow client code to know that a TTObject has disappeared. This is very important.

In the particular context I’m in, Jamoma, I wonder if this is actually going to be good enough to solve the current FunctionLib crash I’m working on. I need to think about it after some sleep… The problem with this FunctionLib crash is that there are things going on in multiple threads…

I just had a good conversation with Jesse, and it looks like things are cooking for Electrotap. A number of new things are around the corner, all in keeping with the Electrotap commitment to making tools for interactive art and music easier to use for real people.

• ObjectiveMax should be released soon for the Mac. This is a framework for creating Max objects using some human-friendly Objective-C.
• Tap.Tools 2.5 should hopefully be beta-ready quite soon. We decided to put Tap.Tools 3 aside for a while to make sure it is done properly and release a version 2.5 which will be Max 5-compatible. This also means people won’t have to pay to upgrade Tap.Tools when upgrading Max, which should be a nice gesture to the community (and it means we will be able to sleep with ourselves).
• The are some cool new sensor-related things currently in prototyping for later this year.
• Jamoma and TTBlue are currently coming along, with Jamoma work focusing on Max 5 compatibility.
• And then there are some other things we can’t talk about just yet ;-)

So much for sleeping this year!

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.

Setting up the Environment

I was very happy to get a comment from the main impetus behind Cocotron the other day. He pointed out some important things that were not at all obvious:

• The main Cocotron site is out of date
• The best information can be had on the Cocotron mailing list (hosted by Google)

This information doesn’t seem to be all in one place, so I’ll summarize how I got Cocotron working (I’m on OS 10.5.1 and using Xcode 3 at the moment).

First, I checked out the Cocotron source via SVN from the URL provided here: http://code.google.com/p/cocotron/source

Second, You need to install the Cocotron Dev Tools (CDT)—this is what provides the ability to cross-compile from Xcode: meaning compile for Windows and the Mac both from Xcode. The link on the site is out of date, the only link I found to a more recent version was in the Cocotron forums. That link is: http://www.cocotron.org/Tools/Downloads/InstallCDT-2007-10-10.zip

Third, the forum details some extra steps required because Apple changed some things in Xcode 2.5/3.0. The relevant post to the forum is here: http://groups.google.com/group/cocotron-dev/browse_thread/thread/aa427e195be9a86a

What that says to do is run this in the terminal:

ditto ~/Library/Application\ Support/Xcode ~/Library/Application\ Support/Developer/Shared/Xcode

Fourth, you need to actually compile the Cocotron frameworks.

• Build ApplicationServices.xcodeproj
• Build AppKit.xcodeproj
• Build Foundation.xcodeproj
• Build Cocoa.xcodeproj

So that sets up the environment. Now what?

Actually building something

To test that it actually works (and to grab a sample Xcode project with the correct target settings), I downloaded the TextEditor example from this page: http://www.cocotron.org/Code/Examples/

I compiled the Mac version, and it worked fine.

So I compiled the Windows version, copied it to a flash drive to try on the Windows machine. Hmmm. Didn’t work because I needed to copy the frameworks (dlls) to the Windows directory in the application bundle. That is documented here: http://www.cocotron.org/Code/Documentation/Things_You_Need_To_Know/

It actually took a minute to find out where these build frameworks were located. The answer is in /Developer/Cocotron. So I copied the AppKit, Cocoa, and Foundation dlls into the same folder as TextEditor.exe. Over on Windows, TextEditor.exe launches, but any time I try to click on a menu it crashes.

That documentation I last referred to also said to copy the frameworks. It isn’t readily apparent what it is referring to, since there are several options. I choose to try the option that had the exact name as spelled in the documention—so that meant copying /System/Library/Frameworks/AppKit.framework and friends. One downside to this is that it made our nice little text editor leap from 4MB to over 100MB. The other downside is that it made no difference.

So it isn’t flawless, obviously. Of course by checking out from SVN I could have just gotten things at a bad time when a few things are out of sync or not fully tested.

For writing plug-ins to run in Max/MSP we are really just interested in using the Foundation though, and not the AppKit. So maybe I’ll have better luck with that when I try it…

An alternative to GNUstep for cross-platform ObjC development, that seems to be generally much better, is Cocotron. I’ve looked at it a few times. Info can be found here: http://www.cocotron.org/

A really nice feature that it claims (I haven’t tried it) is that you can compile from Xcode on your Mac and have it build a Windows binaries.

Unfortunately it is incomplete. One of the things it lacks is support for Key-Value coding, which is one of the basic elements that is required by the MaxObject framework I’ve been working on and the ObjC version of TTBlue.

That means I can’t use it.

I’ve now spent an untold amount of time working on getting Objective-C Max Objects working on Windows. Anytime I get something working, it seems that it will be broken in about 5 minutes. The problem is that GNUstep is totally ridiculous.

GNUstep fancies itself as making everyone’s life easier for developing with Objective-C. Quite the opposite is true. Instead of making things work with normal make files, they have their own system of make files that goes through many mazes of indirection, and makes it impossible to work with any of the myriad of tools available for makefiles.

And then they delude you into thinking that they are compatible with the basic workings of Apple’s objc implementation. But it isn’t really true. In some cases they think they are smart and have come up with some faster ways of doing things, and so made their own functions instead of doing something compatible. This is not helpful!

GNU is supposed to stand for “GNU’s not Unix”. Given my various experiences with some of this software, and especially with GNUstep, I have a new one: “GNU’s not usable”.

One thing that has always been a bit of challenge, or at least a bit tedious, for me is to create externals for Max/MSP that process more channels than just mono.

I was playing with a lowpass filter that Trond Lossius just added to TTBlue tonight, and it was trivial to turn it into an MSP external that could have from 1 to 32 channels of audio processing. This is part of what I was trying to accomplish, so I’m very happy to end the evening with this little success :-).

Hopefully it will lead to more development of multichannel external objects.