Back to Noatikl!

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

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

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!

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

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

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

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

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

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!

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

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

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!

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

intermorphic - at the start of 2008

For those of you who are keeping up with developments at intermorphic Towers, we sure had a lot of fun getting our new web store live - believe it or not, we finally got it running late on Christmas Eve. :) It was nice to be able to enjoy Christmas with that out of the way…!

Since then, we’ve been working hard to continue to improve and extend noatikl.

We’ve been trying to keep updates for noatikl coming every couple of weeks, and keep on adding new and interesting stuff. The next update will feature support for build-in trigger scripts and MIDI control of noatikl, which is very exciting as it takes noatikl into the realms of being a customisable hyperinstrument!

It has also been great to be able to work again with Tim Didymus, who authored two new Generative Drum template packs for noatikl. These are tremendous fun to use, and are proving a big hit.

We’ve also been working on behind-the-scenes ideas for optikl and liptikl (some of which have fed-in to noatikl, including the scripting engine).

It is lovely to find that past users of our previous software creations (such as Koan Pro and miniMIXA) keep on discovering the intermorphic site, and start playing with our new software. Welcome back to you all!

Looking forward to another innovative and exciting year,

Pete

Reflections on the release of noatikl V1 and liptikl V1…

Well, it has been quite some year for Tim and me! The year of intermorphic. :)

Since our previous employer went down the pan, we’ve taken the opportunity to kick-off intermorphic, accepting the challenge we set ourselves to “do it all again, only better”. Its funny how life turns out, losing our jobs was the catalyst to “go for it” with intermorphic…

Looking back, we’ve taken on an almighty task. We’ve created two completely new products from scratch. They are cross-platform, Windows and Mac. We created them in double-quick time. They’re solid, good looking. Innovative. Different. And powerful! We’ve created a new site, with a fresh new style, written masses of documentation, and have even created a load of video tutorials. I think we’ve got a lot to be proud of.

Why did we create liptikl first? Well, this was partly because we thought it *could* be done and because I figured it’d be nice (ha!) to get started on something very new to us, and that we could cut our teeth on with the new development frameworks and design principles we’d adopted. I hope you can imagine how exciting it was for me when Tim sent me the first lyric he’d created with liptikl, I figured it was a verse from Shakespeare… and then he told me he’d created it in a few seconds with liptikl by mangling-together some words he’d found on the net :) . We knew we were really on to something, and once we’d got liptikl sorted we felt ready to start on noatikl…

noatikl was an unbelieveably challenging piece of software to create. We had the advantage of knowing exactly what we wanted to create, having learned our lessons in past lives (!) about exactly how users wanted a generative music tool to work and integrate with their own tools. But… that made it hugely daunting … how could a small company like us create such a thing totally from zilch, and include a standalone version, as well as a raft of plug-in variants, all focused on MIDI, and working wherever our users wanted within the vast range of Mac and Windows sequencers? Big challenge - the key was not to be daunted, but to start with the right tools (the exact same ones that we used for liptikl, we’d looked ahead very carefully!), and just plug-away without looking down off the tightrope. The past few months have been a blur, but here we are, we’ve done it and frankly it works beautifully, just like we wanted. Maybe even better! Our Beta users spotted very soon how solid the software was. Our decision to focus on pure MIDI was totally vindicated. The UI approach we’d adopted worked a treat. And with some massaging of the software, we suddenly integrated beautifully with Logic. Then with Cubase and Sonar. Bliss - it works!

Actually, getting noatikl working well with the various plug-in formats, and standalone mode, isn’t something I’d want to have to go through again :) but here we are, we’ve done it. The future now lets us focus on concentrating on the guts of noatikl and liptikl, making them as powerful and easy to use as possible, without our having to worrry any more about integration or cross-platform issues. And hopefully to bring-out new generative tools like optikl, where we can leverage yet more of the experience we’ve built-up.

A big “thank you” to our Beta testers to helping us find the way through the product development maze. An especially big thanks to Mark Harrop, who has been *immense*. Big ups too to Tim Didymus (generative music master!) and Ken Mistove for his top VSTi tips.

I can’t wait ’til you all start using the software, and hope you’re as excited as Tim and me to be at the start of what will be hopefully a huge generative tools success.

Have fun!

Pete

Getting Mac OS X 10.4.9 on to my old iMac G3 350...

I thought I'd save some of you time and tell you how I got Mac OS X 10.4.9 installed on my old iMac G3 350 (which we're using for testing noatikl and liptikl, as a low-end Mac platform).

The problem is that the old Mac only ran Mac OS 10.3.x, and I wanted to install Mac OS X 10.4.x ... and upgrade the memory and the hard drive.

However, Mac OS 10.4.x comes on a DVD, but this old Mac only has a slot-loading CD-ROM drive that cannot read the Mac OS install DVD! Also, the Mac has very little memory to start with (64 MB!) and, to crown it all, only had a puny 8 GB hard drive!

The steps I followed are given here. Note that you *could* instead return your DVD media to Apple and exchange for CD-ROM copy, but that would cost you around 10 pounds and that is money which would be better spent IMO towards a DVD-ROM drive that you can use from more than one computer. But that is just my opinion!

Shopping

1. Get yourself a larger replacement IDE drive! An old Mac like this can't read *really* big drives, so I got an 80 GB IDE/ATA drive for around 25 pounds from ebuyer.


2. Get yourself a USB-2 IDE/USB adaptor! I got mine for around ... guess what... 25 pounds from the local Maplin. We use this to connect to both our new hard drive (if you want to back-up your data via another Mac, for example) and the DVD-ROM drive.


3. Get yourself a basic ***INTERNAL*** IDE/ATA DVD-ROM drive! (Yes, INTERNAL!) I got mine for around 25 pounds from the local PC world, going relatively cheap. Internal drives are a lot cheaper than external drives, and I use the IDE/USB adaptor to connect this drive temporarily *externally* to the Mac via the USB/IDE adaptor (see later!)


4. Get yourself some more RAM! I got two 128 MB memory chips from a couple of old PCs, or you could buy what you need from e.g. crucial.com ...

Install the RAM upgrade

1. Take-out your old RAM, and upgrade it!


2. Verify your Mac reboots with the upgraded RAM!

Upgrade your Hard Disk

If you have a spare Mac with enough disk-space (!)

1. Take-out your old hard drive from your iMac. You'll find-out how to do this through google.


2. Plug-in your old drive Mac to the IDE/USB adaptor, to your other Mac...


3. Use the wonderful "Super-Duper" program to copy the contents of your old drive to space on your other Mac


4. Plug-in your new drive, formated it with a suitable partition using Disk Utility, and use SuperDuper to copy the backup data on to the new drive ... again, using the USB/IDE adaptor.


5. Plug-in your new drive back into your old Mac, and verify that it still boots up!


6. Plug-in the "internal" DVD drive to your old Mac, using the IDE/USB adaptor. :) It'll make sense when you try it. Insert your Mac OS DVD. Hold down the "option" key when rebooting as the start-up bong plays, and you will soon be given the option to boot-up from the DVD drive. Install Mac OS!

If you do NOT have a spare Mac...! ...

1. Take-out your old hard drive from your iMac. You'll find-out how to do this through google.


2. Plug-in your new drive back into your old Mac


3. Plug-in the DVD drive to your old Mac, using the IDE/USB adaptor. Insert your Mac OS DVD. Hold down the "option" key when booting as the start-up bong plays, and you will soon be given the option to boot-up from the DVD drive. Install Mac OS!


4. Turn-off your Mac. Plug-in your old drive to your Mac via the IDE/USB adaptor. Restart your Mac. You'll see the your old drive appear on the desktop as an icon. Copy-across whatever data you want to restore form your old Mac drive to your new Mac drive... being careful not to overwrite anything you shouldn't!

That is "all" there is to it! Don't blame me if this steps don't work! ;)

Good luck,

Pete

noatikl and Plug-in formats

Our biggest challenge with noatikl is that there are so many plug-in formats, each of which behaves differently on different platforms. noatikl is a MIDI-based generative music engine, and therefore needs to emit (and respond to) MIDI events. However, each sequencer requires a slightly different variant of plug-in!

Just as well that the Juce toolkit isolates us from a lot of this craziness!

Cubase SE - noatikl is deployed as a VSTi, or as a MIDI Effect written using the VST Module Architecture SDK. The output from this is fed-in to your favourite VSTi to render the MIDI events using the sounds you want.

Cakewalk Sonar Home Studio - noatikl is deployed as a VSTi, or as a MIDI Effect written using the DXi/MFX format. The output from this is fed-in to your favourite VSTi to render the MIDI events using the sounds you want.

Reaper - noatikl is deployed as a VSTi plugin, as Reaper does not support MIDI effects, but can instead route MIDI events generated from the noatikl VSTi plugin into other VSTi synthesizers.

Logic (for Mac) - now I know this might sound odd, but Logic simply doesn't support MIDI event generation by any Audio Unit plug-in. This is apparently addressed in Mac OS 10.5 ... Even the intent Sound System (that I wrote for the now-defunct Tao Group, as a fully-featured integrated audio platform for mobile phones running the intent platform) supported both MIDI and audio plug-ins. On mobile phones! So to use Logic with noatikl, you need to use the standalone version of noatikl and route the data via the IAC ports. This solution actually works very nicely, we've put some nice tutorial videos our our site showing how to do it.

intermorphic - creating a new family of tools

We've been very busy recently, starting to create a whole new range of tools for intermorphic...

Our site is http://www.intermorphic.com...

The biggest buzz is having a completely clean slate to dream-up a new set of tools that we'd really like to use ourselves!

The first one, liptikl, came out of a conversation I had with Tim, where he'd been complaining how difficult he finds to write lyrics for his songs. I said "Tim, you do realise that we could create a generative tool to help you do that?". After a furious round of prototyping and experimenation, we knew we were on to something!

The second one, noatikl, is a totally obvious one for us to do; a new generative music system for a world where the Koan Music Engine (created by Tim and me) is no longer available. With noatikl, we're starting again from a completely blank slate, focused on creating a range of generative music tools in plug-in form that can be used the desktop tool sequencers that everybody in music uses these days. Generative music is here to stay!

The third one, optikl, is something we've been aching to do for a very long time now, which is a very interesting (and entertaining!) light synthesizer...

One thing that is making this a whole lot easier than back in the days of SSEYO, is that we're writing all the user interfaces using the wonderful Juce application development framework. This lets us write an application GUI once, and then have them run on any supported platform simply by recompiling! Yes, all our new tools will run on a range of platforms including Windows XP/Vista and Mac OS X. And even Linux if we want!

Not only does Juce let us write cross-platform applications with a beautiful look-and-feel, but it lets us write them five times faster than any other toolkit we've used for either Mac or Windows. Not only that, but it lets us write cross-platform audio plug-ins using the same framework. And more: all of the user interface components that we create (like sliders and what have you) can be re-used across our entire tool range!

It is really liberating to have this opportunity to create a vibrant, exciting range of tools, using novel generative technology, in a cross-platform way with a totally up-to-date look and feel. Marvellous!

MacBook hard drive and memory upgrade

Boy, that was fun. Upgrading a Mac Book memory - and the hard drive - yech!

I wanted more memory so I can run the excellent Parallels Desktop for Mac, as well as play with various music tools on the Mac.

Yes folks, just the one, small Intel x86 MacBook with its awesome battery life, and running both Mac OS X and Windows XP at the same time, debugging code on both without any problems whatsoever. Apart, that is, from the strange keyboard mapping when in Windows XP on Mac OS (all sorts of keys useful for programming aren't mapped properly - which gets confusing!)...

Anyways, here are some upgrade tips:

Before you start, take a look at how to take the back off your Mac Book, through this video of taking the memory and hard drive out of your MacBook... excellent!

Before you start to install your memory upgrade (or the hard drive upgrade), you'll first need a Phillips No. 0 screwdriver. Don't bother even getting started without one of these! I upgraded the RAM in my MacBook from the measly 512KB (made up of two 256KB units ... why do Apple provide such a pathetically small amount of memory on a standard MacBook?) to the maximum 2GB (made up of two 1GB units).

If you want to upgrade the hard drive, you'll also need the right size of Torx screwdriver (get a set of the small ones!) or you won't be able to take the hard drive out of its mounting bracket (and fit the replacement into the bracket... before putting the thing back in!).

Oh, and the SuperDuper! software is fabulous/essential for first backing-up your hard drive. I found that I in addition to my new Seagate Momentus 120GB drive (to replace the Seagate Momentus 60GB that was pre-installed in the MacBook), I also needed a SATA to USB adaptor so that I could copy-across the data from the drive in the Mac to the new drive ... I got this one which seemed to do the trick. Oh, and as this was a MacBook upgrade, I was very careful to get a 2.5" SATA drive... and why don't Apple fit a bigger drive as standard so I didn't have to upgrade the drive in the first place?!

Basically, in order to do the upgrade, I first plugged the new drive into the SATA to USB adaptor, then plugged this into my Mac Book. I used SuperDuper to copy the data (after a couple of attempts... the first try hung-up!) from the hard disk in my MacBook to the new disk. Next, I restarted my Mac pressing Opt when restarting to give me the option of which drive to boot from (the internal one, or the newly copied external one). Note: the Opt key on my MacBook is the one between the ctrl key and the key with the Apple logo on it... why Opt isn't written on the key is a good question! Anyways, that allowed me to do a test boot from the external hard drive before replacing the internal one with the new drive.

Phew!!

I hope this info is of some use!

Sharing a Mac OS X external USB hard drive with Windows XP

I've been looking for a way to have easy-to-use add-on hard drive storage that could be shared easily across my home network between both Mac and Windows machines.

And the good news is that if, like me, you want to share your Mac OSX external USB Hard Drive with your Windows XP computer (and, for that matter, any other Macs on the network), it is pretty easy ... once you know what to do!

First, you need to get SharePoints and install it to your Mac. When you configure SharePoints, add your USB drive and give it a name like "My USB Drive". Remember to enable SMB file sharing (this is the Samba protocol that allows your PC to see the software; your other Macs can use it too).

Right, now that is done, how do you actually see the drive ? Easy!

Mac: Finder: Network ->; Workgroup -> (your Mac computer name) -> press the Connect button.

You'll be presented with this message "Select the SMB/CIFS shared volume you want to connect to". Select the one called "My USB Drive". You will need to enter your user name / password. An icon representing the drive then appears on your Mac desktop! You can drag this icon to your Trash to Disconnect the drive.

Windows XP: Windows Explorer -> My Network Places -> Entire Network -> Microsoft Windows Network -> Workgroup -> (your Mac name!) ->My USB Drive. You will need to enter your *Mac* user name / password. Sorted!

There you go, as easy as you like. Follow this advice and you should be able to get a cheap USB hard drive, plug it in to e.g. a Mac mini, and use that as a cheap, shared file storage device in your local network for e.g. backing-up photos (or code!) or as a common place for storing/streaming your MP3 files and what have you.

Certainly a lot cheaper than buying an AirPort Extreme with AirDisk!

Now, can somebody please tell me why the functionality in SharePoints isn't built-in to Mac OS X?

One more comment: I strongly recommend that you connect two USB drives, and configure them as a RAID array (in a RAID 1 mirrored configuration - see http://en.wikipedia.org/wiki/RAID for more information). This is really easy on a Mac, as it has software RAID built-in. Having such a RAID array has already saved my bacon once, when one of my cheap USB drives failed on me a few weeks ago. Have a look at the USB Floppy Disk Striped RAID for a fabulous example of how easy it is to build RAID arrays on any Mac!