Pete Cole from Intermorphic

Noatikl 2

2012-01-23T16:16:00.000Z

We've been working very hard on Noatikl 2, and it is going to be a huge improvement on Noatikl 1.x!

Noatikl 2 will include built-in support for the Partikl synth that has already been featured in Mixtikl (in addition to all of Noatikl's traditional MIDI I/O options).

When Noatikl 2 launches later this year, it will be available directly from the Mac App Store in standalone form (Windows versions and Mac Plug-in variants will be on the Intermorphic web store as usual). We're also planning to bring it to both iOS and Android at some point this year. :)

Pete

Mixtikl on Kindle Fire!

2011-12-24T16:34:00.000Z

I got hold of a Kindle Fire via a re-seller on eBay UK, so we could make sure that Mixtikl worked fine on there.

This being Android, Mixtikl worked first time! I installed Mixtikl using "adb install", having first configured adb to recognise the Kindle Fire.

I changed just a couple of things to make it "Kindle Fire friendly". Those being:
- I had to increase the audio latency a bit to prevent audio break-up; that took just a few minutes...
- I had to account for Kindle Fire's taking-up the bottom 20 pixels to display the soft menu bar, which was also very easy...

I must say that Mixtikl works *really* well on the Kindle Fire. The Mixtikl icon doesn't display at the moment; but I have read that is because the icon is downloaded only when you purchase the app from the Amazon Kindle App Store.

I should say that I'm really very impressed with the Kindle Fire! It is a really nice size, fabulous for reading books (thanks to the touch screen, which isn't on the older Kindle of course). It seems very fast, with a lovely clear display and it is very responsive. Will I like it more than my iPad 1? Well, I prefer the size of the Kindle Fire, and like the stereo speakers; and I like that it was so easy to get our app running on it. :) The iPad has the advantage of having lots of good quality games for it... but it is *very* much more expensive ... if the Kindle Fire had more storage space, it'd make quite a nice MP3 player.

It's a pain that the Amazon App store is US-only at the moment, but I'm sure they'll roll that out worldwide soon enough. I think they're going to sell huge numbers of Kindle Fires!

I also want to mention that so far, the Amazon developer support team have been *incredibly* responsive to the questions I've had; I'm genuinely impressed!

Pete

Mixtikl on Android - reprise

2011-12-19T09:16:00.002Z

The port of Mixtikl to Android is now complete.

I thought I'd share how I ended-up porting Mixtikl to Android, as this has been a long road!

When I first started looking at porting Mixtikl to Android, there were a couple of blocking issues;
- no support for C++ template library (though eventually STLPort arrived!)
- the original Mixtikl made heavy use of Modal code for dialog handling
Both of those two items made a port with Android a non-starter.

However, when Airplay (now renamed to Marmalade) added Android support, we were able to attempt a port of Mixtikl; as Airplay contained both C++ template library support, and supported modal code.
Ultimately however, the audio had too many problems (very, very high latency, mono only etc.) and this made the Airplay-based port too low quality to allow us to release.

Time moves on however, and a while back, Google added full support for the C++ standard template library to the Android NDK. And, critically, they added support for both OpenSL (to Android 2.3), and 32-bit ARM code generation (via armeabi-v7a). Given those changes, we spend a month or so removing all the modal code from Mixtikl (not an easy undertaking: you have to bear in mind that Mixtikl is > 500K lines of C++ code!).

So, given those changes in both the Android NDK and Mixtikl's own internal architecture, we were able to start and complete a full native port of Mixtikl to Android.

The bulk of Mixtikl remains in C++; all the graphics are drawn via the same C++-based graphics engine we use on all platforms. The interaction with Java is just a thin JNI layer that looks after drawing primitives and some native dialog interfacing. The OpenSL support is just a thin adaptor layer between our audio engine and OpenSL.

Mixtikl performs brilliantly on Android in my opinion; though as noted elsewhere the Android OpenSL implementation is missing a big trick in regards latency management; and we have to configure Mixtikl to run with slightly higher latency that we would like in order to avoid any potential audio break-up.

I should note that debugging C++ code on Android remains a pain, you have to rely on trace statements, though it is at least possible now to use gdb and the bt command to trap crashes when they happen and see where the code died in the call stack. The good news is that Mixtikl is very solid as 99% of the code is cross-platform and very well tested, so I've hardly had to touch gdb!

Android - how to reduce the audio latency

2011-12-06T09:26:00.000Z

I been approached a few times recently about how to write low-latency audio latency apps in Android, and I point such queries to OpenSL and say "look how much better it is that it used to be" (provided you use C++ of course)...

But the bottom line is that the Android audio APIs - and that includes OpenSL - still miss the basic trick, which is to be able to offer a programmatic contract that is as simple as this:

App : what sets of audio rates and formats do you support?
(API responds, maybe only 22Khz stereo, for sake of simplicity here)
App asks: how many audio blocks do I need to keep prepared and primed in the queue to guarantee no break-up, at this rate/format, with minimal latency?
(API responds, maybe 2 blocks of 512 sample frames each).
App prepares the first 2 blocks, submits, and gets "block delivery" callbacks; it runs a separate thread to keep internal queues topped-up ready to deliver to the callbacks.

With that sort of contract, every app can run at minimal latency dictated by the underlying audio device (through the driver layer), on any device. Without that sort of contract, every app developer is kept guessing, and has to assume a worst case that works on all devices available for testing. :)

I implemented this scheme nearly a decade ago in the intent Sound System (I had the luxury of designing and implementing a complete audio architecture for mobile devices from scratch!). It is a piece of cake to do, and IMO audio developers for Android are screaming for it. Intent was focused on ultra-low audio latency for games / multimedia and musical instruments...

I should note, Apple have also missed the same trick - they've been able to get away with it however, as the offer a fixed range of hardware....

Android - high performance audio - how to do it

2011-12-04T00:36:00.004Z

I've just been through a very interesting period of work, sorting-out a high-performance audio interface for the Android port of Mixtikl. I've learned quite a few things - here are the highlights.

Firstly, target Android 2.3 or later. This allows you to use OpenSL ES, which is the only realistic approach for low-latency audio on Android. The audio allows you to delivery audio with pretty low latency, and totally avoids any problems of garbage collection blocking you. This of course assumes that all your audio code is written in C++!

As you're using OpenSL ES, and assuming you have some very heavy audio DSP going-on (like in Mixtikl!), you'll need to use a separate Posix thread to keep your audio callbacks pumped-up. Basically, if your OpenSL ES audio block callbacks take much time at all, then your audio will break-up. So, use a worker thread to keep sufficient audio pre-processed and ready to be picked-up and delivered via your callbacks!

Finally, and believe me this is important (!): make sure you target armeabi-v7a, and that you use the right compiler flags to generate 32-bit ARM7 code. If you on the other hand use the default settings, you'll generate Thumb code for armeabi - and your code will run staggeringly slower (!!), and audio break-up is inevitable if you're doing anything serious. So: don't bother targeting armeabi devices... and Thumb code is a no-no.

Follow my advice, and you can create sophisticated audio software. Don't follow it, and you're going to find things tough! ;)

I should note that support for armeabi-v7a *emulator* targets arrived in the Android 4.0 SDK... which makes things a lot easier as well... something worth knowing!

Finally... here is a useful resource on the background to OpenSL ES on Android...:
http://mobilepearls.com/labs/native-android-api/opensles/index.html

gdb with the Android NDK - now easy with ddd wrapping ndk-gdb!

2011-10-21T14:26:00.002+01:00

You might already know this, but android debugging from gdb is now really, really easy - if you can stomach gdb!

See Android/ndk6/docs/NDK-GDB.html in your NDK documentation.

Basically, the app's libs/armeabi folder must have a gdbserver in it... which is put there automatically by the ndk-build command (remember not to ship your app with gdbserver in it!):

So...: build your app, install with e.g.:

adb install -r myfile.apk

Start your app directly from the Android UI, and in a terminal, change to your product's jni folder, and you're ready to debug!

Using command-line gdb

If you prefer command-line gdb, type this:

ndk-gdb com.example.myproject

You'll find that ndk-gdb will break as your app attaches. Set a breakpoint if you want (optional!), e.g.:

b Java_com_example_hellojni_HelloJni_stringFromJNI

Enter "cont" to continue...

And the debugger will now hit your breakpoints - use normal gdb commands to control it!

Using the graphical ddd debugger

If, like me, you prefer to use a graphical debugger, it is really easy to use ddd as a wrapper around gdb!

Many thanks to a blog reader for this suggestion!

It is really easy to use ddd instead... here are the steps!

Preparation:

1. Install ddd ...!
2. Modify your ndk-gdb shells script, to simply comment-out the "exit 1" call when an unexpected argument is passed

Running ddd

Start your app from Eclipse

In a terminal window, change to your project's jni folder (if you're not there already!)
Run ddd like this - and that is all there is to it!

ddd --debugger ndk-gdb

Eclipse

Using gdb for JNI/NDK from Eclipse is way too painful - I wouldn't bother. :)

Run-time breakpoints

On a final note, you can use this code to force a breakpoint at runtime...

    #define BREAKPOINT __asm__ ("bkpt 0")
    printf ("Hitting breakpoint!");
    BREAKPOINT;
    printf ("Gone past breakpoint!");

Mixtikl 5... iOS/Mac/Windows

2011-09-23T08:20:00.000+01:00

Work on Mixtikl 5 is keeping me very busy... we've decided that Mixtikl 5 will be the first version we release for Android. However, we'll focus first on finishing-off the iOS / Mac /Windows versions...

Android - using findbugs from outside of Eclipse

2011-09-02T10:08:00.001+01:00

I've been using findbugs to help track-down issues in Java code. A great tool, and very easy to use. However, the Eclipse-based plug-in keeps crashing for me with a NullPointerException on certain projects.

The work-around to this is to run the findbugs UI directly.

To use findbugs on Windows, get the latest findbugs distribution from http://findbugs.sourceforge.net/downloads.html, and then create a shortcut along the following lines (note the -X argument, as the JVM might require quite a bit of memory to avoid failing for big projects!):

\java.exe -Xmx1024m -jar C:\findbugs-1.3.9\lib\findbugs.jar -gui

On Mac, simply run something like this directly:

java -Xmx1024m -jar ~/findbugs-1.3.9/lib/findbugs.jar -gui &

It is really use to use - just select File -> New Project, add your class folders to the top pane, your source folders to the bottom pane, and let it run!

Upgrade to XCode 4.1 - problems with VALID_ARCHS for iOS Simulator builds

2011-08-30T09:05:00.000+01:00

Now that I've taken the plunge and moved to XCode 4.x from XCode 3.x ... I had a really weird problem trying to build my iOS projects for the simulator.

The builds failed with an error related to the i386 architecture. I simply couldn't figure-out how to solve this directly with the XCode IDE.

Luckily, I did manage to figure-out a fix: my solution was to edit the project.pbxproj files by hand with vim, and remove a handul of fixed definitions of VALID_ARCHS ... which presumably were legacies from previous XCode versions. This is not the first time that I've been forced to fix XCode projects by hand!

Mac - how to build installs the easy way

2011-08-29T13:43:00.001+01:00

I was having some issues getting my Mac installers (using packagemaker) working with the latest XCode.

Surfing-around, I found an amazing free tool called Packages. The link is here:

http://s.sudre.free.fr/Software/Packages/about.html

I've changed our own installers to use this, and all my Mac install problems have disappeared with an hours work. :)

Pete

Audio and MIDI Visualization in iOS and Android

2011-08-10T09:15:00.001+01:00

I've spent the past month focused mainly on Intermorphic's Audio/MIDI visualizer framework, dusting-down the work I did (in the main) several years ago, and bringing it all up-to-date.

I've recently experimented with lots of stuff, 2D and 3D, on iOS (UIKit ,Quartz, Core Animation and OpenGL ES) and Android (Canvas and OpenGL ES), and have learned a lot about performance differences between these approaches. I've also learned that OpenGL ES is a truly horrible API in which to get things done. :)

Anyways - things are coming on nicely: the next update for Mixtikl should be another good one!

Android - turn key events into UTF8

2011-08-03T11:53:00.000+01:00

As I've been asked a few times how to turn Android key events into UTF8 data, I figured it might be a good idea to share this info in my blog! It is actually really easy:

@Override
public boolean onKeyDown(int keyCode, KeyEvent event) {
    int [] unicodePoints = new int[1];
    unicodePoints[0] = event.getUnicodeChar();
    String x = new String(unicodePoints, 0, 1);
    byte utf8Bytes[];
    try {
      utf8Bytes = x.getBytes("UTF-8");
      // Do something with your UTF-8 data here!
      // ....
      // ...
    } catch (UnsupportedEncodingException e) {
      Log.e(TAG, "Failed to key event to UTF8");
      Throw(e);
    }
    return true;
}

Mixtikl on Android - with the NDK and C++

2011-07-26T20:29:00.000+01:00

Mixtikl is now around 95% complete on Android.

I've actually ported directly with the NDK/C++, without using Juce, as my 2d portability layer for Mixtikl is so highly developed. The port only took around a week (having already done a lot of background work in the previous few months laying the ground for this and possibly other ports!).

The Audio drivers have caused some fun; I've ended-up implementing support for AudioTrack and AudioRecord in native code with pthreads. Audio support in Android really is very poor...

The biggest headache is the basic problem of debugging C++ code on Android; I'm reduced to using trace statements. It helps that 99% of the code in Mixtikl is cross-platform and fully debugged on other platforms!

That said, the latest NDK (R6) is much improved with STL support and what have you; there is no longer any need to use Crystax.

I'm still very likely to use Juce for the Liptikl and Noatikl ports to Android, of course!

Juce, C++ and Android

2011-06-30T08:37:00.000+01:00

I've been experimenting with using the fabulous Juce to create programs for Android using C++.

You can find out about Juce here: http://www.rawmaterialsoftware.com/juce.php

If you haven't used Juce yet - give it a go! I've been using it for years now to create cross-platform programs for Mac and Windows...

SourceTree - git app for Mac

2011-01-31T10:27:00.000Z

I've started using SourceTree for painlessly reviewing historical changes in my Mac's git repository.

Steve (the SourceTree developer) has just added a feature which easily allows you to visualise changes between arbitrary versions of any given file, which is far easier than trying to do with the git command-line tools!

Give it a try - its a really nice tool!

How to debug Android NDK code using Eclipse

2010-11-01T11:40:00.000Z

This looks very useful, though I have yet to try it!

http://www.eclipse.org/sequoyah/documentation/native_debug.php

Android: creating pop-up menus at specific screen locations

2010-10-07T11:59:00.002+01:00

If you need to create a pop-up menu in Android, anchored to a specific View on the screen you could use this simple code as a template:
http://www.londatiga.net/it/how-to-create-quickaction-dialog-in-android/

However, what if you want your pop-up to appear at a particular position on screen, where you don't have a View to anchor to (maybe to overlay some other element on-screen that you don't have ownership of)?

My solution was as follows:
- Create a new Linear Layout to use as a "canvas" - call it my_canvas - and set to fill parent.
- Create a single ImageView (with empty drawable - it'll remain invisible!) within that layout, set to wrap content; call it my_canvas_image.
- We then create dynamically a view based on the layout, with left and right margin properties to pixel-position to the correct place on screen; use the image in that view as the anchor for our pop-up; and remove the view when done.

When your activity is created, grab the ViewGroup used to create the main activity layout like this:

    LayoutInflater inflater = (LayoutInflater)getApplicationContext().getSystemService(Context.LAYOUT_INFLATER_SERVICE);
    ViewGroup appViewGroup = (ViewGroup) inflater.inflate(R.layout.myApp, null);
    setContentView(appView);

When you need to create the pop-up at a given screen location, you can use code like this:

    WindowManager windowManager = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE);
    int screenWidth = windowManager.getDefaultDisplay().getWidth();
    int screenHeight = windowManager.getDefaultDisplay().getHeight();

    LinearLayout.LayoutParams paramsx = new LinearLayout.LayoutParams(screenWidth, screenHeight);
    paramsx.leftMargin = putPopUpHereX;
    paramsx.topMargin = putPopUpHereY;

    LayoutInflater inflater = (LayoutInflater)context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
    View canvasView = inflater.inflate(R.layout.my_canvas, null);

    appViewGroup.addView(canvasView);

    ImageView imageViewUseAsAnchor = (ImageView) canvasView.findViewById(R.id.my_canvas_image);

... the imageViewUseAsAnchor item can then be used as the "anchor" to which to attach the pop-up menu at your required screen location!

When you've finished, you can then remove the "canvas" view with:

    appViewGroup.removeView(canvasView);

The art of scalable Android Layouts

2010-09-28T08:41:00.000+01:00

One of the harder things to figure-out in Android, is how to do nice layouts that work well on different screen sizes. And, as always, I found it difficult to track-down that information!

The key for me in many circumstances is to position elements in percentage terms, generally using fill_parent; this is the opposite of most of the examples I have seen, which tend to use wrap_content! My approach is to ensure that size is defined in relative terms from the top-down using layout_weight; rather than allowing children to dictate their own size (and thereby mess-up the overall layout) via wrap_content...!

Here is a simple example of my approach.

Imagine you have a screen which you want to split into two panels, aligned horizontally, where you want the right-most panel to take-up around 20% of the screen size.

Create a new layout which is a frame layout. Set layout_width and layout_height to fill_parent. We'll use this for most other elements.

Create a LinearLayout within the frame parent. Set orientation to horizontal. Set layout_width and layout_height to fill_parent.

Create two elements (whatever type you need for your panels, maybe ImageView with a drawable background picture if you're just experimenting) as children of your new LinearLayout. Set both to have layout_width of 0dp and layout_weight of 50. If you want one layout to be wider than the other, simple adjust the weights; the element with the larger weight will be bigger proportionately. Make sure you sent layout_height to be fill_parent; otherwise the panels won't properly fill the screen in different configurations!

Want to split-up your right-hand panel into two vertical elements? Replace your right-hand element with a new LinearLayout. Set layout_width to 0dp, and layout_weight to whatever your previous right-hand element was (e.g. 50). Set orientation to vertical. Set layout_height to fill_parent. Put two new elements (again, maybe ImageViews for example...) in the new LinearLayout; set both to have layout_height of 0dp and layout_weight of 50. If you want one layout to be taller than the other, simple adjust the weights. Make sure you sent layout_width to be fill_parent; otherwise (as before!) the panels won't properly fill the screen in different configurations.

And so on! If you need to use an invisible spacer, you can simply follow the above approach and use an empty LinearLayout with the appropriate layout_weight.

This makes sense once you've tried it out; remember to test the layout you create with a variety of AVD sizes!

Android - building the PDK using the SDK, and adding a system service

2010-09-16T15:04:00.000+01:00

Just how difficult can it be to:
- download the Android source code
- figure-out how to add a system service
- call that service from an activity installed to the system after the event
- test this all out with the Android emulator.

The answer is: a lot harder than you might think!

Because this was a complete pain, involving a lot of fiddling-around and tracking-down and experimentation, I thought it would be a good to set-down the steps I had to follow. I really hope it helps somebody else out at some point!

I'm assuming that you're using Windows XP, Vista or 7 as your base machine.

Downloading the Android Source Code (Platform Development Kit - PDK)

The Android Platform Development Kit (PDK) download instructions are here.

http://source.android.com/source/download.html
First things first: install VirtualBox and install Ubuntu 32-bit as a Virtual Machine under Virtual Box.

Then install Android under this Virtual Machine.

You’ll require the java5 jdk.
The 64-bit build does not always work properly... it depends on which version of Android you’re using...:
http://groups.google.com/group/android-building/browse_thread/thread/193332fd6850a2a

All the open-source codelines that mirror Google's internal froyo

branches (i.e. froyo and the various android-2.2) use 1.5 like

Google's matching internal codelines do, since that is the version

that Google developed and tested with through the entire froyo

development cycle.

We backported the changes to switch to version 1.6 (64-bit) from our

internal master branch to the open-source master just as we switched

our internal master branch to 1.6, since from that point there was no

requirement for contributions to the open-source master branch to

build under 1.5 any more.

If you need to use the 64-bit version, then in order to complete the sudo apt-get install git-core ... command, you'll need to do this to get the correct JDK configured:

# Tell the system where to get the JDK...

sudo add-apt-repository "deb http://archive.canonical.com/ lucid partner"

# Update the source list:

sudo apt-get update

# Install sun-java6-jdk;

sudo apt-get install sun-java6-jdk

The build problems otherwise are very simiilar to those for the 32-bit system.

However, various blocker issues arose. I gave up, and reverted to 32-bit building...

IMPORTANT NOTE: use the following as your repo init command... otherwise, you’ll get “work-in-progress” which might not build (if you want a different Android source code tag other than froyo, then feel free to use one):

repo init -u git://android.git.kernel.org/platform/manifest.git -b froyo

If you have problems with Java, try doing this:

sudo update-java-alternatives -s java-1.5.0-sun

Building the Android Source Code

The Android PDK build instructions are here:

http://pdk.android.com/online-pdk/guide/build_system.html

Here is what I did.
cd ~/mydroid
lunch
# Choose 2. simulator
make

============================================

PLATFORM_VERSION_CODENAME=REL

PLATFORM_VERSION=2.2

TARGET_PRODUCT=sim

TARGET_BUILD_VARIANT=eng

TARGET_SIMULATOR=true

TARGET_BUILD_TYPE=debug

TARGET_BUILD_APPS=

TARGET_ARCH=x86

HOST_ARCH=x86

HOST_OS=linux

HOST_BUILD_TYPE=release

BUILD_ID=MASTER

============================================

Note: the alternative of trying choosecombo (selecting: simulator, debug, eng) isn’t recommended by Google heads; they recommend the use of lunch.

To fix this error...:

usr/include/bits/fcntl2.h:51: error: call to ‘__open_missing_mode’ declared with attribute error: open with O_CREAT in second argument needs 3 arguments

... I had to edit frameworks/base/core/jni/android_server_Watchdog.cpp
... and add this new argument at the end of the function call where the reference to O_CREAT:
, 0644);

http://forum.archosfans.com/viewtopic.php?t=11426&start=4

To fix this error...:

frameworks/base/opengl/libagl/egl.cpp: In member function ‘virtual EGLBoolean android::egl_window_surface_v2_t::swapBuffers()’: frameworks/base/opengl/libagl/egl.cpp:554: internal compiler error: in add_phi_arg, at tree-phinodes.c:391

... I had to remove the const on line 554 in frameworks/base/opengl/libagl/egl.cpp

http://stackoverflow.com/questions/3304951/build-android-system-on-ubuntu-10-04-x86-64-occrur-internal-compiler-error

If you get problems reported when building, related to a missing file called asoundlib.h, you’ll need to install these packages and then re-attempt the make:

libasound2-dev

lib32asound2-dev

If you get problems reported when building, related to a missing files called something similar to wx/wxprec.h, you’ll need to install this package (WxWidgets) and then re-attempt the make:

sudo apt-get install libwxgtk2.6-0 libwxbase2.6-0 libwxbase2.6-dev

If you get problems reported when building like this:

|~/mydroid/development/simulator/app/DeviceWindow.cpp:175: undefined reference to `wxImage::HasAlpha() const'

You’ll have to edit:

development/simulator/app/DeviceWindow.cpp - comment-out the lines to HasAlpha()

development/simulator/app/MainFrame.cpp - comment-out the lines to AppendSeparator()

Modify external/stlport/stl/_num_put.c in line 351. to use the first form of the #ifdef block (the second one, which would otherwise be chosen, causes compilation to fail).

Remove external/gtest/Android.mk, external/gtest/test/src/Android.mk and external/gtest/test/Android.mk (which had STL-related problems in my system!)

Installing the Android SDK

Download the Android 2.2 SDK from here:

http://developer.android.com/sdk/index.html

Expand the download file to e.g. ~/Downloads/android-sdk-linux_x86

Add this to your PATH, e.g. (but: make sure this comes before any other Android-related paths...):

export PATH=$PATH:~/Downloads/android-sdk-linux_x86

Restart your shell!

cd ~/Downloads/android-sdk-linux_x86/tools

export ANDROID_SWT=/home/mycompany/Downloads/android-sdk-linux_x86/tools/lib/x86

android

... Select and install the SDK Platform Android 2.2, API 8, revision 2

Further notes on installing the Android SDK 2.2

http://developer.android.com/sdk/installing.html

http://developer.android.com/sdk/adding-components.html

Now, copy the Platform SDK so that the PDK can find it!

# Create a new terminal, and then...

cd ~/mydroid

export PATH=/home/mycompany/mydroid/out/host/linux-x86/bin:$PATH

# Note that when you first do this, ~/mydroid/out/host/linux-x86/platforms and ~/mydroid/out/host/linux-x86/add-ons do NOT exist!

cp -pR \

~/Downloads/android-sdk-linux_x86/platforms \

out/host/linux-x86

Running the emulator with the newly built image

# Create a new terminal, and then...
cd ~/mydroid
export PATH=~/mydroid/out/host/linux-x86/bin:$PATH

export ANDROID_SWT="~/mydroid/out/host/linux-x86/framework"

# Now-up the emulator with the correct image!
./out/host/linux-x86/bin/emulator -system out/target/product/generic/system.img -sysdir out/target/product/generic -kernel prebuilt/android-arm/kernel/kernel-qemu -data out/target/product/generic/userdata.img

Adding a new service to the System

With reference to:
http://groups.google.com/group/android-porting/browse_thread/thread/f9a383ce949d1557?pli=1

Create a new service as frameworks/base/packages/IMyTest, as a very rough clone of frameworks/base/packages/SettingsProvider

Edit build/target/product/core.mk, to add the following line after the line showing DefaultContainerService :

MyTestService \

Create various files:

mydroid/frameworks/base/packages/MyTestService/AndroidManifest.xml

<manifest xmlns:android="http://schemas.android.com/apk/res/android"

package="com.mycompany">

<service android:name=".MyTestService"

android:enabled="true"

android:exported="true"/>

</application>

</manifest>

mydroid/frameworks/base/packages/MyTestService/Android.mk

LOCAL_PATH:= $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE_TAGS := optional

LOCAL_SRC_FILES := $(call all-subdir-java-files)

LOCAL_PACKAGE_NAME := MyTestService

LOCAL_CERTIFICATE := platform

include $(BUILD_PACKAGE)

mydroid/frameworks/base/packages/MyTestService/src/com/mycompany/MyTestService.java

package com.mycompany;

import com.mycompany.IMyTestService;

import com.android.internal.content.PackageHelper;

import android.content.Intent;

import android.content.pm.IPackageManager;

import android.content.pm.PackageInfo;

import android.content.pm.PackageInfoLite;

import android.content.pm.PackageManager;

import android.content.pm.PackageParser;

import android.net.Uri;

import android.os.Environment;

import android.os.IBinder;

import android.os.ParcelFileDescriptor;

import android.os.Process;

import android.os.RemoteException;

import android.os.ServiceManager;

import android.os.StatFs;

import android.app.IntentService;

import android.util.DisplayMetrics;

import android.util.Log;

import java.io.File;

import java.io.FileInputStream;

import java.io.FileNotFoundException;

import java.io.FileOutputStream;

import java.io.IOException;

import java.io.InputStream;

import android.os.FileUtils;

import android.provider.Settings;

// Based on src/com/android/defcontainer/DefaultContainerService.java

// Also see:

// frameworks/base/packages/MyTestService/AndroidManifest.mk

// frameworks/base/packages/MyTestService/Android.mk

// frameworks/base/core/java/com/mycompany/IMyTestService.aidl

// frameworks/base/Android.mk

// Note that the .aidl file can be used by external activity projects.

public class MyTestService extends IntentService {

private static final String TAG = "MyTestService";

private IMyTestService.Stub mBinder = new IMyTestService.Stub()

{

public void setValue(int val)

{

Log.i(TAG, "In setValue! ");

}

};

public MyTestService () {

super("MyTestService");

setIntentRedelivery(true);

}

@Override

protected void onHandleIntent(Intent intent)

{

Log.i(TAG, "onHandleIntent!");

}

public IBinder onBind(Intent intent) {

Log.i(TAG, "onBind!");

return mBinder;

}

mydroid/frameworks/base/packages/MyTestService/res/values/strings.xml

<?xml version="1.0" encoding="utf-8"?>

<string name="service_name">MyTestService</string>

</resources>

mydroid/frameworks/base/core/java/com/mycompany/IMyTestService.aidl

package com.mycompany;

interface IMyTestService {

/**

* {@hide}

void setValue(int val);

}

The interface file will need to be added to the build system, so edit frameworks/base/Android.mk
... and add the following at the end of the list of LOCAL_SRC_FILES:

core/java/com/mycompany/IMyTestService.aidl \

Type this to make... if you don’t do the make clobber, your new MyTestService.apk file won’t be built!

make clobber

make

You will now see this error reported:

(unknown): error 3: Added class IMyTestService to package android.os

(unknown): error 3: Added class IMyTestService.Stub to package android.os

******************************

You have tried to change the API from what has been previously approved.

To make these errors go away, you have two choices:

1) You can add "@hide" javadoc comments to the methods, etc. listed in the

errors above.

2) You can update current.xml by executing the following command:

make update-api

To submit the revised current.xml to the main Android repository,

you will need approval.

******************************

Type this to work-around this:

make update-api

Run this to verify that your new service is now in the build images...:

ls -ltr ~/mydroid/out/target/product/generic/system/app/MyTestService.apk

find . -name "*.img" | xargs -- grep "MyTestService.apk"

... This should show that the code you’ve created has appeared in ./userdata.img ...
Edit this to look for IMyTestService, to verify that it has been added!

~/mydroid/frameworks/base/api/current.xml

5. Test the service APk is picked-up by the emulator...

Start up the emulator (using the previous long command line!)
Using adb logcat, you will find the message saying that the package has changed.

I/PackageManager( 68): /system/app/MyTestService.apk changed; collecting cert

6. Test Program

To test the service, create a "Hello World" activity using the project wizard under Eclipse on Windows.

MyServiceTest.java:
package com.mycompany.MyServiceTest;
import android.app.Activity;
import android.content.ComponentName;
import android.content.Context;
import android.content.Intent;
import android.content.ServiceConnection;
import android.os.Bundle;
import android.os.IBinder;
import android.util.Log;
import com.mycompany.IMyTestService;
public class MyServiceTest extends Activity {
  /** Called when the activity is first created. */
  IMyTestService imts;
  private ServiceConnection mConnection = new ServiceConnection()
  {
     @Override
     public void onServiceConnected(ComponentName className, IBinder service)
     {
         Log.d("MyServiceTest", "onServiceConnected");
          imts= IMyTestService.Stub.asInterface(service);
         try
         {
             // Try a dummy call to the service!
              imts.setValue(7); // Any value would do, this is just a test!
         }
         catch (Exception e)
         {
             e.printStackTrace();
         }
     }
     @Override
     public void onServiceDisconnected(ComponentName arg0) {
         Log.d("MyServiceTest", "onServiceDisconnected");
          imts = null;
     }
  };
  @Override
  public void onCreate(Bundle savedInstanceState) {
     super.onCreate(savedInstanceState);
     Log.d("MyServiceTest", "onCreate");
     setContentView(R.layout.main);
     // Bind-in to our service!
     Log.d("MyServiceTest", "try to bind service");
     Intent intent = new Intent();
     intent.setClassName("com.mycompany", "com.mycompany.MyTestService");
     bindService(intent, mConnection, Context.BIND_AUTO_CREATE);
     Log.d("MyServiceTest", "done try to bind service");
  }
}

Copy the IMyTestService.aidl file from your Linux box, in your Windows/Eclipse project’s src/com/mycompany sub-folder (you’ll first have to create this folder in your activity’s project folders).

Refresh your project files from the Eclipse menu and rebuild/debug.

This should run benignly under Windows, warning that it was unable to find the service.

Copy the apk file to your Linux VM, and install using:

adb install MyServiceTest.apk

Run the app using the emulator’s launcher; you should see the service used!

I/MyTestService( 360): onBind!

D/MyServiceTest( 354): onServiceConnected

I/MyTestService( 360): In setValue!

Easy, wasn't it? :-D

Mixtikl - added clipboard support

2010-07-02T08:23:00.001+01:00

The new version of Mixtikl adds Intua Clipboard support for the iPhone/iPod/iPad version, amongst many other updates! This Mixtikl update is a big step forward for us, we're really looking forward to releasing it in a few weeks!

Android version of Mixtikl coming along

2010-05-26T22:23:00.000+01:00

The tidy-up phase of the Android port of Mixtikl is coming on nicely. My shortlist of things to do is getting very short. :)

Customized Android NDK r3 with enabled support of C++ exceptions, RTTI and Standard C++ Library

2010-05-20T14:58:00.000+01:00

This looks very useful... (thanks to Chris for the pointer!)

Customized Android NDK r3 with enabled support of C++ exceptions, RTTI and Standard C++ Library...

http://www.crystax.net/android/ndk-r3.php

Mixtikl on Android

2010-05-09T23:58:00.002+01:00

The Mixtikl port to Android has been making further good progress; I think we're now only a couple of weeks from first release... it is working pretty well on my HTC Hero device, as I type this.

Hopefully we'll be able to follow-suit with Symbian once the Android version is out of the door...!

MeeGo - how to download the source code using Cygwin / Windows

2010-05-06T11:09:00.002+01:00

You can get the very latest MeeGo source code from here:

http://repo.meego.com/MeeGo/devel/trunk/repo/source/

I downloaded all the rpm files easily enough using wget (under cygwin, on my Windows machine).

To extract the contents of the downloaded rpm files, do this for each rpm file (assuming you have the rpm tools installed with cygwin!):

rpm2cpio filexyz.rpm | cpio -idmv --no-absolute-filenames

Then...

For each extracted myfile.tar.gz file, do this:
tar -xvf myfile.tar.gz

And...

For each extracted myfile.tar.bz2 file, do this:
tar -jxvf myfile.tar.bz2

You will then have all the latest MeeGo source code extracted to your computer!

Mixtikl on Airplay - audio now working too!

2010-04-30T13:38:00.001+01:00

Good progress - Mixtikl's Audio is now working under the Airplay ARM simulator, so I now need to get it all up-and-running on an actual Android device. Fingers crossed. :)

Edit: Mixtikl is running under the Android simulator using Airplay - amazing. :-D

Many congratulations to Ideaworks!!

Mixtikl Airplay port - to Android/Symbian

2010-04-29T12:55:00.000+01:00

I've been porting Mixtikl to Qt and Airplay DK in parallel.

Now that the Qt port is done, I've also got the Airplay SDK port running in the ARM debugger emulator.

I've yet to add the audio hooks, and there are a couple of rough edges, but I'm looking forward to trying it all out in a few days on my HTC Hero Android phone!

Due to a weird problem with the Airplay SDK, I'm unable to link for X86 target (I'm waiting for a solution at http://airplaysdk.com/node/761). The same code builds fine however for the ARM Debugger - so at least I'm able to make progress. :)

The documentation has been pretty frustrating, so here are two useful tips to save you time!
- to blend-in an image, use Iw2DSetAlphaMode() to set a colour with the appropriate alpha channel setting before calling Iw2DDrawImage(); the alpha colour setting is used to blend the bitmap! Also, set the rgb values to other than 255, to scale the colour; useful to draw a white coloured bitmap in different colours, for example.
- if you want to clip, then call IwGxSetScissorScreenSpace(...) to define a clip window before any calls to Iw2D*(...).

The routine to query for pointer support didn't work for me - maybe I made the call wrong - I'm having to ignore the result from that call, I need to raise that in the forum once my build issue is resolved. :)

Anyways, Mixtikl now runs on the ARM emulator, so the next step is to complete the audio hooks and try on Android and Symbian devices!

Note: lack of support in Airplay for threads and clipboard will cut-back on some of the Mixtikl functionality for now on Android/Symbian... until those items are exposed in future Airplay updates!

Porting Mixtikl to Qt

2010-04-29T08:07:00.001+01:00

It didn't take me long to port Mixtikl to Qt: just a few days to get it all running. Of course, it helps that Mixtikl was designed to be portable. :)

The biggest gotcha was shown-up by a weird linker error relating to missing vtable for a class.

It turns out that this was for a few reasons!

1. If your class implements slots, the declaration *must* be put in a header file; put it in a .cpp file, and qmake won't won't find it and you get the vtable link error.
2. That header file MUST be in your .pro file's list of header files; forget this, qmake won't won't find it and you get the vtable link error.
3. Make sure your class has a special line added. You must have the Q_OBJECT line as the first line in your class prototype, as shown below - no punctuation at the end of the line!

class myclass : public QObject
{
  Q_OBJECT
  // ... rest of class follows
};

4. The class must be derived from a class that ultimately derives from QObject
5. Your slot implementation method must have a "slots:" line before it. e.g.:

public slots:
  void setValue(int value);

6. You must then run qmake from the console/terminal, while in the folder that contains your .pro file (that will rebuild the makefiles to pull-in the neceesary bits).

One more thing to mention: I found using QTimer to be problematic if using threads; use QThread instead to roll your own timers if you have problems. I had similar issues with NSTimer on iPhone...

Once you've figured that out, Qt is a piece of cake to use. A very easy to use, powerful, flexible C++ framework.

Airplay SDK - building C++ apps as Android .apk files - first impressions

2010-04-21T08:37:00.002+01:00

I noticed the other day that the Airplay SDK now uses modern C++ with STL - nice, and essential for my code. I already knew that the Airplay SDK supported Android, and having taking a look at my Android porting options I really didn't want to directly port my own C++ app code to Android using STL and JNI - there would be too much pain involved. :-0

So, having just installed the latest Android SDK on Windows 7 and Mac, I figured it was time - finally - to download and install the Airplay SDK evaluation.

In installed the Windows version on my Mac under Boot camp. This requires Visual Studio 2008 (the Express edition should work, if you're interested...).

Installation on Windows was easy, the eval license registered properly and I was soon following the instructions to build my first basic demo project. [I actually started with the Mac version - still in Beta - but it failed to register my eval license! Serves me right for starting with Beta software :)]

I double-clicked the example project file for a 3d demo game, which automatically constructed and opened a suitably configured Visual Studio project. Building this for the x86 target was as easy as building any other Visual Studio project - very simple.

Running-up the project under Visual Studio debugger for Windows, ran the app through a device emulator, which worked smoothly.

I next trivially rebuilt the app for ARM Debug target, ran under Visual Studio under ARM emulator on Windows - again this was easy and worked fine - it runs the app through an arm device Emulator, with a graphical version of GDB as the debugger.

Having rebuilt the app for ARM Release target, I next used a simple utility that comes with the Airplay SDK, to bundle-up the app an a .apk file (the installer format for Android). This was really easy. Note, however, that I first had to rename the Android SDK 1.6 folder on my PC (see the Airplay SDK forum for details on how/why!), and had to install a couple of other tools that are clearly documented in the Airplay documentation). Anyways: once your system is configured, building the .apk file is very easy. :)

I next installed the .apk to the Android SDK's emulator using the "adb install" command, and ran-up the application directly from Android SDK emulator. This worked OK, albeit with a slow frame rate I've been told that on devices the frame rate is very, very much faster than the emulator).

So, a really good experience so far. I'm looking forward to finding out more in due course. I was impressed enough to get a 99 dollar "indie" license; the "iPhone" license is actually free, which is very cool.

I'll need to find out how well it all works on a real Android device, and try some complex 2D graphics and heavy-duty audio, but the Airplay SDK so far looks very promising. It is powerful enough that it even looks like it'd be relatively straightforward to port frameworks like Qt to the Airplay SDK.

I found the online documentation to be a pain to navigate, but the documentation in Windows CHM file format (in the SDK) is pretty good.

The bottom line for me is how easy it was to get from generic C++ code, to a .apk file for Android - very impressive indeed. Not only that, the SDK supports buildling Symbian .sis files, Window Mobile .cab files ... and various other platforms. Plenty here to keep me busy and productive!

Edit: I've just discovered that Airplay doesn't support threads at the moment... which is problematic, to say the least!

Edit: I've heard via the Airplay forums that Thread support is coming in a few months ... which is very good news. :) Meanwhile, the port of Mixtikl to Android/Symbian via Airplay (and also a port of Mixtikl via Qt...) is coming along well, so maybe we'll have something to report in a few weeks...

Port Qt and/or SDL to Android

2010-04-19T15:28:00.000+01:00

I've been looking around to see if there are any ports of Qt or SDL to Android. This is by way of comparison to the Airplay SDK.

There are a couple of open-source projects that have been working towards this... though neither look pratical to my eyes at the moment.

Qt port to Android:
http://code.google.com/p/android-lighthouse/wiki/QADK

SDL port to Android:
http://www.anddev.org/viewtopic.php?p=40838

It is a shame that none of the bigger software development companies haven't done this already - the port of Qt would be especially useful!

Airplay, Android and in-app advertising

2010-04-18T21:32:00.000+01:00

I've been thinking around the subject of Android, and am pretty certain that the only tenable model for app distribution on this platform is with in-app advertising.

Of course, porting of a C++ app to Android is a complete pig, and I guess the option is either maybe via a port of SDL, or via Airplay.

The issue with Airplay is how to display in-app advertising; there is no way that I can see to invoke native code from Airplay!

Thinking around the subject, I was wondering if it were possible to install a native Android service that listens to a particular socket.

My thought is that Airplay could communicate with that service via the socket, to send request to display an ad in a native pop-up Window (the service handles the display of the ad, outside of the context of Airplay).

Anybody care to comment on this idea...? :-D

Pete

Performance-tuning example with gcc

2010-03-08T09:39:00.001Z

From time to time, I need to rip-apart functions to do some old-school performance tuning. This is really easy to do.

Here is an example file, called perf.c ... in it, I have two versions of a function. One is inefficient, the other is more efficient by virtue of being written slightly differently.


typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned int uint32_t;


// Inefficient inner loop

void byteswap (const uint8_t *PpFrom, uint8_t *PpDst, uint32_t PBytes)
{
    long i;
    long lWords = PBytes >> 1;

    for (i=0; i < lWords; i++)
    {
        unsigned lWord = ((const uint16_t*)PpFrom)[i];
        ((uint16_t*)PpDst)[i] = ((lWord & 0x0ff) << 8) | lWord >> 8;
    }
}

// Efficient inner loop

void byteswap_2 (const uint8_t *PpFrom, uint8_t *PpDst, uint32_t PBytes)
{
    uint32_t lWords = PBytes / 2;

    uint16_t* PpDstPtr = (uint16_t *)PpDst;
    uint16_t* PpDstEnd = PpDstPtr + lWords;

    const uint16_t* PpFromPtr = (const uint16_t *)PpFrom;
    for (;PpDstPtr < PpDstEnd;)
    {
        unsigned lWord = (*PpFromPtr++);
        (*PpDstPtr++) = ((lWord & 0x0ff) << 8) | lWord >> 8;
    }
}

From the command-line, run this command (assuming you have gcc!)

gcc -c -g -gstabs perf.c perf.s

This takes your source code (perf.c), and outputs the disassembled output to a file called perf.s ... which you can take a look at with your text editor.

In the file, the code generated for the first function looks like this:


.globl _byteswap
.def    _byteswap;  .scl    2;  .type   32; .endef
_byteswap:
LFB3:
.file 1 "perf.c"
.loc 1 9 0
pushl   %ebp
LCFI0:
movl    %esp, %ebp
LCFI1:
subl    $16, %esp
LCFI2:
.loc 1 11 0
movl    16(%ebp), %eax
shrl    %eax
movl    %eax, -8(%ebp)
.loc 1 13 0
movl    $0, -12(%ebp)
jmp L2
L3:
LBB2:
.loc 1 15 0
movl    8(%ebp), %edx
movl    -12(%ebp), %eax
addl    %eax, %eax
leal    (%edx,%eax), %eax
movzwl  (%eax), %eax
movzwl  %ax, %eax
movl    %eax, -4(%ebp)
.loc 1 16 0
movl    12(%ebp), %edx
movl    -12(%ebp), %eax
addl    %eax, %eax
leal    (%edx,%eax), %ecx
movl    -4(%ebp), %eax
movl    %eax, %edx
sall    $8, %edx
movl    -4(%ebp), %eax
shrl    $8, %eax
orl %edx, %eax
movw    %ax, (%ecx)
LBE2:
.loc 1 13 0
addl    $1, -12(%ebp)
L2:
movl    -12(%ebp), %eax
cmpl    -8(%ebp), %eax
jl  L3
.loc 1 18 0
leave
ret

The code generated for the second function looks like this:


.globl _byteswap_2
.def    _byteswap_2;    .scl    2;  .type   32; .endef
_byteswap_2:
LFB4:
.loc 1 21 0
pushl   %ebp
LCFI3:
movl    %esp, %ebp
LCFI4:
subl    $32, %esp
LCFI5:
.loc 1 22 0
movl    16(%ebp), %eax
shrl    %eax
movl    %eax, -20(%ebp)
.loc 1 24 0
movl    12(%ebp), %eax
movl    %eax, -16(%ebp)
.loc 1 25 0
movl    -20(%ebp), %eax
addl    %eax, %eax
addl    -16(%ebp), %eax
movl    %eax, -12(%ebp)
.loc 1 27 0
movl    8(%ebp), %eax
movl    %eax, -8(%ebp)
jmp L6
L7:
LBB3:
.loc 1 30 0
movl    -8(%ebp), %eax
movzwl  (%eax), %eax
movzwl  %ax, %eax
movl    %eax, -4(%ebp)
addl    $2, -8(%ebp)
.loc 1 31 0
movl    -4(%ebp), %eax
movl    %eax, %edx
sall    $8, %edx
movl    -4(%ebp), %eax
shrl    $8, %eax
orl %eax, %edx
movl    -16(%ebp), %eax
movw    %dx, (%eax)
addl    $2, -16(%ebp)
L6:
LBE3:
.loc 1 28 0
movl    -16(%ebp), %eax
cmpl    -12(%ebp), %eax
jb  L7
.loc 1 33 0
leave
ret

I've highlighted the assembly of the code generated for the two inner loops. Look how much more efficient the second version is, with only a simple bit of re-coding!

It should be easy using this approach to learn how to make your code more efficient, without much effort.

VisualBox, VMWare Player and Parallels

2010-03-01T09:57:00.000Z

I've done quite a bit of work over the past year with PC-hosted Linux (Ubuntu) VMs under VMWare Player, mainly for Android work. I got so fed up recently with the poor system integration (poor Mouse and Keyboard transitioning when moving to/from host and the VM, no copy/paste between Windows and the VM, limited support for VM desktop resizing, not easy to share file data between host and VM), that I decided to spend some time looking at VirtualBox.

After a day evaluating, I've now moved entirely to VirtualBox! I was even able to (easily) set-up 64-bit VMs running on 32-bit Windows, which was very handy; and it was simple to set-up a shared file area between host and VM.

I haven't yet tried VirtualBox on Mac, but I'm perfectly happy with Parallels 5 at the moment so haven't felt the need to use anything else on Mac...

Windows 7 on my Mac

2010-02-16T23:23:00.007Z

I finally took the plunge a few weeks back, and upgraded my Mac Book Pro hard drive (requiring a week with the Apple repair center to do the upgrade!), in preparation for replacing the Windows XP Boot Camp partition with a Windows 7 installation (with Windows XP moved from Boot Camp to a Parallels VM).

The transition was fiddly; I used Parallels Transporter to copy the Boot Camp XP to a virtual machine image on an external USB drive (which I then copied to the Mac Hard Drive). I had to use a USB drive, as I couldn't get Parallels Transporter to work over my LAN. Once I'd proved that the VM started OK (and was backed up to my RAID drive!), I then got rid of the boot camp partition, and tried to install Windows 7 in a larger Boot Camp partition. However... I found was that the Mac drive was too fragmented to resize the Boot Camp partition (!).

I did some reading around the subject, and was surprised to find that Macs don't have a defragmenter option...! My solution was not much fun, but was easier than it sounds: I cloned-off the hard drive using the incredible Super Duper! to another spare USB drive, double-checked that I could boot off that drive; then cloned-back the Super-Dupered drive back to replace the contents of my Mac Book drive. That fixed the fragmentation, so I could finally configure the Boot Camp partition as I wanted and proceed with installing Windows 7.

I chose a 64-bit install of Windows 7 so that I could use Mixtikl and Noatikl VST plug-ins in 64-bit mode under Windows.

Using 64-bit so far hasn't caused me too many problems; Beyond Compare (which is still isn't available in a 64-bit version) did't integrate at first with Windows Explorer. However, thanks to a comment from Aaron from Scooter Soft (see below), I found the configuration option that let me re-configuration as a shell extension, which now works perfectly!

There is also a 64-bit version of Tortise SVN which integrates with Windows Explorer OK. There is also a new version of Cygwin that works fine with Windows 7, and I found a 64-bit copy of GVim that integrates with Windows Explorer.

All in all, Windows 7 is quite a bit faster than XP (though still not as fast as Mac OS!), and is in general easier to use now that I've customised Windows Explorer to work more like that in Windows XP. After a week of use, XP already seems dated and I have no intention of going back to it other than for occasional software testing! I also love the way that out-of-the-box, Windows 7 gave me a read-only view of the HFS partition on my Mac.

So, what about a Windows 7 virtual desktop manager (Mac has the wonderful spaces built-in)? Well, simply install VirtuaWin - it works beautifully, and is open source!

Finally, you'll need Cygwin to get a greate scripting environment, which lets you share scripts between Windows and Mac.

That said, there are far more tools for Windows than for Mac... so I am happy to use both Windows and Mac, mixing-and-matching where required. Where would I be without Beyond Compare and Tortoise SVN on the Windows side, for example? :) The combined Mac OS X/Windows/Parallels/Bootcamp system really is a good one for code development...

64-bit Noatikl and Mixtikl...

2010-02-16T09:08:00.001Z

I'm currently working on creating 64-bit versions of Noatikl and Mixtikl...

This is made easier for us on the Mac, which supports the use of Universal Binaries; there is quite a lot more fiddling around to do on Windows, where I have to build both separate binaries and a dual-configuration install that includes both 32-bit and 64-bit components.

Incidentally, using Inno Setup makes building a mixed-mode install very easy; what a great tool.

Of course, having both 32-bit and 64-bit binaries makes testing even more time-consuming than usual...!

cygwin - alternative shells

2010-02-09T10:09:00.000Z

While I love cygwin, I've never been totally happy with the standard Cygwin Shell Console, mainly in the way that it handles copy/paste, fonts and colour setting. But mainly copy/paste. :)

Well, I've finally got around to reseaching some replacements, and like what I've found!

Basically, I found a couple of good alternatives: mintty and rxvt. Neither of these require use of X, and both are available as optional packages that you can select from the standard cygwin installation.

Note: neither of these work right with non-cygwin utilities that require piping. You need to keep the normal Cygwin Shell Console for that.

mintty (http://code.google.com/p/mintty/)

When you install this as a cygwin component, you'll find a shortcut created for you automatically under the Start menu.

Next, I modified the shortcut to look like this:

C:\cygwin\bin\mintty.exe bash -li

However, when I started cygwin using this shortcut, my normal .profile scripts weren't picked-up properly. To fix this, I had to modify /etc/profile and add a line like this...

export HOME=/cygdrive/c/home

mintty then launches.

What I love about this is that it gives a fully UTF-8 enabled shell, where it is really easy to cut/copy/paste text, and very easy to change colour schemes.

Just right-click on a mintty window to see the copy/paste etc. options; dead easy.

If you want to spawn-off a new console, use an alias like this:

alias mintty='mintty --size=100,70 bash --login -i &'

mintty

rxvt

This is also available under cygwin, but isn't fully Unicode aware, so isn't as good as mintty. You'll see problems for example when you try viewing a manual page; look at the funny text you get when you try this...:

man bash

That said, here is what I did to get it working.

Basically, I took a copy of the cygwin.bat file, and modified part of it like this:

rem bash --login -i
rxvt -sr -sl 2500 -sb -geometry 100x70 -fg black -bg white -tn rxvt -fn "Lucida Console-12" -e /usr/bin/bash --login -i

I also created an alias in my .profile file, that allows me to launch new rxvt windows easily.

alias rxvt='rxvt -sr -sl 2500 -sb -geometry 100x70 -fg black -bg white -tn rxvt -fn "Lucida Console-12" -e /usr/bin/bash --login -i&'

With rxvt, you get a paste operation in one of two ways:
- Ctrl-Shift-LeftButton
- middle (press mouse wheel) - no good for MacBook devices with Track pad!

Debugging Android native code - another useful link

2010-01-25T13:46:00.000Z

Another Android native code debugging link that you might find of use...:

http://pdk.android.com/online-pdk/guide/debugging_native.html

vim - how to force .cpp files to have Objective-C syntax highlighting

2010-01-24T12:21:00.006Z

This one has bugged me for a while - how to make vim and MacVim display .cpp files with full Objective-C++ syntax highlighting.

This is actually really easy to do; I can't believe it took me so long to figure out! Especially as I try to avoid using .m or .mm files in my projects, and almost exclusively use .cpp source files in all that I do to make my cross-platform work easier...

Anyways: all you have to do, is put these three lines in ~/.vim/filetype.vim (you'll almost certainly first have to create the .vim folder under your home directory...)


au BufNewFile,BufRead *.cpp set filetype=objcpp
au BufNewFile,BufRead *.h set filetype=objcpp
au BufNewFile,BufRead *.c set filetype=objcpp

Sorted! Whenever you use the built-in vim, or MacVim, to edit a .cpp/.c/.h file, you'll see any Objective-C code in your editor displayed with nice syntax highlighting; your C++ code will also look lovely too!

Mixtikl update for iPhone coming soon - and Liptikl!

2010-01-18T20:23:00.002Z

Tim and I both had a good break over Christmas; I think we both earned it after the long, hard push to releasing Mixtikl 2!

Now that we're refreshed, we've been busy working on an update to Mixtikl, which tidies-up various loose ends and generally makes it easier to get into! We're aiming to release this in a few weeks.

We've also been working on an iPhone version of Liptikl, which is fun and easy to use, so we hope to release that at some point after first releasing the Mixtikl update.

For those who are interested in the technicalities of such things things, most of the primary development for Mixtikl is done under Xcode on the Mac, targeting the iPhone version. Because Mixtikl is 95% cross-platform, I actually have the option to work under either Windows (with Visual Studio) or Mac OS (with Xcode). Despite Visual Studio being hugely more powerful than Xcode (with a far nicer editor model, debugger etc. etc....), I find myself working mainly in Xcode. Why? Simply because Mac OS is a great deal faster than Windows for running all my development scripts. Xcode is a lot less nice to use than Visual Studio, but overall I'm faster on the Mac because Mac OS mainly because shell scripting runs so much quicker...! Because I use the same editor on both platforms (vim ...) I can move easily between the two whenever I need to. I must say however, that if cygwin scripting were a lot faster under Windows, then I'd be back to Windows. :)

Android - NPAPI plugin - how to make a callback from the main thread

2010-01-18T11:53:00.005Z

If you happen to be writing a browser plug-in using NPAPI/JNI for Android's built-in browser, and are doing some processing in the native side in C/C++ in a separate Posix thread; and want to get a callback into your native code from the main browser thread; you want to use this NPAPI function...!

void NPN_PluginThreadAsyncCall(NPP instance,
void (*func)(void *),
void *userData);

You can find some documentation on this if you search your Android source code for the file called npapi.cpp.

Basically, you call the above function from your native thread to register a callback function; the call to NPN_PluginThreadAsyncCall returns immediately. At some future point in the very near future, the browser will call your supplied function from the main browser thread, supplying the userData that you provided when you registered your callback.

Incidentally, if your Plug-in method is passed a JavaScript object that you're going to need to do something with at a later point (e.g. if you want to issue a deferred callback, through use of NPN_PluginThreadAsyncCall), you need to remember to keep your JavaScript object alive until you're ready to use it, by calling:

NPObject *NPN_RetainObject(NPObject *npobj);

Once you've used the object, remember to release it with:

void NPN_ReleaseObject(NPObject *npobj);

Hopefully that'll be of use to some people!

Android - how to obfuscate your apps

2010-01-15T10:30:00.001Z

If you're wondering how to obfuscate your Android apps, you should look at http://proguard.sourceforge.net/ ...!

Android debugging with gdb?

2010-01-04T11:44:00.001Z

For those of you that have been struggling to find information on how to debug under Android with GDB (for example, if you've been writing JNI code for Android...), this looks like a useful link to follow!

http://pdk.android.com/online-pdk/guide/debugging_gdb.html

Pete

My first Mix Tikl!

2009-12-08T23:37:00.003Z

http://t1kl.me?2PJAAIAAAAAAAAdpAqAAABOSBwAAACgkCYAAAC5IDgAAAMaQaAAAAVEAAAAACoAAAAAAVAAAAAACoAAAAAAVAAAAAACpAAAAAAVIAAAAAAA==

Amazing stuff. :-)

Mixtikl 2 launch day - at last!

2009-12-08T08:38:00.000Z

So here we are, Mixtikl 2 launch day.

Product launch days are always a bit hard, there is always too much to do, and we're focused for now purely on completing the web side of things.

The good news of course is that the software is stable and we're pretty happy with what we've created.

As always, we're wondering what people will think of how we've changed and extended things. Of course, Mixtikl 2 looks quite a lot different to Mixtikl 1, some aspects of the UI have changed a lot and will take some getting used to for users of Mixtikl 1.

We've featured generative content very strongly, and added what we think are some exciting new features aimed at collaboration and content sharing through text audio vectors. And, of course, we're now running on iPod/iPhone; I should think that some people will be interested to compare and contrast the experience of using Mixtikl on iPhone/iPod, compared to Windows Mobile. :)

The biggest challenges for Mixtikl have been of our own making: a continued wish to have it run on as many platforms as possible; to have Mixtikl be usable on both touchable and non-touchable devices; to introduce extensive content sharing features which build on our long experience of "vector audio"; to introduce web browser plug-in variants.

Whatever we do, we know that some people will love Mixtikl 2, others will hate it - and the struggle to create compelling generative software continues!

Life certainly would be easier if we just supported one platform and just focused on one major feature; but then Mixtikl simply wouldn't be so interesting and kaleidoscopic! :)

Pete

Moving to Android NDK 1.6 from Android NDK 1.5 ...

2009-11-20T11:43:00.002Z

I've updated my Android configuration to NDK 1.6, and am using the latest STLPort download.

There were a few things that changed, mainly system paths, as some posters to my blog were kind enough to point-out in earlier posts.

Here are some notes on that process, from the point of view of a cygwin-based setup under Windows. The comments generally apply to Linux/Mac as well, however.

Getting STLPort

I performed the "git" command for STLPort from within the root of the Android NDK folder, in other words from within this folder:

C:\android-ndk-1.6_r1

The command to use is this:

git clone git://umbel.mooo.com/ndk-wrappers.git

This puts the STLPort code in a slightly different place to where it was before, such that the code appears under the ndk-wrappers folder...


ndk-wrappers\stlport

... which you'll need to account for when you update the paths!

There were a couple of other things that I found tricky to get right in this transition were as follows.

env.sh

When you try running env.sh, you must do it with "source" otherwise the environment isn't updated properly. In other words, type this:


source ./env.sh

Application.mk

If your project is called "fred", then you need to have the following folder:

C:\android-ndk-1.6_r1\apps\fred

This should contain just one item, which is the Application.mk file, with the following (example!) two lines in it:

APP_PROJECT_PATH := /cygdrive/c/DOCUME~1/me/MYDOCU~1/WORKSP~1/fred
APP_MODULES := fred

libstlport.a

Once you've rebuilt STLPort, you need to copy libstlport.a (which seemed to be called libstlport.5.1.a in the previous build system... again, watch out for that!) to a new folder, which you'll need to create in the following location:

C:\android-ndk-1.6_r1\out\apps\fred\libs

The jni folder

You need to have at least two files (your source .cc file, and your Android.mk file) in the jni folder under your project, which is here in my example:

C:\Documents and Settings\me\My Documents\workspace\fred\jni

Android.mk

In my example, the Android.mk file contains this data:


LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

STLPORT_BASE := /cygdrive/c/android-ndk-1.6_r1/ndk-wrappers/stlport


LOCAL_MODULE    := fred
LOCAL_CPP_EXTENSION := .cc
LOCAL_CFLAGS += -I$(STLPORT_BASE)/stlport \
-D__NEW__ \
-D__SGI_STL_INTERNAL_PAIR_H \
-DANDROID \
-DOS_ANDROID
LOCAL_SRC_FILES := fred.cc

#Static Libraries:
LOCAL_PREBUILT_LIBS :=  libs/libstlport.a
include $(BUILD_MULTI_PREBUILT)
LOCAL_STATIC_LIBRARIES := libs/libstlport

include $(BUILD_SHARED_LIBRARY)

Good luck!

That should be enough to get you up-and-running with NDK 1.6!

Mixtikl 2 - coming December 8th 2009

2009-11-04T12:18:00.002Z

The Mixtikl 2 release date has now been set at December 8th 2009.

Can't wait! :)

Mixtikl update

2009-10-08T07:54:00.000+01:00

After a long push, Mixtikl 2 is now feature complete! We're now focussed on tidying-up a few loose ends, meaning that there is a good chance we'll be able to release for Mac/Win/Windows Mobile at the end of the month. We'll also submit the iPhone/iPod version to the app store at that time; that'll arrive at such time as Apple approve it!

Amongst all the other stuff we've done for Mixtikl 2, we've created Mixtikl internet browser plug-ins for Mac and Windows, meaning that you'll be able to publish your Mixes and Partikl tracks on-line. Which is pretty cool! :)

How create a new JNI / STL based project for Android

2009-09-10T09:40:00.005+01:00

Now that I've been through the process of creating new JNI / STL-based projects for Android a few times, I thought I'd summarise the steps; as you can see, they are pretty complicated! The problem isn't down to STL; the problem is one of the basic complexity of setting up a JNI-based project (which is never easy to get started, but is fine once you're up and running!).

Note: the steps below assume you're using cygwin and Windows. You'd need to tweak them a little if you're using Mac or Linux.

1. Make sure Eclipse uses a sensible workspace folder

NOTE!! I modified my Eclipse preferences to put my files in
Documents and Settings/myname/My Documents/workspace
rather than the Eclipse default of
Documents and Settings/myname/workspace
which I find really difficult to track-down and/or backup!

2. Create a new Android Java project.

a) Create a package called com.mycompany.MyStl, with your activity class called AdaptorClass

Ensure the following code is in your ActivityClass source code...


    // A native method that is implemented by the
    // 'libMyStl' native library, which is packaged
    public native String  stringFromSTL();

    // Note: remember to put-in some test code that calls the above native method!!

    // this will load the 'libMyStl.so' library on application startup.
    static {
        System.loadLibrary("MyStl");
    }

b) you must add a "libs" folder to your project: and then add an "armeabi" sub-folder in this folder.

c) Build the project (and fix any compilation errors) - but don't run it yet!

3. Create the JNI / STL project

a) Create a folder in for your project, e.g.:


  C:\android-ndk-1.5_r1\apps\MyStl

b) Create a file in this folder called Application.mk, which contains the following:


APP_PROJECT_PATH := /cygdrive/c/DOCUME~1/MYNAME/MYDOCU~1/WORKSP~1/MyStl
APP_MODULES      := MyStl

NOTE!! The path is a path with no spaces (as otherwise the Android NDK make system gets confused...!), and was generated using cygwin's cygpath command. You must generate and use one that suits your user, using a command similar to the following...


  cygpath -dm /cygdrive/c/Documents\ and\ Settings/myname/My\ Documents/workspace

c) Make an empty folder in this folder called "project".

4. Create the JNI / STL sources, and integrate with your Android project:

a) Create a folder for your C++ source code, e.g.:


  C:\android-ndk-1.5_r1\sources\MyStl

b) Create a file in this folder called Android.mk ...


LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

STLPORT_BASE := /cygdrive/c/android-ndk-1.5_r1/stlport

LOCAL_MODULE    := MyStl
LOCAL_CPP_EXTENSION := .cc
LOCAL_CFLAGS += -I$(STLPORT_BASE)/stlport \
     -D__NEW__ \
     -D__SGI_STL_INTERNAL_PAIR_H \
     -DANDROID \
     -DOS_ANDROID
LOCAL_SRC_FILES := MyStl.cc

LOCAL_STATIC_LIBRARIES := /../../../../../stlport/build/lib/obj/gcc/ar/libstlport.5.1

include $(BUILD_SHARED_LIBRARY)

c) Create a file in this folder called MyStl.cc ... note the instructions that follow in d) on how to re-generate your own method prototypes...!


/*
 * Class:     com_mycompany_MySTL_AdaptorClass
 * Method:    stringFromSTL
 * Signature: ()Ljava/lang/String;
 */

// Prototype - make sure it uses C-style linkage!
extern "C"
{
JNIEXPORT jstring JNICALL Java_com_mycompany_MyStl_AdaptorClass_stringFromSTL
  (JNIEnv *, jobject);
};

// Implementation
JNIEXPORT jstring JNICALL Java_com_mycompany_MyStl_AdaptorClass_stringFromSTL
  (JNIEnv *env, jobject)
{
    std::vector lVector;
    lVector.push_back("Hello from STL!");

    std::string simple_string = lVector[0];

    return env->NewStringUTF(simple_string.c_str());
}

d) Modify the MyStl.cc file...

The prototype and implementation shown are just examples. You MUST construct your own by doing this:


  cd "/cygdrive/c/Documents and Settings/myname/My Documents/workspace/MySTL/bin"
  javah -jni com.mycompany.MySTL.AdaptorClass_MySTL

Copy-out the generated prototype from the generated .h file that javah creates for your, and replace what I've shown above with the correct generated function prototype and function name.

e) Then, build the library:


  cd $NDK_HOME
  ./env.sh
  make APP=MySTL

f) The first time you've built the library, you must drag the newly constructed .so file from Windows Explorer to your armeabi folder in the project. You must then right-click on the armeabi folder in Eclipse, and select "Refresh". The library is then bundled-in to your project bundle when you next build your Android project.

5. You can now build and run your Android project!

6. If you ever modify your C++ source...

Simply re-build the library (step 4e) and then re-build and run your Android project (step 5).

7. If you need to add a new method...

You'll need to re-use javah to generate the correct prototype function signature to use. Add this to your STL project, re-make, re-build and you're done!

Android Lists - using the ListView component

2009-09-08T08:50:00.005+01:00

Whenever I write GUI code for a platform that is new to me, I always find myself stumped early-on figuring-out how to get simple list gadgets working. After all, most simple applications are based around buttons and lists of data. Buttons are always easy to use, but lists are always a pain.

Every platform seems to use a completely unique approach to creating lists; Android's approach is no exception in terms of how difficult it is to figure-out how to use its LiewView components. My opinion here is that the problem is down to the trend for using Model-View-Controller architectures, which actually seem to get in the way of deploying basic components like a list.

Anyways: you'll find a really useful guide to creating multi-column lists on Android here.

The steps you need to follow:
- create a new res/layout/mylayout.xml file, with the correct magic format and properties that you have to copy from what you can glean through internet searches
- use some magic code based around Adapter classes
- call the setAdapter method on your list

For those who are interested, I think the Windows API model is by *far* the easiest (using owner-draw lists); a piece of cake to use. The Apple APIs (carbon/cocoa) are hideous. The Android APIs are probably the worst.

I really wish that people who wrote APIs would concentrate on making the basic stuff easy, with lots of example code. Well done Microsoft for getting this stuff right in the first place. :)

The good news about Java development these days is support for Java Generics; I'm very happy to find that Android supports them!

PC-Lint and Visual Lint

2009-08-28T09:08:00.004+01:00

Writing software is always a challenge. When you are responsible for every line of code across multiple products and platforms, it is critical to write solid code that is as good as possible (bugs are very expensive to deal with!) :)

The free lint tools (mainly cppcheck) are OK but seem to miss lots of things compared to the professional tools, and I've been meaning to get a proper static code analysis tool for a long time now...

So: I finally took the plunge a couple of days ago, and bought a license for PC-Lint. I'd been meaning to do this for a long time, having slowly been improving my tool chain. The longer I do programming, the more I realise that it is critical to have as good a set of tools as possible, from operating system, editor, IDE, shell/scripting tools etc. ...!

Having installed PC-Lint and started to use it... I soon realise how difficult it was to use, albeit very powerful. I have never seen a tool with so many command line options, and stepping from command line output to change the code (and back again) is very difficult. So, imagine my complete relief to stumble upon Visual Lint!

For those who don't know, Visual Lint it is a GUI front-end for PC-Lint that makes it a piece of cake to use; it integrates beautifully with Visual Studio.

One thing I like about the evaluation version of Visual Lint is that it makes it very easy for you to see which features you need, so you can end-up choosing the product variant that best meets your needs. I'm guessing I'll get the Professional Edition, and am still making my mind up; but I'm certain to get a copy in a few days.

It is a shame that PC-Lint doesn't have an evaluation model. The software is certainly expensive; which is understandable, but a shame as it prevents more people improving the quality of their code.

If only there were an integrated Static Code Analysis system for XCode on Mac. It seems that the availability of PC-Lint and Visual Lint gives a major advantage to Visual Studio on Windows for cross-platform coding, as much as I love the general speed of working on the Mac. I guess I'll continue to work on the Mac, but spend a little more time now on Windows analysing the cross-platform code I've written using Visual Lint.

auto_ptr with arrays - and a solution

2009-08-26T14:30:00.004+01:00

It is pretty irritating that auto_ptr (a feature of C++, for those who don't know!) doesn't work with array variables.

In other words, it is not safe to do this:


int *pArray = new int[10];
auto_ptr autodel(pArray);

It is pretty easy however to create your own alternative to auto_ptr, that works with array pointers...

template <class T> class auto_ptr_array
{
public:
    auto_ptr_array(T *p) :
        mp(p)
    {
    }

    ~auto_ptr_array()
    {
        delete[] mp;
    }

    void reset(T *p)
    {
        delete []mp;
        mp = p;
    }

    T *get()
    {
        return mp;
    }

    T* release()
    {
        T* lpRet = mp;
        mp = NULL;
        return lpRet;
    }

private:
    T *mp;
};

Example usage...

int main (int argc, char *argv[])
{
    // Use it one of two ways...
    auto_ptr_array autodel(new int[20]);
    int *pval = autodel.get();

    int *pval2 = new int[20];
    auto_ptr_array autodel2(pval2);

    printf ("Done!\n");

    return 0;
}

Android NDK - getting STLPort up and running

2009-08-21T11:07:00.003+01:00

If you want to get STLPort running with the Android NDK, you'll have a bit of work to do; especially if using Cygwin under Windows.

First, visit http://umbel.mooo.com/ and get the STLPort version from John Ripley (great job, John!). If you're a cygwin user, you'll first need to remember to install the git package.

Next thing is to copy the files to a place that works for you. On my system, I copied the files into my c:\android-ndk-1.5_r1 folder, and then moved the two hello-stl folders to somewhere that seemed consistent with the other NDK files:


C:\android-ndk-1.5_r1\apps\hello-stl
C:\android-ndk-1.5_r1\sources\samples\hello-stl

I then had to change a few files before I could build the STLPort...

setup.sh

Change the top few lines to look like this:

#!/bin/bash
if uname | grep -qi linux; then
export NDK_HOST=linux-x86
elif uname | grep -qi CYGWIN; then
export NDK_HOST=windows
else
export NDK_HOST=darwin-x86
fi

Change the third line up from the bottom to look like this:


    ln -sf "$NDK_DIR/build/prebuilt/${NDK_HOST}/arm-eabi-4.2.1/bin/arm-eabi-$tool" arm-linux-$tool

stlport/build/lib/android.mak

Change the TOOLCHAIN_PREFIX line to look like this:


TOOLCHAIN_PREFIX := $(NDK_DIR)/build/prebuilt/$(NDK_HOST)/arm-eabi-4.2.1/bin/arm-eabi-

sources/samples/hello-stl/Android.mk

Change the STLPORT_BASE line to be this:


STLPORT_BASE := /cygdrive/c/android-ndk-1.5_r1/stlport

Change this:


LOCAL_LDLIBS += -L$(STLPORT_BASE)/build/lib/obj/gcc/so \
     -lstlport

to this:


LOCAL_STATIC_LIBRARIES := libstlport.5.1

Building STLPort

Now that the files are merged-in, you're ready to build STLPort!

Run the following in the cygwin shell... it will build the STLPort static library for you! You'll only need to do this once.


export NDK_DIR=/cygdrive/c/android-ndk-1.5-r1
cd $NDK_DIR
./env.sh
./setup.sh

Now, do this to copy the file to your project:


cp -p \
/cygdrive/c/android-ndk-1.5_r1\stlport\build\lib\obj\gcc\ar\libstlport.5.1.a \
/cygdrive/c/android-ndk-1.5_r1\out\apps\hello-stl\android-1.5-arm

Building your project's shared library

You can now go back to the cygwin shell, and do this:


cd /cygdrive/c/android-ndk-1.5_r1
make APP=hello-stl

... which will build your shared library file:


C:\android-ndk-1.5_r1\apps\hello-stl\project\libs\armeabi\libhello-stl.so

Note that this will have the static STLPort library linked-in.

Building the hello-stl project

From Eclipse, use the New Project Wizard to create a new Android project for each sample, using the "Import from Existing Source" option and import the source from c:\android-ndk-1.5_r1\apps\hello-stl\project

You can now build and run your project. The string displayed comes from the shared library, using std::string ...!

Android JNI/NDK - notes on getting started

2009-08-20T15:14:00.004+01:00

There are a lot of steps required to get your Android development environment set-up, to a state where you can create your first Android "Hello World" app with JNI/NDK.

This is definitely not for the faint-hearted! It is complicated enough that I thought it'd be useful to run through in a blog entry.

So, here is a summary of what to do, in order to get started with using the Android software under both Mac and Windows.

1. Get the latest Sun Java SE Development Kit

Windows: You can get this from here:
http://java.sun.com/javase/downloads/index.jsp

Mac: You should already be up-to-date, assuming you have XCode installed

2. Get Eclipse

I downloaded the latest version of the "Eclipse IDE for Java Developers" from here:
http://www.eclipse.org/downloads/

Windows: Unzip, and then put a shortcut to eclipse.exe somewhere where you can find it!

Mac: Unstuff, and put Eclipse to your Applications folder.

3. Get the base Android SDK (1.5 or later!)

As we're doing to be doing NDK development, make sure you get Android 1.5 or later from here:

http://developer.android.com/sdk/index.html

Make sure you follow the appropriate instructions for installing/upgrading (depending on what current system you might already have)

Windows: When you unzip the file, make sure that it goes under the c:\ root folder... i.e. so it looks like this (for example):


c:\android-sdk-windows-1.5_r3

Mac: Put this under your home folder, so it looks like this (for example):


~/android-sdk-windows-1.5_r3

4. Windows: Get Cygwin

The cygwin toolchain is required for NDK development if you're using Windows.

So, make sure you have cygwin installed! You can get this from here:
http://www.cygwin.org
... note that you'll need the C/C++ developer tool packages.

Mac: users already have a suitable toolchain built-in through XCode.

5. Get the Android NDK

Get the latest Android NDK, from the "Native Development Tools" in the sidebar on in the sidebar on this page:
http://developer.android.com/sdk/index.html

Windows: When you unzip the files, make sure you copy them such that they are under the C:\ root folder, i.e. so that they look like this:


c:\android-ndk-1.5_r1

... if you leave them under e.g. My Documents, then the system will fail to build your source code due to spaces in the file paths etc.

Mac: Put this under your home folder, so it looks like this (for example):


~/android-ndk-1.5_r1

Make sure you follow the instructions that are in DOCS/INSTALL.TXT ...!!!

6. Windows: My Computer - path

Remember to follow instructions on setting your path variable!

Basically, append something like the following (which you'll have to change if you ever come to upgrade)


;c:\android-sdk-windows-1.5_r3;c:\android-ndk-1.5_r1

7. Create your first AVD

You can create your first AVD to be called something like my_android1.5 ... make sure you base it on the Android 1.5 SDK!

You can do this from Eclipse; and more information is available here:
http://developer.android.com/guide/developing/tools/avd.html

Test that you set-up the NDK properly

The following steps will create the following file:


out/apps/hello-jni/android-1.5-arm/libhello-jni.so

Windows:


start cygwin
cd /cygdrive/c/android-ndk-1.5_r1
make APP=hello-jni

Mac:


Run Terminal
cd ~/android-ndk-1.5_r1
make APP=hello-jni

8. Create your first basic Android Project

Now follow the instructions here:

http://developer.android.com/guide/developing/eclipse-adt.html#CreatingAProject

... and if you're lucky, it will build and run, and you can then get on with the JNI/NDK side of things!

9. Create and build/run your first NDK project

You can now create your first NDK project using JNI, and build/run it, following the steps you'll find here:

http://developer.android.com/sdk/ndk/1.5_r1/index.html#samples

Easy!

Using find with xargs in Linux/Mac/Unix/Cygwin with spaces in the file paths

2009-08-20T09:01:00.005+01:00

I'm always having to perform searches through lots of files when on Mac/Linux/Cygwin

This is the style of command I'd normally use from the bash shell (Terminal) on Mac/Linux/Unix/Cygwin ...


find . -name "*.cpp" | xargs -- grep -i "find me" > q.q

This looks from the current folder (and all files below), searching for all files with the cpp file extension. For every file, it runs grep on it (case insensitively); putting the results of all searches in the file called q.q (which you can then edit using e.g. vim).

However, this simply doesn't work when the file or folder being searched has a space character in it. Which is annoyingly common in a files these days...

A short while back I discovered the solution to this "spaces in names/folders" problem, and I figured it'd be useful to write it up to save you the trouble...


find . -name "*.cpp" -print0 | xargs -0 -- grep -i "find me" > q.q

Note how we've added both -print0 and -0, which together magically solve the problem.

Incidentally, the -- in the argument list for xargs, is shell magic that tells xargs to ignore any options it might see after that point (e.g. the -i in the example), and simply pass them directly on to the command (grep in our example).

Android JNI NDK - and STL support?

2009-08-18T15:13:00.004+01:00

There is an interesting post that you can find here, which indicates that it is possible to get STL support working in C++ code that you might want to port to the Android JNI / NDK, using STLPort. Cool!

This is really interesting; I think this was the biggest issue that was blocking a port of Mixtikl to Android devices (I think I can see a way around most other issues). So, I now need to clear some time in my schedule to investigate in more detail! :)

The STLPort info page has more details, and the license looks promising; all-in-all, this is very exciting!

Mixtikl ... V2!

2009-08-14T10:55:00.003+01:00

We've put so much effort in to Mixtikl V1.5 ... and reworked so many things... that it seems to have evolved into Mixtikl V2. Right under our very eyes!

So, the release of the new version of Mixtikl is going to be quite a lot later than we planned early this year, but that is all part of the fun of designing and coding on the fly. You never know exactly where things will take you! :)

Right now we're focused on finishing off all the UI rework, and then fixing-up the bugs that the rework has (inevitably) introduced. I hope it is worth the wait!

GTK - how to enumerate widgets

2009-08-14T10:40:00.005+01:00

I had fun recently trying to figure-out the code that would allow me to enumerate through all available GTK Widgets, a little bit like the Windows EnumWindows function. This took me a while to figure out... mainly because of the terrible state of the GTK documentation. :)

Anyways, here is the bare bones of the solution; as you can see, it is actually really easy.

A couple of things to note:

- a GtkWindow can be treated as a GtkWidget...!
- if a GtkWindow has child widgets, then it must be of type GTK_CONTAINER

static void widgetEnumerate (int nDepth, GtkWidget *pGtkWidget)
{
  printf ("%d: Got GtkWidget=%x\n", nDepth, pGtkWidget);

  // If the GtkWidget in question is a also a container,
  // then we can enumerate through its children!
  if (GTK_IS_CONTAINER(pGtkWidget)
  {
    GtkContainer *pGtkContainer = GTK_CONTAINER(pGtkWidget);
    GList *pGtkWindowList = gtk_container_get_children(pGtkContainer);

    GList *pNode;
    for (pNode = pGtkWindowList; pNode != NULL; pNode = pNode->next)
    {
      GtkWidget *pGtkWidget = GTK_WIDGET(pNode->data);
      widgetEnumerate(nDepth+1, pGtkWidget);
    }
  }
}

void enumerateGtkWidgets(void)
{
  GList *pGtkWindowList = gtk_window_list_toplevels();
  GList *pNode;
  for (pNode = pGtkWindowList; pNode != NULL; pNode = pNode->next)
  {
    GtkWindow *pGtkWindow = GTK_WINDOW(pNode->pData);
    widgetEnumerate(1, GTK_WIDGET(pGtkWindow));
  }
}

iPhone - problems updating the Ad-Hoc Provisioning Profile

2009-08-10T20:58:00.003+01:00

If you get the following error in XCode after having updated your Ad-Hoc provisioning profile...

CodeSign error: a valid provisioning profile is required

... then don't panic - help is at hand - here! :)

Porting from iPhone to Windows Mobile?

2009-08-07T07:37:00.002+01:00

I found this article a couple of days back on the MSDN site - Porting the Amplitude Application from the iPhone to a Windows Mobile Device – a Case Study.

The article talks us through porting an iPhone app to Windows Mobile. This is a good idea of course - but the article decided to use C# as the language in which to completely rewrite the app for Windows mobile! This got me wondering why anybody would want to use anything other than C++ for writing applications (as much as I really like C# as a language), excepting of course those platforms where you have no choice.

The big thing about the iPhone - for me! - is that one of Apple's several great decisions was to adopt Cocoa as their platform. This means that apps are written in Objective-C ... and, if you want, you can use Objective-C++ as well. This means that all of your app code can be written in platform-neutral C++ ... with only the UI-specific code [which is based around the Cocoa Touch framework] being in Objective-C. This way, all of your non-UI code should be easy to port to any other platform that supports C++. Note: this approach assumes that you isolate and minimise your use of low-level Cocoa elements such as NSString as much as possible! This is easy to do if you use things like your own String adaptor classes, which wrap-up this platform specific stuff in a platform-neutral manner.

The nice thing about Windows Mobile is that all your code can be written in C++. So... why would you want to use a completely different language - C# in this case - as your language? Why not instead keep as much of your code as cross-platform as possible, and use C++, which is natively supported for Windows Mobile? Then you have to do much less work to port and maintain your application.

Oh well.

While doing some Android consultancy work recently, it was strange to reflect that all of the code had to be written in Java. I've got nothing against Java per se, it is just the annoying thought that all the code I wrote could not get re-used on other platforms. I can but hope that Android's NDK eventually matures to the point where we can write write most of our graphics code in C++.

As for Symbian - I won't look at that again until they base their development on a standard version of C++ with STL template support and Posix threads ... :)

Building installs

2009-07-27T13:08:00.004+01:00

I thought I'd share some of what I've learned in building installs for Windows, Mac, Windows Mobile and iPhone.

Windows: Inno Setup

This is free from http://www.jrsoftware.org/isinfo.php

Inno Setup is a marvellous tool, making it really easy to auto-build "standard looking" setup .exe files using scripts. I use cygwin bash shell to grab my latest files, build the setup .exe files and zip them up - dead easy. Spread the word!

Mac: PackageBuilder - free from Apple

Some apps are simple enough just to distribute as zipped-up Disk Images, from which the user can drag the embedded .app file to their Applications folder. However, applications that are more complex (such as Noatikl, which includes various components including Audio Unit and VSTi variants) are tougher to build installs for.

PackageBuilder is built-in to XCode, and builds good looking "Mac Standard" installs, but it is a pain to drive it automatically. I use one bash shell script to copy all the bits I need under a build folder, then I run the PackageBuilder manually using pre-prepared configuration file (can't figure-out how to run it from the command line!) (making sure I save the .pkg files into the right folder... that'll catch you out if you're not careful!) and then a second script to build the pkg file into a .dmg file, then zip it up.

Both these tools allow you to embed licenses that the user has to agree to in order to complete the install, which was important to us; in both cases, those text files can come from .rtf files so they're nicely formated!

PackageBuilder with XCode 3

If you're using XCode 3.0, and have tried to build an installer package and encountered all sorts of annoying problems that prevent it from working; don't despair.

Instead, do what I did, and copy/use intead the PackageBuilder.app from from an XCode 2.x distribution; this works, and means you can totally avoid the buggy version in XCode 3.0 ... :)

This fixes the problem where when your application gets installed, it appears in /Library/Applications rather than ~/Applications ... this is such a huge bug, I'm amazed it actually got into XCode 3 ... oh well!

Here is an outline bash script that you could use. Note the use of sudo to get around some file permission problems; basically, if the files that you work with don't have the appropriate permissions, they won't get installed properly on the target Mac.


sudo /Developer/Tools/packagemaker \
-build \
-v \
-p myprod/install/macosx/myprod_mac.pkg \
-proj imyprod/liptikl/install/macosx/myprod_mac.pmproj \
-f ./myprod_install_root \
-r ./myprod_install_root \
-i myprod/install/macosx/Info.plist \
-d myprod/install/macosx/Description.plist

The .pmproj file is prepared by you, prior to repeated running of this script, by the PackageMaker GUI tool that is in /Developer/Applications/Utilities ...

Oh, and under myprod_install_root, you first have to create separate Applications, Library etc. folders containing copies of my App, Libraries etc. that you want installed, in a folder structure mirroring how they should get installed on the target Mac.

Windows Mobile

The solution here is to build cabinet files using cabwiz (which comes with of Visual Studio). You'll need to construct all sorts of custom code in a custom setup.dll file, that does stuff such as displaying license text that the user must agree to at install time. You should also write a relatively simple launcher .exe for Windows Desktop, that allows the user to install the file directly from their Windows desktop, through the services of ActiveSync (this is a lot easier for your users, than expecting them to copy a .cab file across to their Mobile device's StartUp menu...!)

iPhone

For distribution to your ad-hoc testers, remember that you need to update the version number in version.plist every time you supply an updated build; otherwise, it'll fail to install/update on the target iPhone/iPod! Remember also that if you zip-up a .app file, it won't install properly after being unzipped on the target computer. Instead, first put the .app file in a disk image, and then compress the disk image to a zip file that you can then mail to your ad-hoc testers.

File comparison and diff tools - Mac and Windows

2009-07-13T20:49:00.003+01:00

File comparison tools are pretty critical to what I do. Most of the time, I rely on command-line diff (under Mac Terminal, or Windows Cygwin shell). But there are times when only a graphical comparison tool will do; such as recently, when I changed a vast amount of code, only to have introduced a new bug that was proving very difficult to track down. In these cases, you need to compare old and new code, one file (or folder) at a time, painstakingly looking at each change until you figure-out what went wrong.

A friend introduced me to Beyond Compare for Windows - which I liked enough to buy a license for. Great software!

However, now that I've changed my focus to do as much of my core development as possible on the Mac (avoiding Parallels where possible as it really is very slow compared to native Mac tools), I've been hunting around for a good graphical diff for Mac. And I have now found that tool - it is called Changes. Give it a try - tremendously good value, I'm very pleased to have bought a license!

Incidentally, I'm quite amazed at how much faster the shell on Mac works compared to Cygwin on Windows. I use a lot of scripting as part of my software development setup; one of the reasons to moving over to doing as much work as possible on the Mac is that the faster scripting makes a big difference to my productivity. I wonder why Cygwin is so much slower than the Mac Terminal window?

More on Android Audio

2009-07-09T07:54:00.004+01:00

Many thanks to Jay, who was kind enough to post a comment on my previous post, saying that there is an API we can use for programmatic delivery of audio streams in Android, which you can find documented at http://developer.android.com/reference/android/media/AudioTrack.html.

Now that I know where to look :), I have found that there is also a similar API you can use to capture incoming audio on Android to memory, which is documented at http://developer.android.com/reference/android/media/AudioRecord.html.

So, that means that Intermorphic could at some point create a Noatikl/Partikl player library for Android if we wanted to, using the Android NDK (I wouldn't be surprised if this link breaks at some point...).

However, that would first require the NDK to fill-in some critical (!) gaps:
- no support for C++ exceptions (this is a show stopper for a lot of code...)
- no support for STL (this is also a show stopper...)

If any reader happens to know who to prod at Android, please get them on the case wrt the holes in their C++ support!

I suspect that the full Mixtikl user interface would be a bridge too far :) though it'd be interesting to experiment around what is possible (not that I ever have any spare time!).

Android Audio?

2009-07-06T09:51:00.003+01:00

I've been investigating Android recenly, and have downloaded the SDK and had a play with it.

And in summary, I'm quite staggered at how poor the support is for audio in the Android SDK.

You can find-out more here.

The fundamental problem is that there is no way for a program to generate its own stream of audio. All audio resources must be from a URI of some sort, or from data bundled-in to the application, or from a file in the file system.

Of course, some bright spark out there might tell me that you can easily create your own "in-app" audio server with Java that you can access through a URI from that self-same application, and that can generate an audio stream on demand; I'd love to hear if this is the case!

On another note, the audio data capture system only allows you to send data to a file; there is no way for your application to get access to the audio as it arrives. So whichever way you look at it, there is no way to create audio FX boxes for Android.

This all reminds me very much of the JSR-135 multimedia APIs for Java, which were completely useless from the perspective of a low-level audio programmer.

I'm pleased to report however that if you want to create interesting audio apps for Mobile, then your needs are well served both by the iPhone/iPod SDK, and the Windows Mobile SDK. Shame about Android though!

More Mixtikl progress

2009-07-01T12:19:00.002+01:00

Well, that always seems to happen. We've decided to put another round of polish on Mixtikl 1.5 for iPhone/iPod, and figure that we'll spend another 4 weeks or so on it, if our estimates are right...!

Holiday season is coming up too which is bound to affect things! :)

Android NDK?

2009-06-29T07:53:00.000+01:00

Interesting to read about the Android NDK, which is a "native" SDK for Android.

It is a shame that currently, the implementation seems somewhat flawed IMO:
- your app is written in Java and runs through the VM; you can call-out to native code libraries through JNI (which has hardly efficient!)
- no support for C++ exceptions (this is a show stopper for a lot of code...)
- no support for STL (this is also a show stopper...)

Reading the forums, the latter 2 are likely to appear some time; goodness only knows if the first restriction will ever disappear...

Is the expanding mobile environment a good thing?

2009-06-26T08:05:00.004+01:00

Thanks to a response from "Mobile" to my blog from a couple of days back, pointing out that the whole underlying market for Smartphones will continue to expand and diversify.

It seems pretty clear that most product churn seems to be of little benefit to the consumer. For example: I was pretty happy with Windows 95, and accept that Windows XP is better; but cannot see any point at all in Windows Vista. :) Companies have a need to keep re-inventing successful products, as milking a cash-cow is hugely easier than creating a new one.

For me, phones have been capable enough for most things since Windows Mobile 2002! That allowed full-featured, multi-threaded applications to be written and deployed in C++; with support out-of-the-box for full-duplex audio. With easy exchange of data through the PC using Active Sync. Devices were cheap, too.

All that was missing back then was a realisation by the market that such a device was a genuinely capable, multi-purpose mobile computer.

Since then, I can't see that Windows Mobile has moved on much (although the development tools are now better!); but then it really didn't need to change much, it has been a great platform for a long time. Symbian seems to have stood still for many years, and is stuck with a terrible variant of C++ and an awful tool chain. iPhone has opened a lot of peoples eyes, full credit to Apple for putting their toes in the water and for extending the iPod concept to include iPhone, and for pointing-out a direction for touchable UIs.

Anyways: to the heart of the problem. Now that more platforms offer similar capabilities - though iPhone has big sandboxing and connectivity issues, Android only allows Java apps, Symbian is a pig to code for and (IIRC) only allows applications to support single-duplex audio - that has served mainly to split-up the market. This gives more choice for the consumer in terms of hardware, but ironically makes it more difficult to get all the software you want on your chosen phone. Should you get a Windows Mobile device for application A, or iPhone for application B, or Symbian for application C? What if you want to change platform? Tough: you probably can't bring all your favourite apps with you. Now this might be good for the hardware developer (locking people in to their platforms), but in my opinion this is bad for the consumer.

The applications are what really define the device. You want Halo? You get an XBox. You want Zelda? You get a Wii. If you want Logic, you use a Mac. If you want Microsoft Office, you get a Windows box. Luckily now if you like Open Office, Firefox or other cross-platform tools, you have the option of running on all three main desktop platforms.

When it comes to smaller apps for mobile devices, the sort which are written by smaller developers and which really are what make a phone do what a user wants, and which are a far simpler proposition that the big apps I've just mentioned, you might think that it should surely be possible to write once, and deploy on all the platforms without too much effort? Actually no: it is unbelievably hard work, as you'll have seen from other posts on my blog.

The biggest challenge for mobile software developers, is one of writing an app such that it can reach as much of the market as possible. I can't see many ways to make this easy (apart from using a framework like the one we've painstakingly developed at Intermorphic!); this will lead to each phone platform being a separate island. I can but hope that Antix will succeeed and open up this whole market... which would also allow apps to be written once in C++, and run with binary portability on any device, including TVs, which had the application engine installed.

Sharing data between Mixtikl Windows and Mixtikl iPhone/iPod

2009-06-25T08:29:00.006+01:00

While waiting for the skins and Tiklpaks for Mixtikl 1.5 to pull-together, I've been continuing to fill-out the outer edges of Mixtikl. I spent the past week adding-in code that allows Mixtikl on Windows to share data with Mixtikl on iPhone/iPod; this was a lot harder than I wanted, as it involved both bonjour code and the creation of a mini HTTP server, which are things you get "out of the box" with XCode for Mac/iPhone, and which are hard to implement on Windows (to say the least!). Still, the code to do the file sharing all now seems to be working and I'll spend a day or 2 more on testing/tweaking it.

I remain amazed that the iPhone SDK makes it so difficult to share data with the desktop. On Windows Mobile, you can get data on and off via your PC using Active Sync and Windows Explorer; albeit, there is no simple way to get data on/off your Mac (if you have one!) short of installing Windows on your Mac through a VM or Boot Camp. On the iPhone/iPod, your app sits there in its own island, unable to communicate even with a Mac without a large amount of code being written for both Mac and iPhone. And if you want your iPhone/iPod app to communicate with a Windows box, well you're in a world of hurt from a coding perspective.

The good news for us is that now we've done the hard work, I think we'll be able to quite easily roll-out useful utilities within Mixtikl, that will allow quite a lot useful stuff to be done on iPhone/iPod/Windows Mobile - and shared/worked-on on the PC/Mac, as best suits the needs of the user...

Windows Mobile, iPhone, Android, Palm - a look around

2009-06-18T07:55:00.005+01:00

It is an interesing time of flux in the mobile software development market. The new version of iPhone OS released, a new version of Windows Mobile in the offing, Android phones have trickled onto the market and the Palm Pre arriving.

Intermorphic are in a pretty good position during this time of change.

The approach we've taken is to try and embrace all the key platforms - provided they support C++, Posix threads and STL. This lowest common denominator allows us develop complex software quite cost effectively. Of course, this required us to engineer our products from the beginnning to be able to reuse 95+% of our UI code, and 99+% of all other code, across all platforms we support; which is a challenge but one that was well worth the effort. That allows us to create standalone Mixtikl variants for Windows Mobile, iPhone, and Mac/Windows desktops. And even plug-in VSTi/AU variants for Mac/Win desktops!

This baseline requirement on C++ means that for now, Android and Palm webOS aren't viable target platforms for Mixtikl. The reason? Android only supports Java applications, and Palm Pre supports only JavaScript/CSS applications. However, the C++ approach does mean that a Symbian Series 60 variant of Mixtikl is possible in the future, if the Symbian SDKs ever become cost-effective to use (I remember various past problems when I last looked at Symbian, including their use of non-standard C++, no thread support, no support for STL...). The Antix platform also looks very promising, I hope it gets mass distribution so we can run on it!

It is interesting to consider how the Android and Palm platforms might succeed in terms of a 3rd party software market. From my perspective as a creator of applications for mobile, I can't see how it could be cost effective for me to invest several months (or years!) in creating a complex app for either Android or Palm, where I could spend just a little more time creating a complex app that would run on all of Windows Mobile, iPhone/iPod, Windows desktop, Mac desktop, and future platforms as yet unknown. The economies of scale seem pretty clear to me. :) I can see small games and utilities being created for the two platforms, but would be surprised to see large-scale commercial apps coming about for either of them.

Pete

Mixtikl 1.5 gets closer...

2009-06-12T07:40:00.003+01:00

Another 2 weeks on, and another 2 (or 3!) weeks of coding to go.

I've put a lot of effort over the past couple of weeks into further polishing Mixtikl on iPod/iPhone, and have also spent time improving the behaviour of Mixtikl on Windows Mobile (which has not been forgotten amongst all the iPhone work!).

There is still quite a bit of work to do on tweaking the skins for all the different Mixtikl platforms, and we've yet to finalise the Tiklpaks for release; we'll just have to see how we get on and release when we're ready!

Mixtikl iPhone release soon?

2009-05-31T15:30:00.003+01:00

It sometimes feels like I've been working on Mixtikl for iPhone for my entire life. :)

Anyways, we've made a great deal of progress over the past months, and are now aiming to submit the app to the App Store in around 4 weeks. Knowing the way things go, we'll no doubt slip by a few weeks, but it is good to have a date to target.

As for how long it'll take to get the app actually listed on the App Store; well, we'll just have to see what happens!

We'll also be rolling-out Mixtikl 1.5 to all the other platforms at the same time. Much to do! :)

Parallels 4

2009-05-25T14:49:00.007+01:00

Last week, I help my brother configure his new Mac Book Pro. On this, we installed Parallels, so he can use Windows XP easily without rebooting from Mac; and sometimes when booted directly into Windows (mainly, for using legacy Windows Audio tools where he wanted minimum audio latency). The whole idea behind this is to help him transition to doing more work on Mac and less under Windows...

I was a bit worried about installing Parallels, having previously had real problems with it; but his installation went fine, and all seems to be working well. Actually, the performance is pretty impressive!

Things went wrong for me a while back when I had Parallels 2; using this, my Windows partition got corrupted pretty early on, so I gave up and moved to a BootCamp solution. I got the Parallels 3 upgrade when it came out, so that I could try to use my Boot Camp partition with Parallels; but this also corrupted Windows for some reason, leading to yet another re-installation and dumping of Parallels. Well, as my brothers installation of Parallels 4 had gone well, I decided to try yet again..!

I bought the upgrade from Parallels 3 to Parallels 4, and converted the BootCamp on my wife's Mac Book to use Parallels (figuring it best to try on her Mac, rather than my main development Mac!). This went well; so I took the plunge and converted my Boot Camp on my Mac Book Pro using a new (non-upgrade) Parallels 4; this also went well. Phew! :)

However... I then found that I'd installed Parallels for Boot Camp slightly wrong for my wife's machine, and had to track-down instructions on how to enable parallels for her when logged on as her (not just when logged-on as me!). The solution was a pain, and required me to change her account to be an admin account (something that is not documented in the instructions I followed...); but at least it all works now and she can do most of her work now in Mac OS!

You might wonder why I went through all this hassle. The primary reasons are that Mac OS is a lot faster to start-up, and the battery lasts longer in MacOS. I have to do a lot of development work in Mac OS and Windows; and it is a pain to have to reboot between the two; so if I can use Mac OS has my main base, and use Windows whenever I need to, then that saves me a lot of time week-by-week. In the case of my wife, she needs to use Windows for only one thing, which is some Internet Explorer magic to do access her office network. We have found that Open Office 3.1 now lets her open and edit all of her work-related documents, without the need for Microsoft Windows; and she can work the same way in both MacOS and Windows.

It seems that in the main, the tools that most people use most often are the web browser and office tools. We use Firefox for both Windows and Mac, and Open Office for both Windows and Mac; so the operating system is less relevant. This brings me back to secondary issues of speed of start-up and longer battery life; where the Mac wins.

I was also pretty impressed to find that even when booted into Mac OS, running Windows XP in the Parallels VM, I can use Visual Studio 2007 running Mixtikl in a Windows Mobile emulator, debugging real-time audio code without any audio break-up. That is partly because my Mac Book Pro is pretty fast, and also because Parallels 4 really does seem to offer great performance. I wonder when I'll next feel the need to boot-up via Boot Camp?

One more reason for using Windows XP under the Parallels VM, is that just last week I discovered the wonderful Spaces mode in Mac OS, which gives me a dead-easy to use Virtual Desktop. This works brilliantly for me, and has already transformed my development process. There is no build-in virtual windowing mode that I can see in Windows XP, which has long frustrated me... anyways, Spaces also works very well with an external monitor, and/or when using Windows via the Parallels VM. Great software!

Running iPhone UI code from other than the main thread

2009-05-14T00:07:00.007+01:00

If you've got a relatively complex multi-threaded app, where you need to have something happen in the UI in response to an event occuring in a thread that is not the main thread, then you're going to have to be careful!

Basically, what you need to do is use performSelectorOnMainThread to execute your code that does UI work; as otherwise the UI calls you make will probably cause your iPhone app to crash!

The way to do this is to create an instance of an Objective-C++ (or C!) wrapper class that has a method on it which'll do the UI work for you (and could well have a modal loop within it, like for yesterday's post). That method could be something simple, like:


- (void)DoTheUiStuff
{
  // All the UI code is here
}

Derive this class from NSObject (or maybe UIView, of course!).

You can then invoke this method through a selector, passed to your call on your class instance to performSelectorOnMainThread. When this call returns, you're safe to clean-up your wrapper class instance and get back to whatever your thread was up to in the first place...

Running a UIAlertView modally

2009-05-13T11:19:00.005+01:00

The funny thing about UIAlertView (and other iPhone modal interfaces), is that they don't actually run modally; in other words, you can't do something simple like this:

bool bResult = [myUIAlertView runModal];

Rather, the UIAlertView has a show method ... which shows the dialog, but which doesn't simply hang around and give you a result when done.

What you need to do in this situation, is create a delegate to handle the message generated when the UIAlertView button is pressed; and you must then provide you own modal processing loop!

Here is a simplified version of what you need to do. Spot the code loop that makes it all run modally!

// Create an instance of a custom UIAlertViewDelegate that we use to capture
// the events generated by the UIAlertView
MyUIAlertViewDelegate *lpDelegate = [[MyUIAlertViewDelegate alloc] init];

// Construct and "show" the UIAlertView (message, title, cancel, ok are all
// NSString values created earlier in your code...)
UIAlertView *lpAlertView = [[UIAlertView alloc] initWithTitle:title message:message delegate:lpDelegate cancelButtonTitle:cancel otherButtonTitles:ok,nil];

[lpAlertView show];

// Run modally!
// By the time this loop terminates, our delegate will have been called and we can
// get the result from the delegate (i.e. what button was pressed...)
while ((!lpAlertView.hidden) && (lpAlertView.superview!=nil))
{
[[NSRunLoop currentRunLoop] limitDateForMode:NSDefaultRunLoopMode];
MySleepMilli(10);
}

// Grab the result from our delegate (via a custom property)
int nResult = [lpDelegate result];

// Tidy up!
[lpAlertView release];
[lpDelegate release];

Hope that helps!

Vim - easy to install MRU list

2009-05-12T09:15:00.005+01:00

If you want an MRU list in your vim window for Windows/Linux (which is very useful, trust me!) then simply follow the instructions you'll find here to install a really useful Vim plug-in:

mru.vim : Plugin to manage Most Recently Used (MRU) files

This works very well with with the vims I've tried it on so far, which are gvim and cygwin vim on Windows, console-based vim and gvim on Linux, as well as console vim and MacVim on the Mac.

Even though an MRU system of sorts is already built-in to MacVim, I still recommend using this vim plug-in as it also works very well with MacVim.

iPhone Ad Hoc Distribution gotcha

2009-05-10T15:06:00.004+01:00

Here is a good one - if you forget to update the version number in your iPhone app (through the info.plist file): and then try to install the App to your iPod/iPhone as an Ad Hod distribution, iTunes will prompt you to upgrade your app; but will actually fail to upgrade the app at all. :)

In this case, you could either first delete the app and re-install (but this would lose any app-specific data of course); or re-build with a new version number!

On another note, if you try to just zip-up your app with the Compress feature in Finder, and send that - it won't capture enough information, and will fail to install on your ad-hoc target devices. Instead, you should copy your app file to a folder, use Disk Utility to create a DMG file from that folder, and then zip-up the DMG file; and send that on to your testers. That will work. :)

iPhone - clearing the Bonjour jungle

2009-05-08T08:58:00.004+01:00

Phew: the Mixtikl file sharing code seems to be pretty much sorted out now. It has been a lot of work, but it is great to be able to have Mixtikl on the Mac share files with Mixtikl on the iPhone (in both directions!) through the local network.

I like the way that you can copy a Tiklpak from Mixtikl on your Mac, to Mixtikl on the iPhone, and use it immediately on your iPhone without having to restart. Nifty!

I can now get back to tidying-up the skin code to accomodate Tim's latest design. And when that is done: we'll be in a position to submit Mixtikl 1.5 to the App Store...

Just for the record though, if the iPhone allowed the desktop machine to connect to the iPhone, such that the desktop could read/write data into an "public" area specific to each app; that would have made everybody's lives so much easier without breaking the sandbox model.

The approach taken in Windows Mobile is much more flexible - just copy files around as you want, using Explorer and Active Sync ... though of course the fact that Mixtikl for iPhone has an integrated solution will make it really easy for Mixtikl users with a Mac. Windows users with an iPhone will not find things so easy though...

Fun with Bonjour and NSRunLoop

2009-05-03T20:26:00.006+01:00

You know, I keep coming back to not liking much of the implementation behind Cocoa, no matter how much I use it!

Here is the sort of thing that irritates me. I create a dialog within Mixtikl (using our own internal GUI framework), and run it modally. Within that Dialog, I use Cocoa services to request to be told what Bonjour-advertised services are available. What do I get? Well, nothing, other than a call through the delegate to tell me that searching has started.

It turns out that the processing behind the scenes works only if the active NSRunLoop is allowed to do processing; so I've had to add-in a call like this in my modal loop:


    [[NSRunLoop currentRunLoop] limitDateForMode:NSDefaultRunLoopMode];

So you might ask, what is wrong with this? I contend that for such processing, the system should be smarter and use an approach that doesn't require specific magic within the client code (in this case, a worker thread that does the work without my having to worry about blocking it). Otherwise, people who know a lot less than me might never be able to figure-out what they've done wrong.

Bonjour is a great idea, and is built-in to Mac/iPhone: however, I can't spot any open-source implementation that I can use for other platforms. If any reader would be kind enough to point me to such an implementation, I'd love to take a look!

Objective C++ and file extensions (.m, .mm, .cpp)

2009-04-27T13:31:00.006+01:00

If you've ever wondered how to combine C++ and C in your Cocoa code for iPhone or Mac, it is as simple as renaming your files to have a .mm extension, rather than the default .m extension.

It is a shame that Apple don't enable this file extension by default in their code building wizards. It certainly makes the transition to Objective C for C++ programmers a lot easier!

Anyways, for those of you interested in porting your C++ code across to iPhone and Cocoa, without having to rename your files or create lots of .mm file wrappers; I discovered under Linux that -x objective-c++ can be used to tell the compiler to treat the file as an objective c++ file; irrespective of the file extension... as follows (wbere test.cpp actually contains Objective-C++ syntax, and would normally be called test.mm ...):


gcc-4 -x objective-c++ test.cpp -lgcc -lobjc -o a.exe -lc -lstdc++

There are two ways to use this in XCode:
- on file-by-file basis, right-click on any .cpp file in which you want to put some Objective-C and/or C++, and select Get Info. In the Build tab, set -x objective-c++ in the Additional Compiler Flags field.
- alternatively, for the entire project, in Project Settings under Build, under GCC 4.0 - Language, set Compile Sources As to Objective-C++.

As always; this is easy when you know how...!

Pete

CFSocketCreate on iPhone

2009-04-25T15:03:00.001+01:00

If you're doing sockets programming on your iPhone (like I'm doing for Mixtikl's file sharing server code), don't panic when your call to CFSocketCreate fails to create an IPv6 TCP socket when passing PF_INET6.

Just accept the IPv4 socket that you will get when passing-in PF_INET, and all will be fine... :)

MacVim and XCode

2009-04-25T14:59:00.004+01:00

XCode no longer automatically launches MacVim to edit my files. However, this actually forced me to find what I think is a better solution. :)

All you need to do is open-up MacVim and XCode; and drag any files you want to edit from the XCode project window file list, on to MacVim. The file you drag-across opens automatically in a new tab for editing under MacVim. Really easy!

Even more easily: if you are editing a file in XCode, and don't want the hassle of first searching for it in the project file list in order to drag it to XCode; simply right-click on the XCode editor window, select the option to Reveal in Finder, and then right-click on the file in the Finder window and select the option to edit with Vim.app ...

CGContextSelectFont - slow slow slow...

2009-04-24T12:22:00.001+01:00

Wow, that was a shock. There I was profiling Mixtikl on the iPhone after tuning various things, and what do I find? CGContextSelectFont is hogging 30% of the CPU cycles!

This is nothing new apparently (see http://www.manton.org/2005/12/cgcontextselectfont.html - which dates from 2005!). Thanks Apple. :-(

The solution was this:
- when you grab a CGContextRef from UIView (or for example when I create my own singleton temporary one I use for off-line calculation of text display areas...), set the font just once on that CGContextRef by calling CGContextSelectFont with a temporary font size of e.g. 10; do this before you do any text drawing operations with the CGContextRef...!
- Whenever you need to draw text, call CGContextSetFontSize before you call CGContextShowText (or whatever...); do not call CGContextSelectFont as there is no need to set the font by name and size in most cases, just the font size. Calls to CGContextSetFontSize hardly take any time at all ... and your performance problems will disappear.

That makes a huge difference to performance, and is easy to do when you know how. :)

Tweaking Mixtikl on the iPhone

2009-04-23T22:42:00.000+01:00

While Tim is fiddling-away with the new iPhone skin (there's no point in rushing him, he only ignores me anyways ... just joking Tim!), I've been spending my time tweaking the UI responsiveness of Mixtikl on the iPhone, and fixing some odd bugs left-over from the porting process.

User interface latency is really fabulous ... so much better than Windows Mobile.

Our pluggable font engine has paid dividends yet again, the effort to move text display across to iPhone was only the matter of a few hours work, as is usual for our trans-platform graphics architecture. It sometimes amazes me when things like this work so quickly, but I guess I shouldn't be surprised any more. :)

I have few other bits-and-bobs to sort out, but things are looking and sounding very good indeed...

Missing symbol with mangled name when loading a library under Linux? How to track it down.

2009-04-23T11:06:00.000+01:00

Suffering from a missing with a mangled name when loading a library under Linux? Here is how you can track down what is missing.

I had a library failing to load...

The error output reported a "symbol lookup error" for a mangled name like _Zkasdfkadf83 ... which didn't help me much. :)

To figure-out what this is:


cd [the folder with your libraries in]
grep  Zkasdfkadf83 *.so

... This tells you the library that the symbol is referred to from.
Assume this is fred.so

Then, do this. Note: the first version shows you the mangled names, the second version shows you the UNMANGLED (i.e. human readable) names... Other than that, they are identical.


nm -B fred.so > sym.mangled
nm -C fred.so > sym.unmangled

Edit both files.
Look for the missing symbol in the first file, make note of the line number.
Go to that line in the second file. That shows you the unmangled-name corresponding to the mangled name. It should now be crystal-clear what the missing symbol is!

HTH

Pete

The power of Vim

2009-04-21T23:32:00.001+01:00

I don't often post on tools, but I thought I'd make a mention for some fabulous new software I discovered and installed today:
- ViEmu: a Vim editor plug-in for Microsoft Visual Studio, which integrates really well within Visual Studio and is a bargain IMO ... http://www.viemu.com/index.html
- MacVim ... http://code.google.com/p/macvim/ - a wonderful version of Vim for Mac, which works quite well with XCode. And it is free!

I've been a power Vim user for many years now, having first started using vi around 20 years or so back. The key for me is that whatever programming work I have done, on every single platform (apart from VMS - shudder!) I've been able to use one vi variant or other as an ultra-productive editor.

vi and Vim have been staples of mine on Windows for ages, mainly in the context of cygwin on Windows. I've been using gvim for Windows for a long time now, and it works quite well with Visual Studio; but the ViEmu/VS is such a great integrated solution that I simply wish I'd heard about it years ago - I hate to think how many hours of programming time it would have saved me. :)

On MacOS X, I naturally use vim from the terminal window (this has been built-in to all Macs for ages). But MacVim is a great implementation, and hooks-in an awful lot better to XCode. Again, I wish that I'd installed it a long time back. It is going to save me a huge amount of time going forward.

I should note that while there are some good points about both the editors in XCode and Visual Studio, they are both staggeringly less productive to use for every day editing than Vim. When you consider the amount of cross-platform coding I do, I simply can't afford to specialise in either of these two editors. I need one common editing paradigm that rocks for all platforms. So for me, great implementations of Vim on Windows and Mac, that integrate well with Visual Studio and XCode respectively, are tremendously important.

I also spent some time today learning about some features of Vim that I simply didn't know about, that are going to transform my editing life. Visual selection modes, anybody? :)

Finally, if you're a serious programmer and haven't tried Vim - go for it. Take the pain of 2 weeks learning curve, get touch-typing and begin to feel the force. :) Vim is free, and you can get it from http://www.vim.org/ for most platforms, or within Cygwin for Windows. It is also built-in to MacOS X and Linux.

Mixtikl on iPhone - dealing with chubby fingers

2009-04-17T11:54:00.000+01:00

We're taking our time to get the iPhone version of Mixtikl "just right".

After playing around with Mixtikl on a real device, it became obvious that the general inaccuracy that you get with touch-only devices using chubby fingers :) meant that the Mixtikl skin needed to be "chunkier". This is as opposed to pointer-controllable devices like most Windows Mobile PDAs, where you can have a UI that supports smaller elements that can be selected accurately with a pointer device.

We've come up with a nice solution to this problem, and in the interim have been extending the underlying .partikl file format to take better advantage of local sample files (in Ogg and DLS format) used in the Tiklpaks. All will become clear when we release the next version of Mixtikl!

These changes are combined with other user-interface tweaks, which we think make a great deal of difference to the usability of Mixtikl across all our platforms.

We can't wait to release this new version ... but won't rush it. :)

Pete

Running Mixtikl on my iPhone

2009-03-30T21:50:00.000+01:00

At long last, Intermorphic's iPhone SDK application has been activated, we've got our certificate, and we've got Mixtikl running on my iPhone! Exciting times... :)

Sound quality is great, the UI is responsive and things are looking good. :-)

It'll be fun getting Mixtikl tidied-up for the iPhone; Tim's already created a great new iteration of the skin that we'll release first for the current platforms (Windows, Mac, and Windows Mobile). We've also been generally improving the workflow and usability of Mixtikl, and will be using the reworked Mixtikl as the basis for some neat demo videos.

We hope to be in a position to submit Mixtikl to the App Store in the next 3 months or so, but time will tell...! We certainly don't intend to release it until we're totally happy that it offers a polished iPhone experience.

Pete

JavaScriptCore and iPhone

2009-03-16T13:12:00.000Z

I'm really surprised that while Apple use JavaScriptCore within the iPhone platform, they don't expose it to application developers (even though it is available to Mac Desktop developers!. That seems very last century. :)

Application development can be a lot quicker when using scripting approaches, but the SDK only allows you to use scripting technologies provided by Apple. I really hope Apple expose the JavaScriptCore engine in the next update to iPhone, that should unlock a whole lot more creative Apps for the iPhone platform.

Meanwhile, we're continuing to use Lua within the Intermorphic applications for Mac/Windows desktop and Windows Mobile. I've recently been evaluating JavaScriptCore and SpiderMonkey, with a view to using JavaScipt as an alternative to Lua for our applications and engines. The reason? Mainly that a lot more people are familiar with JavaScript than Lua! Reasons not to? Mainly down to licensing pain. And Lua is a great scripting language; Lua is actually very similar to JavaScript.

Is it just me, or were the GPL licenses designed to be some kind of IP virus?

iPhone Interface Builder madness...

2009-02-19T21:21:00.001Z

Hi!

I've been meaning to mention this for a while... and this has just happened to me again I guess the time is as good as any to mention it!

Basically: if you use XCode to create a New Project, based on Tab Bar Application... as soon as you try adding some items with activated UIAction responders, you're going to get an exception like this when starting the app... which is not a good thing. :)


'NSUnknownKeyException', reason: '[ setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key ....'

When this happens, you're the victim of a really stupid bug in Interface Builder/Cocoa.

I wonder if this sort of problem is enough to put-off novice developers from using Interface Builder... that would be a shame.

Anyways: the solution to this problem is as follows...

From Interface Builder, select MainWindow.xib

Within the Tab Bar Controller, select each of the two View Controller items in turn... and for each one:
1. Press Cmd-2
2. In the window that appears, click on the right-most button with a (i) mark on it
3. ... and in the Class combo box, specifiy the class to be FirstViewController... (the two items are both wrongly set to be UIViewController!)

Save your XIB file, rebuild the system, and all will then work!

The above steps are explained (obliquely!) here:

Very basic problem with Tab Bar Application and Interface Builder

What surprises me is how little Apple fans complain about hideous bugs like this. :)

Pete

Back to Noatikl!

2009-01-25T21:32:00.000Z

Now that the first release of Mixtikl has settled-down nicely (with an iPhone port hopefully pending, subject to feedback from Apple), we're starting to look again at Noatikl.

The first thing to sort-out is to make it easier to use templates, and we've just updated Noatikl to version 1.5.0.15 to deal with that. It is now really, really easy to merge Noatikl pieces and templates together.

The next thing we'll be looking at is some big stuff for Noatikl 2: mainly the generative pattern editor, which is a big chunk of work, and is something that is going to take a lot of focus from us over the coming months. We might also spend some time looking at easy-to-use interfaces for the Noatikl engine for mobile. Whatever we do, we're planning on having some real fun with our generative music engine!

iPhone and Bonjour file sharing

2009-01-11T22:32:00.000Z

I've finally figured-out how to share files between my iPhone running Mixtikl, and other devices connected to the local network using Wi-Fi. Though it is a lot more work that it should be. :)

The way to do it was for Mixtikl to run as a HTTP server which broadcasts it's presence using Bonjour (see Apple's CocoaHTTPServer example to get you started!), and then you can browse for and grab files from it (e.g. saved .mixtikl or .partikl files) using Safari from any browser on your network! From Safari, select Bookmarks -> Show All Bookmarks, and click on the Bonjour tab. There is a Mixtikl entry from every Mixtikl iPhone on the local network; double-click on it to show the list of files on the iPhone, and select/save the files you want to your Mac!

The other way around, you're able to use Mixtikl on the iPhone to see files advertised by Mixtikl on the Mac (which also runs a HTTP server advertised using Bonjour); Mixtikl has a special view allowing you to select the server to use, look at the file list, and select the file(s) you want to copy-across to your iPhone.

Cool stuff; welcome to the Zeroconf revolution! :)

Porting Mixtikl to iPhone

2009-01-05T22:23:00.000Z

I spent most of Christmas finishing-off the bulk of the remaining port of Mixtikl to iPhone, with a view to possibly releasing it if we can resolve various issues related to Apple's SDK terms.

I had planned to work on the Symbian port, but delayed that after reminding myself again of the horrors of porting any code to Symbian. :) That will wait for a few more weeks...!

Anyways, it is interesting to reflect on the iPhone porting process.

All in all, I reckon it took me around 3 to 4 weeks to port Mixtikl; which was mainly about creating an iPhone abstraction layer, with Cocoa variants for some of the code.

Not too hard, but there is some crazy stuff out there:
- you have to abandon all use of fopen() etc., and use Cocoa NSFileManager instead. If you try fopen() in the emulator, it'll try to open files in the host Mac's file system; which isn't what you want. :) opendir() etc. all have to be replaced, too.
- Mixtikl is highly threaded. I simply couldn't get the NSTimer class working properly in such a threaded system, and resorted to using Thread-based timers instead (that wasted a few days, drove me potty!).
- despite what Objective-C/Cocoa heads tell you, I found autorelease pools difficult to get my head round, easy to leak by mistake, and inefficient on occasion. IMO, if you have to learn magic rules for when you can and should release objects returned to you within the system, then the system ain't as smart as it should be. No such problems in Java. No such problems in C++! You need to remember that not all of us spend all of our time writing Objective-C, and it isn't easy to dip-into without making mistakes in this area.
If you call [object release] when you shouldn't, the system fails at some unrelated time in the future; if you fail to call [object release] when you should, the system will leak and it ain't easy to track down! Horrible.
- On a related note, avoid using NSData to hold file read/write data; use the file descriptor and low-level file-descriptor function such as read()/write() instead. Why? Well, if you're reading loads of file data, the NSData objects (which are purged by an auto-release pool) aren't actually purged until some arbitrary point later over which you have no control. This can lead to your system running out of memory as lots of auto-release objects are accumulated but not yet purged (!); leading to memory allocations failing bizarrely even when you're convinced your software should still have access to lots of memory (the memory clearly isn't available until the system purges the autorelease pool.... at some point when it feels like it!). You can avoid this simply by using file descriptors instead (from [myfile fileDescriptor]). Oh, and another reason is that file descriptor based access is a whole lot faster, as there is no unnecessary buffer allocation/releasing going on.
- you'll be amazed at how horrible image drawing is, if you're using Core Graphics like we are. Having to use transformation matrices to account for the inverted Y coordinate was not fun at all, to say the least! :(

On a separate note, the state of play wrt demo code for Apple/iPhone/Microsoft etc. remains pretty poor. When I worked at Tao Group, I put lots of effort into creating many clear, fully-working and complete demo programs that illustrated many different specific specific uses of our Audio APIs, along the lines of "what code do I need to achieve this specific effect", including playing files, playing streams, adding effects plug-ins etc. I can but presume that the reason that most companies don't do this, is that those responsible for writing the APIs aren't actually genuinely passionate about helping the people who want to use their APIs. This always leads to me wasting lots of time fiddling with poorly written demos, trying to figure-out how to actually use the various APIs...

Mixtikl now released!

2008-12-23T09:51:00.000Z

Wow - at long last! Mixtikl is finally out of the door. And before Christmas, too!

With the software finally released, it was a real treat to sit-back and relax by simply playing with Mixtikl for a while, mixing-up the paks and generative music elements. Frankly, it sounds amazing and is a blast to use.

Do try out some of the Noatikl generative music items in the Tiklpak Cinematic 120d, which is one of two Tiklpaks that comes embedded with Mixtikl. The generative items show up as red in the content list. They make for amazing backing sounds! :

So, onwards and upwards from here. We already have lots of things we want to improve, and lots of things we want to add (including many more Tiklpaks!), and we also want to take a look at Noatikl and Liptikl. 2009 should be very busy, but hopefully not as frenetic as 2008!

Pete

Mixtikl - launch in a few days

2008-12-09T13:15:00.000Z

Hi Folks,

We're aiming to launch Mixtikl any day now; we'll do our best to get it out of the door before the weekend starts. :)

Pete

Mixtikl now in Beta

2008-12-04T15:11:00.000Z

Well, we're almost at the finishing line ... Mixtikl is now in Beta, and we can't be more than a week from the full release. Thank goodness!

Mixtikl is easily the most complicated piece of software I have ever created! The last time I checked, there was more than half-a-million lines of code in there ... and then there are all Tim's skins and the Tiklpaks and the documentation we've had to create... this has certainly been a labour of love!

Keep an eye on the Mixtikl site for the draft user guide and lots more information! The user guide is ever expanding, and hopefully makes for an interesting read...
http://www.intermorphic.com/tools/mixtikl/index.html

I'm looking forward to porting to Symbian Series 60 during my Christmas holidays (yeah, I really know how to enjoy myself!). I've already completed most of the iPhone port, in case we ever decide to release on that platform...

Mixtikl Beta (and Alpha!) - and some background

2008-10-14T12:21:00.000+01:00

It is always something of a relief to hit major project milestones. We have already passed a major one: Mixtikl is midway through its Alpha testing phase and now has people other than Tim and me using it! The Beta release is now only weeks away.

What is Mixtikl, and why are we so excited by it?

Mixtikl is the first mobile music creativity app that does not ignore the importance of the 'full-on' desktop music sequencer. Mixtikl embraces it: with both plug-in and standalone versions. Mixtikl is for both PC (Windows and Mac) & Mobile!

Mixtikl is open: Use your own content, or from in add-on Tiklpaks.

Capture / mix / work on content on the move on your mobile.

Finesse your mixes on PC using the Mixtikl plugin.

Move your mixes between mobile and PC and back again.

'Performer' app - Perform music on your mobile.

'Remixer' app - Create quick mixes, and mix and match sounds.

'Partikl' app - Sound and FX design, exporting mix files

'Player' app - Play lists of Ogg, MIDI and generative music.

Use audio loops, MIDI, generative music & modular synthesis.

Integrated Noatikl generative music engine for generative music.

Pitch shift your loops and apply realtime FX.

Act as VST or AU plugin in your VST/AU enabled sequencer.

There is also a whole lot of other stuff in there that we'll let you all know about when we release it!

What is Noatikl, and why is it in Mixtikl ?

For those who don't know, Noatikl is a Generative Music tool. This is an easy-to-use program (with great depth!) which helps you make music; by composing the music for you, in real time, while you give it direction in what to do!

Mixtikl contains a run-time version of Noatikl . That is to say, it Mixtikl lets you play your Noatikl compositions on whatever device you happen to have Mixtikl . You can use Mixtikl 's built-in synth designer (called Partikl) to attach sounds to your Noatikl compositions, to really bring them to life in a cross-platform way.

This lets you, for example, create playlists of Noatikl Generative Music pieces that you or your friends can listen to on the train, where the music changes every time you hear it; as a change from listening to the exact same notes in your MP3 collection time-after-time!

Releasing software is hard work!

It never ceases to amaze me exactly how much work is required to get software out of the door. We've been creating products since the early 1990s, so we've got a feel for how long things will take now and what order things need to be done in.

Our prediction "way back" when we started creating Mixtikl out of the ashes of miniMIXA has actually been pretty good; we figured it'd be out sometime this month (October) but it now looks like it'll be November. As always, the delays are due mainly to discovering new things along the way, and adding them in to make the product more interesting! :)

The software is now pretty much in a Beta state, give or take a few items. We'll let it out of the door when it feels ready!

Looking back, to look forward

It is interesting to reflect that we actually created the first version of miniMIXA back in 2004; and that we won a BAFTA award for miniMIXA back in 2005 - more than three years ago! If our then employers (Tao) had had the vision and resources to back miniMIXA, I wonder where we'd have got the product by now... Still, we're making up for lost time and are having a blast bringing Mixtikl to life.

It feels amazing to sit on a train and sculpt music in real-time on my mobile. And, when I want, just kick-back and listen to a generative music playlist courtesy of the built-in Noatikl Generative Music engine. And I still can't quite believe it when I use the exact same software as an Audio Unit under Logic, a VSTi under Kore 2 or Sonar ... or even standalone on my Mac/Desktop.

This is been such a long road; we started writing the code that is within the Intermorphic Sound System, which underpins Mixtikl , more than 6 years ago. We started writing the 2d engine that the Mixtikl UI sits on, well over a year ago. minMIXA itself took around 3 years to write, including three major releases. The port from miniMIXA to Mixtikl has been a long, hard slog through 2008, but it is great to be so close now to releasing the product that reaches our vision from nearly a decade ago!

And that product is an extendable, trans-platform music/media mixer and "box of tricks". And it includes a runtime of the Noatikl Generative Music engine. The first Mixtikl versions are for Windows (Standalone, VSTi), Mac (Standalone, Audio Unit, VSTi), Windows Mobile Pocket PC/Smartphone (Standalone). Once those are finally released, Symbian Series 60 looks to be our next target. And hopefully iPhone after that, if Apple ever solve the problems with their SDK.

We have lots and lots of ideas of ways to extend Mixtikl - and the prices are going to be amazing. I can't wait for the first full release ... not long now!

Pete

Mixtikl now in Alpha

2008-09-26T07:49:00.000+01:00

Phew!

It is always something of a relief to hit major project milestones. And we have just passed a major one: Mixtikl has entered its Alpha testing phase and now has people other than Tim and me using it!

Pete

Porting Mixtikl to Mobile - Windows Mobile, Symbian, iPhone, Antix Game Player

2008-07-27T15:33:00.002+01:00

While evolving miniMIXA into Mixtikl at my company Intermorphic, I've encountered quite a few issues porting Mixtikl to the various mobile platforms, and I thought it'd be useful to be able to share some of this with those of you interested in writing trans-platform applications. I hope you find this of use! If you have any comments, please let me know!

A bit of background

Before I start, the first thing to note is that for implementing any trans-platform application of this complexity (750K++ lines of code!), you'll need to start with a common UTF8 library. I wrote that when I first started Liptikl, so didn't have to worry about that this time round!

I started by implementing Mixtikl to sit on top of the trans-platform graphics layer that I'd already written. The first implementations of this layer were for Juce, Direct X, Windows Mobile GDI, and SDL. Symbian will come soon; iPhone is ongoing, and hopefully Android at some point. The Juce version of the graphics layer for Mixtikl were really easy - Juce is a really great platform for desktop apps. Hence, Mixtikl for Windows and Mac desktops were relatively straight-forward (considering the complexity of Mixtikl!) And, of course, it made the plug-in variants of Mixtikl relatively easy to sort-out.

What do I like about writing for Windows Mobile?

- Great tools: Visual Studio is simply superb.
- Fabulous documentation - mostly. I love MSDN, but the API documentation is light on in-situ example code, and I have had to spend a lot of time surfing for solutions to problems. I still rely on my old Windows API Bible (by Jamle L Conger) - certainly the best API guide I have ever seen, packed with examples of every API call; no longer in print, but amazingly still relevant to graphics coding for Windows Mobile!
- Windows Mobile supports full-duplex audio, which is more than can be said for Symbian...!
- Windows Mobile devices are very consistent
- Windows Mobile devices have good user input: joy pads for control, and keypad/touchable screens where appropriate.
- Windows Mobile allows users to copy data freely to-and-from their desktop computer (via Internet Explorer), which is more than can be said for iPhone...!
- End-of line Windows Mobile 2005 devices are really, really good value.

What don't I like about writing for Windows Mobile?

- Graphics APIs: it took a while to get our Windows Mobile graphics layer sorted-out.

I wasn't able to use Direct X out-of-hand for a couple of reasons. The biggest consideration is that we think that it is useful from a usability perspective for an application like Mixtikl to be able to use the mobile device's soft menus, and to display the status bar. However, Direct X apps on Windows Mobile only run full screen, which made it a non-starter. On another point, there is no PNG import support, the blit routines are not flexible, and I'd have had to do a lot of blitting through my own generic blit functions anyways.

So, we used the standard win32 GDI API for Windows Mobile. The biggest problems I faced here were twofold: I had to implement my own png importer (it is a huge oversight for this not to be built-in to Windows Mobile 2005!), and I didn't realise that when constructing an in-memory bitmap on Windows, I had to WORD-align all lines in the bitmap. That latter problem actually had me stumped for a few days! Also, you need to know to create your bitmaps where possible as 565 BGR bitmaps, as this is the most memory format for Windows Mobile; transparent bitmaps must be stored as 32-bit ABGR bitmaps.

- Problems with the Visual Studio 2005 C++ compiler

Even though the port to Windows Mobile wasn't so hard, I faced some serious problems with Visual Studio 2005. The first problem is that the emulator is so *slow*; I ended-up having to get a top-of-the range Mac Book Pro to get the emulator running fast enough for real-time debugging of my audio engine under the emulator. And far more seriously, there is at least one horrible bug in the compiler ... you can read more about the bug here:
http://vividos.wordpress.com/2007/12/06/the-infamous-arm-by-value-compiler-bug/
http://vividos.wordpress.com/2007/12/09/in-depth-analysis-of-the-arm-by-value-compiler-bug/
The bug is fixed in Visual Studio 2008...

- Visual Studio 2008 Pro is required for Windows Mobile 6 development

Due to the compiler problem in Visual Studio 2005, we upgraded to Visual Studio 2008 Pro; it fixed our compiler problems, and you need at least the Pro version of Visual Studio 2008 to develop for Windows Mobile 6. It is a shame that Microsoft didn't include the Windows Mobile support in the Standard Edition; only the Pro edition (or even more expensive versions) contain Windows Mobile support; I'm sure this puts-off a great number of hobby developers from developing for the platform.

I've taken a close look some of the ARM code generated by the Visual C++ 9 compiler, and it looks really good; the code it makes for maths routines is as good as (or better!) than I can write by hand, so I'm happy to say that I'm keeping clear of assembler on this platform!

- The lack of build-in profiler; you don't get a profiler without paying for an even more expensive version of Visual Studio. This seems a shame for hobby developers.

What do I like about writing for Symbian?

- Symbian allows users to copy data to-and-from their desktop computer (via Internet Explorer), which is more than can be said for iPhone...!
- Symbian devices have good user input: joy pads for control, and keypad/touchable screens where appropriate.
- Based on the Gnu tool chain, so the compiler is good!

What don't I like about writing for Symbian?

- the lack of full-duplex audio support. This is a crazy omission in the Symbian APIs. If anybody out there is listening, you should commission Intermorphic to provide you with a decent audio library. :)
- the need for multiple SDKs. Series 60, UIQ, and variant sub-variants of each... that is a lot of stuff to keep track of.
- if you put your software code a little too deep in your file/folder structure, the Symbian build system falls over!
- documentation nowhere near as good as what is available on MSDN or Apple's site.
- the user interfaces. Why is so much screen real-estate wasted on the title-bar and soft menus, for example?
- the really weird idiosyncracies in their use of C++...
- Symbian doesn't allow full browsing of the local file system from the device; if you want to see what is on a storage card, you have to pop-out the card and look at it with Windows Explorer using a card-reader!

What do I like about writing for iPhone?

- XCode is free for all Mac users!
- It uses a good development environment. XCode is quite nice, though the debugger drives me potty compared to Visual Studio when browsing variables in the application code.
- XCode has a really, really good build-in code profiler. Well done Apple!
- No need to write graphics importers; image loading is pretty easy.
- Based on the Gnu tool chain, so the compiler is good!

What don't I like about writing for iPhone?

- The real killer, show-stopper, "I don't believe it" problem is that the user can't copy data to-and-from the desktop and any data area that can be seen by an iPhone application. This is a *massive* problem with writing software for iPhone. Why even bother attempting to write creativity software for iPhone, if you can't transfer data between your desktop computer and your mobile? Why didn't Apple provide for a common area to which all apps can read/write, and where Windows Explorer and Finder can also read/write. That seems a complete no-brainer to me.
- You're not allowed to use interpreted languages or scripting engines in your applications (other than those in Apple's own APIs - which aren't adequate). Which is not good news for games that rely on scripting engines to get their behaviours, or the user Lua scripts in Noatikl pieces, to give just two simple examples! I am really puzzled by why there would be such a restriction...
- No support for storage cards. No doubt to force all content to come via the Apple Store...
- No clipboard support. Presumably this is part of a cunning plan by Apple to prevent applications sharing data with each other. :-)
- Objective C. It is a great language that seems very well suited to development in a wide range of contexts. It is a whole lot cleaner than C++ (IMO!). It is great that you can mix objective C and C++ in your code (if you first remember to rename your files to have .mm extensions, rather than the default of .m!). However, it just wouldn't be cost-effective to write a new application purely in Objective C; so you have to write most of your code in C++, and implement a very thin adaptor code layer to the iPhone APIs. Fair enough!
- the touchable user interface can't be operated with a pointer stick; that makes high-precision user interfaces a no-no

And to close with a slightly off-target point: why doesn't my Mac Book Pro have a built-in 2-button mouse? Drives me potty.

What next?

The Antix Game Player looks interesting! Android is also on the near horizon; but, and here is a show-stopper: it looks like it only allows apps for it to be written in Java ... which seems crazy!

Hoping this is of interest!

Pete

Mixtikl - coming soon!

2008-07-11T07:43:00.000+01:00

Mixtikl - what a huge challenge. Taking miniMIXA into the real world! What you'll see and hear will just be the tip of an iceberg of multimedia code, enabling what we think will be the first truly trans-platform multi-media creativity tool.

We've been working towards this for some time now, and it is really quite amazing to physically see/hear Mixtikl working as a native app for Windows and Mac, as an Audio Unit for Mac, and as a VSTi for Windows/Mac, and also on Windows Mobile! With interchangable files that work on all supported platforms! Oh, and an embedded Noatikl generative music engine. :)

We're currently very busy working on polishing-off the work we've done so far, and will then be looking to port to iPhone - where I hope there won't be too many issues with sand-boxing or integration with Objective C...

October 2008 release? Well, that's what we're aiming for. Wish us luck!

Pete

noatikl 1.5

2008-02-05T20:50:00.000Z

Well, that was hard work, but we've now got noatikl 1.5 out of the door.

For those who don't know, Noatikl is a Generative Music tool. This is an easy-to-use program (with great depth!) which helps you make music; by composing the music for you, in real time, while you give it direction in what to do!

This is a major new development for us, as it completes an arc of development that has been going on for many months now, and has increased the power of noaitkl greatly. The plan was threefold:
- give noatikl pieces the ability to incorporate internally generated structure
- give noatikl the ability to respond to MIDI input events
- introduce a fast, flexible, easy-to-use scripting system to bind it all together!

So: on one hand, we've added the ability to control noatikl from within, with (optional!) Lua trigger scripts that fire while the piece is playing. The effect on noatikl is quite incredible. It is especially gratifying to see users who are self-confessed 'scriptaholics' test-driving the new features, and finding that it totally transforms their ability to control noatikl in the way they want.

On the other hand, noatikl can now be controlled in real-time in response to incoming MIDI controller events. Not only that, but noatikl automatically harmonises with incoming MIDI note events; and those note events can be used to trigger various responses within noatikl using the scripting engine. noatikl can now fairly be described as a hyperinstrument!

What next? Well, for starters we have plans to greatly improve the pattern handling within noatikl. That should keep us busy. :)

Pete

Graphics libraries and scripting

2008-01-25T10:19:00.001Z

In case you're interested, in addition to adding Lua-based scripting to noatikl, I've been using the same scripting engine in prototyping optikl, the generative visual art program we hope to release some time.

To help optikl and our other products go wherever we want, including maybe to mobile, I've written a common graphics library adaptor layer that sits on top of SDL, Juce and what have you. So this will let us, in future, write our apps once and simply recompiling them for whatever the target platform might be, without the need for any major rewrites. :)

Pete

Low-latency audio IO on a MacBook!

2008-01-25T10:14:00.000Z

My brother (Tim Cole) has tried using Asio4All to get low-latency audio on his Mac Book, but ended-up having various problems with it.

Well, I’ve found the easiest solution on my MacBook and Mac Mini was to get a really cheap Firewire low-latency audio box, that works with both Windows XP and Mac OS X. This was the Behringer FCA202. There are lots of really cheap offers for this in the webstores right now, and it is a tremendous piece of kit!

I’ve been using this to work on ideas for the noatikl hyperinstrument and MIDI-control features.

For that matter, I wonder if we should use the term “hyperinstrument” or “hyper instrument”. I’ll stick with the first spelling, unless anybody can tell me otherwise! :)

Pete