We’ve dropped Loopy’s price for the holiday period!

Loopy HD, for iPad and iPhone, is 50% off at $3.99 (normally $7.99), and Loopy, for iPhone, is 30% off at $1.99 (normally $2.99).

Happy holidays!

Gift Loopy

Gift Loopy HD

The library, which is also the engine behind our popular live looper app Loopy, defines protocols for recording, playback, and audio output capture for easy inclusion with existing or new projects.

It’s designed to be really easy to work with, in order to get new audio projects off the ground quickly, and to dramatically cut down the iOS audio learning curve.

Find out more, download an evaluation version of the framework and a complete sample synth app here.

This dramatically simplifies the use of a circular buffer — you can use chunks of the buffer without any need to worry about where the wrap point is.

See the new implementation, which is thread-safe with one consumer and one producer, with no need for locks, making it perfect for use with high-priority Core Audio threads, on GitHub: TPCircularBuffer.

There’s a basic example of its use over on the original post.

I’m excited to announce the release of Loopy 2.2, and Loopy HD 1.1, which introduce features that the professional and semi-professional musicians are going to love: Trainable MIDI control, and MIDI clock sync!

Loopy can now be entirely controlled via external MIDI devices, via the Camera Connection Kit for iPad, or any one of a number of third party adapters for the iPhone and iPod Touch.

With Loopy, musicians can now accomplish the kind of setup that would otherwise cost hundreds of dollars in expensive, bulky specialised equipment to achieve.

Controllable actions include record toggle, mute toggle, record then automatically select next track, record then overdub, toggle record with no count-in/out, clear, re-record, solo, volume, pan, tempo adjust or tempo tap, pause, double or halve clock length…

The update also introduces MIDI clock sync: The clock can be synchronised, in either direction, with external devices, other software (such as Ableton Live) over WiFi, software running on other iOS devices via WiFi or Bluetooth, and even other compatible apps running on the same iOS device, via virtual MIDI!

Oh, yeah – one more thing: Loopy on the iPhone or iPod Touch can now run up to 12 channels. Yep. Layer it up, baby.

Loopy user and forum member fonyo recently wrote an article on the Loopy forum about busking with low-budget equipment and Loopy. There was some great information in the article, so I’ve reproduced it here with some editorial modifications.

I’ve been planning for a long time to do some busking. I’ve always been amazed by street musicians, and can watch them for hours. That’s why I’ve put together some thoughts on buying portable equipment.

In summary: For just a fraction more money than that saved by choosing Loopy instead of a single Boss RC-300 Loop Station, you can pick up a complete, high-quality busking setup, perfect for going out into the street and performing for the public.

Boss RC-300 vs Loopy

First, let me compare the new Boss RC-300 Loop Station with Loopy, not counting the iPhone’s/iPad’s price (because we love it and would buy it anyway!). I chose the RC-300 as it gives you the closest number of individual loop tracks you can record/overdub

My point is this: let’s forget the RC-300 and save that 400 quid for other stuff to buy so we can go out and play!

Equipment list

Here’s my equipment list. I tried to find a balance between price and quality, while also keeping in mind portability.

Let’s see the details of each. Loopy is obvious, it’s the “core” in our iDevice and the iKlip is holding it (e.g. on a mic stand).

iRig guitar & instrument interface is transferring the sound to the iDevice.

iRig MIDI to control Loopy through MIDI (I know it’s not capable of doing this yet but soon it will be!) and we connect a nice MIDI foot switch (cheap and smart) the Behringer FCB1010. This is the only thing which needs a power supply but I’m listing it as I would go for it anyway. I’m sure now that iRig MIDI and LINE6 Mobilizer II are released we will soon find many battery-operated or maybe even passive foot-switches for iDevices through MIDI.

I’m sorry to disappoint you, but an electric condenser mic like the iRig iMic just won’t give you a nice sound, and as the tests and reviews are showing it’s just not suited for professional use such as live quality street busking.

That’s why I came up with an idea of a small but powerful battery-operated mixer with enough inputs to handle your better quality microphones. You can also plug in your instruments or any device with line out, such as an iPod as a music source.

The mixer device is the Behringer XENYX 1002B which runs on two (!) 9VDC batteries. The main output of the mixer (your gig) goes into the iRig’s TRS input. As a nice optional hardware for electric guitars with pickups, I recommend the MOTU ZBOX. It’s a miracle for guitar sound, and it’s passive so it doesn’t require any current. The Behringer 1002B has 5mic-line input OR 2mic-line/6stereo input with 3bandEQ, 2aux etc.

Finally, the Public Address (PA). I’ve found real luggage-like battery powered speakers made by PylePro and those are just wicked! Low-budget but nice stuff. They have wheels and handle for easy relocating, EQ, and many other cool things built-in. They give you enough power to blow away your own head with guitar riffs, beatbox, singing, so you can just use Loopy to amaze your audience! The iRig’s output goes in the PylePro’s input, and there we are.

You do need to buy a mic, but this way nearly anything will sound better than that electric condenser.

Summary

For the money you avoided spending on a Boss RC-300 LS for £400 (vs. Loopy 2 HD for £5), you can pick up nearly all this equipment — the sum is between 400-550 depending on where and what you buy or not. Then, you’re good to go and show some real busking to the public and start a career like our Uncle Dub Fx!

You can discuss fonyo’s research at the Loopy forum.

Loopy 2.1.1 and Loopy HD 1.0.1 feature a number of bug fixes and iOS 5 compatibility fixes, as well as a few new features:

Configurable fade-in and fade-out

With this switched on, and with mute count-in/count-out enabled, the second tap on a playing or muted track will begin a fade in or out. A third tap will immediately play or mute the track. Without mute count-in/out, the first tap begins fade, the second plays or mutes immediately.

“Re-record” function

When clearing a track, this new function will cause the track to clear and begin recording again at the start of the next loop (or straight away, with count-in off)

“Chained mute” feature

If you mute a track (or tracks) while another track is counting in to record, then the muted track(s) will only mute after the recording ends, instead of at the next loop.

I hope you like the changes! Stay tuned for more.

Benjamin Poole’s creations with Loopy are beautifully whimsical, uplifting and sometimes melancholy tracks that feature second-hand and vintage toy instruments that Benjamin has found via Craigslist and through friends.

Judging by the quality of his work, I’d assumed that Benjamin was a professional musician experimenting with Loopy, but to my surprise, this is just his hobby: Benjamin’s a full time Communications major!

Benjamin can be found posting to SoundCloud as benjaminpoole.

Good Morning (Loopy Experiment) by benjaminpoole

You can hear what others are doing with Loopy at Loopy’s very active SoundClound group.

I bet I’m not the only one, but of course reality struck and we realised that the App Store aint that kind of beast. Like any other product, an app needs to be actively presented to the world on a regular basis, and needs to be nurtured to keep it fresh and relevant.

I say “we” because at this point, my partner Katherine joined me after this particular revelation, and became A Tasty Pixel’s part-time marketing director and PR strategist — it’s taken two of us to keep A Tasty Pixel’s wheels turning smoothly, and we still have a lot to learn.

I thought I’d take a moment to reflect on some of the lessons we’ve learned in the past year, in which we’ve released a relatively successful travel planning and travel assistant app, The Cartographer, a very successful live looping app, Loopy, and its big brother Loopy HD, and tried a bunch of promotion strategies, some successful, some not, and some that haven’t yet run their course.

Stating the obvious: It’s not enough to just build it

Just for the record, and I’m sure we all know this now, but “build it and they will come” doesn’t cut it on the App Store. Maybe it did in Month One, but now, you might as well not start if you’re not going to devote a goodly amount of time to promoting your app, because it just won’t get anywhere amongst the hoards of other apps.

Don’t expect everything to work

Perhaps the biggest, or at least most helpful, lesson we learned was not to expect everything to go as planned, and not to get too down if a strategy didn’t pan out.

It’s often impossible to predict which things will be successful and which not, but we found it helpful to consider the payoff for the successful strategies being spread around amongst all the strategies, successful or not — that way, we could be pleased about the ones that paid off, and philosophical about the ones that didn’t! The trick is just to keep at it, and keep being creative.

High quality attracts attention

Please excuse a moment of immodesty: I’d like to think my apps have a fairly high standard of quality, and it would appear that making “premium” apps really does pay off!

It’s not entirely “build it and they will come”, but having an app that looks great and that customers love gives you a big head-start in the PR game. Word of mouth is huge on the App Store, and the mouths in question produce more words about great apps.

What’s more, a feature by Apple, which generally only happens to high-quality apps, can make a massive difference, both in the short and long term, and gives an app a great “social proof” bump.

Incidentally, this goes for the app site too. Sites like App Sites reward beautiful designs, and you can get picked up on various design blogs too — we’ve had quite a bit of traffic lately from Blog Du Webdesign, for example. And the same goes for demo videos. The Cartographer’s demo got a huge response, and got a lot of word of mouth, just about the video itself:

So: Put in the extra sweat-and-tears. It’s worth it.

Influencers

Sometimes, depending on the nature of the app, a good word from an influencer in the area can be huge.

For example, when Loopy was in pre-release, I made contact with a musician I’m a big fan of, Dub Fx (you might know him from this video, which went viral a couple of years ago). Ben was very interested in the app, and threw his not inconsiderable support behind it, unleashing this amazing demo video:

…our jaws were dangling around our knees when I found that in my inbox! We’ve since decided to work together — look out for the Dub Fx app some time next year!

That was the success story — our experience with The Cartographer was quite different, though. Katherine spent months upon months getting to know travel bloggers, interacting on their blogs and via various social media, hoping to make connections and get to introduce the app to some of them.

The good news is that we made some really good new friends out of the process, which makes it all worthwhile as far as I’m concerned. But as a marketing strategy, it was a total bust. As it turns out, many travel bloggers seem to be quite unresponsive — some of them, despite lots of friendly comments and other interactions, never even noticed us! Some did, and kindly give us a mention on their blogs, but this didn’t seem to have any effect!

It turns out, as Katherine discovered in an industry report, the places that travellers (our target audience) go on the Internet: Not travel blogs! Travellers visit airline sites, hotel websites, TripAdvisor and forums, Lonely Planet’s forums…all places that we have no hope of exerting any influence at all (those forums, by the way, are militantly moderated for anything that even loosely resembles product mentions). So, we did the best we could, given the options, but it’s a really difficult market.

So, I suppose the lesson there is tread carefully, do your research, and spend the time strategically — be aware that the payoff might be huge, or it might be nil. If we’d known in advance how poorly the months of work Katherine put into meeting travel bloggers would turn out, we might have invested less time in it. We may have even decided to find an alternative target market.

Reviewers

There are a lot of app review sites out there, now. It’s just insane — it seems like every man, his dog, and several of his goldfish have app review blogs. Back at the start, Katherine put in a huge number of hours and built us a spreadsheet of the most important reviewers. With that done, whenever we do a release, she spends half a day (that’s how long it takes, or more!) emailing and filling out web forms of reviewers.

Most of them never respond, especially the big ones — they get such a barrage of review requests, it’s not hugely surprising. Many blogs offer paid reviews, but we haven’t gone down that track yet, so, nothing to report there. But many have responded, and every review helps, both for the social proof and word-of-mouth, and for the SEO.

Honestly, we haven’t yet collected hard stats about the proportion of reviewers who contact us in response to our initial contact, and how many are contacting us of their own accord. Many of the significant reviews we’ve had have happened independently of us tracking down and contacting the reviewers in question, though.

So, we’re still undecided about whether the amount of time invested in telling reviewers about our products is really paying off. I think we’ll always do it for initial releases, and possibly for major, major updates, though.

Journalists

This is something we want to do, but haven’t really pursued a whole lot — finding relevant journalists and contacting them directly. We’ve found contacts for a few, but they always seem to be out-of-date and emails just bounce.

So, this seems like a good thing to do, but still TBD.

Press releases

Press releases seem to have two main benefits — they help with SEO, which helps users find your app — and they marginally increase the likelihood of getting picked up and getting some free media.

We’ve been doing regular monthly press releases via PRWeb (a.k.a. Vocus) for a few months now, after previously only doing a big one (via PRWeb) for launch, and a couple smaller ones (via the much cheaper PRMac service) for updates.

Vocus talked us into signing up for a 12 month subscription (for a thousand-and-something $), which includes one release a month, and a representative who helps suggest topics, and checks over our drafts. Our representative Rebecca has been great with both, and has been very responsive with answering our dumb questions along the way.

We’ve been pseudo-picked up by a few nice sites like the San Francisco Chronicle, although it’s automated and I don’t know how much of a direct difference it actually makes. At the moment, loopyapp.com’s page rank is at 4, which is not bad at all, some of which is presumably thanks to our releases, and we seem to rank fairly well with most of the google searches we want to be associated with. An interesting side note is that quite a lot of our referred web traffic is coming straight from PRWeb, which surprised me.

As with a lot of these strategies, I can’t say for sure whether it’s been a huge success so far — it’s hard to determine the cause of a good page rank, for example — but my gut feeling is that it’s worthwhile; it makes sense.

Social media

I never “got” Facebook up until quite recently, but now I can’t get enough — after being a staunch Twitter user for quite a long time, I’ve discovered that Facebookers are amazingly engaged. I remember hearing somewhere that one Facebook follower (…”like”-r?) is worth several Twitter followers, and that rings true. I have a great time hanging around on the A Tasty Pixel Facebook page and interacting with people there, as opposed to Twitter, which is sometimes a little bit like shouting into a black hole.

Google+? I have no bleeding idea. Anyone?

Anyway, it’s important to engage with your customers on both, but particularly Facebook, and there’s lots of scope for interesting interactions with customers. For example, I’m about to start building effects into Loopy, and I was curious about what people most wanted to see. So, I created a poll on the Facebook page, and got a great response (“More Cowbell” coming right up…).

I quite like being able to “be me” on Twitter and Facebook, to show what I’m up to, get feedback on stuff as I’m making it, and to respond straight away to people. I get to present a personal face, instead of being A Company.

As Loopy is a music-creation app, it also hooks straight into SoundCloud, and has a very active SoundCloud group which I find myself trawling every morning — a great entertainment. One of the unexpected benefits is that I’ve met quite a few talented and lovely people though SoundCloud, some of whom have gone on to become testers and advisors, and help shape Loopy.

Customer support

While this isn’t promotion-related, I’ve been in the position (being a one-person dev company) to interact with customers directly, and I make a point of responding almost immediately when possible, and doing my best to address problems straight away. On a couple of occasions, the customer’s helped me identify a time-sensitive issue — they’re using The Cartographer and are about to go away on holiday — and I’ve had a fixed ad-hoc build out to them within a couple of hours, which has been very satisfying on both sides!

Customers love the straight-to-developer contact and the fast replies, and quite a few people have gone on to become very vocal supporters, which has been great. A very positive support experience goes a long way towards building goodwill, and I think it’s super-important. It also feels really satisfying, so in my option, there’s no reason not to go all-out!

Expertise

Tim Ferriss encourages product creators to position themselves as authorities in the area targeted by the product, to give the product more clout and attract more attention. The idea is, if your app is targeted at a particular area, and you have experience in that area, then write: write on your own blog, and seek out others to do guest posts on (make sure it links back to you!).

We’re spending a few years travelling in a motorhome around Europe as we set up A Tasty Pixel and Katherine’s art business, and The Cartographer was built as a result of our experiences travelling. So, (I say “so”, but actually we were already blogging as a journal for ourselves — but let us conveniently ignore that fact) we keep a travel blog, which brings in some traffic. But not much — honestly, this is a terrible example, and we’ve had very few results, possibly because of the nature (and diminutive size!) of our audience. Were we to focus on promoting our blog more and making it less “this-is-what-we-did” and more “this-is-what-you-can-do”, we might see more response, but our priorities lie decidedly elsewhere — traditional travel blogging: not our bag, baby.

But, I know this can work — I know it’s an extreme example, but look at Trey Ratcliff, the HDR photography authority, and his app 100 Cameras In 1. They got onto CNN, ferchrissake, and pretty much every other media outlet you can imagine!

Paid advertising

This is the next frontier, for us, and I’m fairly excited about it. Everything I’ve mentioned up to this point has been about “free media”, but advertising is a whole new category to explore.

With that said, I’ve had two initial forays into ads: Facebook, and AdMob, and both have been total failures.

To an advertiser, Facebook is like a giant damn candy shop. (I felt really weird when I read this recent Joy of Tech, and found myself drooling a little bit by the fifth panel…). The kind of targeting options available are just a-mazing — you can target people from their age, gender and location, right down to their areas of interest (which is insanely cool), and even down to targeting users who like one particular competitor’s product.

Despite the cool factor, it turned out to be pretty much a total bust for attempt 1 — we were paying a stupid amount per click, compared to the actual amount we would earn per sale. We spent $75, and got…45 clicks. That’s $1.60 per click, which represents about 75% of our actual take per sale, and it’s very unlikely even 10% of those clicks resulted in a sale.

At the time, I was choosing to bid per thousand clicks (CPM), instead of per click (CPC), but the reason I chose to was that the recommended CPC was well above what I was prepared to spend.

The lesson there is that Facebook users aren’t ready to buy straight away. A friend who works in advertising reported good results marketing the Facebook page instead of the product, so that users who are interested can hang around for a while, get to know you, and then you can market to them later. I’ll try this soon, and I’m hoping that the mechanics of a social ad (with a “Like” button on the ad, instead of a click to navigate away from the current page) will result in higher (and cheaper!) conversions.

I found similar results with AdMob — we got a much, much better cost per click (I was playing with the minimum bid of 29c per click), but even at 29c/click, in order to break even for our $2.99 app, 1 in 7 people who click the ad would have to buy it, which I think is far-fetched.

So, as far as direct advertising goes: As someone who earns just over $2 per sale, we just can’t afford it! My next experiment: Trying to use Facebook to increase our social reach, instead.

Summary

It’s become abundantly clear to us that app promotion is a job in itself, and it’s one that can scale right up to the amount of time you have available. They key is to be constantly creative, and to be out there, all the time, chipping away.

Almost everything’s a shot in the dark, and while many strategies may yield no results at all, some might be a big break (like meeting Dub Fx, for us), so it’s important to just keep on trying.

Apple give you absolutely no help in tracking the success of any particular strategy, unfortunately, although there are tricks you can use to help track where some of your sales are coming from.

The PR thing is just as important as actually creating the app; it’s hard, and it’s constant, and it means that running a software development company is anything but a “passive income”. Fortunately for me, I love it to bits!

I’m very pleased to announce that Loopy HD has arrived! A Tasty Pixel HQ has been a-buzz with activity these last few months, and we have a solid iPad live looper with top-notch features to show for it.

Loopy HD takes Loopy, doubles the number of tracks to fill up that big iPad display (6, 9 or 12 tracks), adds a beautiful big control panel with more session controls, and brings an even more polished audio engine and spot-on time accuracy.

We’ve got huge plans for this app and it’s just going to keep getting better. Right around the corner is MIDI support, so you can control the app with a pedal, and sync the tempo with other devices and other apps, over the network or even on the same device. Fun!

If you already own Loopy, Loopy HD will be on sale for $3.99 for a few days, so you don’t have to pay full price. We’ll also be giving away some promo codes from our Facebook page, so join us over there if you’re interested.

We’ve already given away some promo codes on our newsletter, but we do this from time to time, so subscribe if you’d like to nab one the next time.

Loopy has been updated too! Version 2.1 includes all of the improvements to the audio and timing engines from Loopy HD, as well as a smaller version of Loopy HD’s control panel. There’s a number of new features, as well, like count-in muting and unmuting, the ability to turn off track sync, and zip file support.

Thanks, Steve.

Loopy HD is on its way: It will be available on October 6. Stay tuned!

Three thousand reboots later, I decided enough was enough, and set about seeing if I could run a virtual machine with a small Linux installation which operated the card on behalf of my Mac, and shared the resulting Internet connection. It was a long learning curve, but I managed to get it all working quite satisfactorily, along with an Internet Sharing setup on my mac to share the connection onwards to other machines on the local network.

What’s more, the drivers I’m using under Linux — actually, they’re Windows XP drivers, running under the fantastic ndiswrapper utility — are brilliant, and I get much better signal strength, stability and throughput, to my great surprise.

If you’re in a similar situation, and either have a crappy driver to contend with, or no driver at all, or even just want a more solid firewall between you and the dangerous open WiFi world, here’re some instructions on how to get it set up, along with a virtual appliance I put together to make it all happen.

A warning in advance: This is Linux, so it aint for the faint of heart. If you’re not familiar with Linux, by all means give it a go, but be forewarned that if everything doesn’t work for you out-of-the-box, it is a steep learning curve.

The virtual appliance is set up by default to run the RTL8187 device using ndiswrapper, but the standard wireless drivers package is installed, and should automatically work with another adapter. If not, let me know and I might be able to assist.

Step 1: Download

First, download and install VirtualBox, the fantastic and totally free VM software. You’ll also want to grab the “VirtualBox 4.1.2 Oracle VM VirtualBox Extension Pack”, which brings USB 2.0 support.

Next, download the Microcore Router virtual appliance that I put together (it’s 45Mb). This is set up for use with Microcore Linux, and contains:

• Wireless device drivers
• Ndiswrapper
• The Windows XP version of the RTL8187 device driver
• iptables, with a script to set up IP masquerading
• dnsmasq, set up to provide a DHCP address to your Mac host
• Wireless-tools (iwconfig, etc), and WICD

Finally, download the Microcore live CD image (the virtual appliance was set up with Microcore 3.8.4 – if you wish to use newer versions, you’ll also need to update the extensions, but you’re on your own there.).

Step 2: Installation and Setup

Install VirtualBox, then double-click on the extension pack to install that. Then, double-click on the Microcore-Router.ova virtual appliance to import it.

Next, we need to create a virtual network interface to link the guest virtual machine, and your Mac. Open VirtualBox preferences, and click the “Network” tab. Click the “+” button to create a new host-only network, and enter the settings below (192.168.22.2, netmask 255.255.255.0). Click the “DHCP Server” tab and make sure it’s disabled, then click OK. This virtual interface is already selected for use within the VM’s settings.

Now attach the Microcore ISO to the virtual appliance by clicking the “Storage” section of the VirtualBox VM settings, then selecting the CD item underneath “IDE Controller”, selecting “Choose a virtual CD/DVD disk file…”, and choosing the Microcore ISO. This lets us boot the VM into Microcore.

Finally, if you’re using a USB network device, plug it in now. Attach the network device to the VM by opening the “Ports” (or “USB”) settings, then clicking the USB “+” symbol and selecting the device.

Note: I’ve already added the RTL8187 device to the VM setup, so if you’ve got one too, you shouldn’t have to do anything here.

Step 3: Boot VM

Now, you’re ready to boot. Close the settings window and hit “Start”. You should see the Microcore boot screen appear, with a prompt for boot options.

Type the following in, to make Microcore boot with the setup contained within the virtual appliance:

mc opt=sda1 restore=sda1

If you’re using an RTL8187 too, then you’ll want to blacklist the buggy Linux device driver here, so that ndiswrapper can run the device with the improved Windows drivers:

mc opt=sda1 restore=sda1 blacklist=rtl8187

Hit enter to start booting, and within a few seconds you should be faced with an empty screen and a prompt.

With a bit of luck, your network device has been detected and started up; type wicd-curses and hit enter to launch the WiFi control panel.

If you don’t see any networks here, and you expect to, then it could be that your network device hasn’t been picked up. Otherwise, breathe a sigh of relief and press on.

Step 4: Configure the Mac

Now that we’re booted and running the VM, we need to set up your Mac to access the internet via the VM’s connection.

Minimise the VM window — we’re done for now — and open up a Terminal window on your Mac. Ping 192.168.22.1, which is the VM’s configured address. Do you see ping replies? Then you’re almost there.

The final step is to make your Mac use the guest’s DHCP server, to obtain the correct settings. Type the following in Terminal to make it happen:

sudo ipconfig set vboxnet0 DHCP

To make sure it’s done the right thing, type ifconfig vboxnet0. You should see something like:

vboxnet0: flags=8843 mtu 1500
    ether 0a:00:27:00:00:00 
    inet 192.168.22.2 netmask 0xffffff00 broadcast 192.168.22.255
    inet 192.168.22.72 netmask 0xffffff00 broadcast 192.168.22.255

That is, the default address we specified when setting up the VirtualBox host adapter, and a new alias that has an address assigned by the DHCP server running within the VM. If you see this, then you should be good to go: Try opening up a web browser or pinging google.com.

If it’s working, then congratulations! Mission accomplished.

Optional Step 5: Internet Sharing

For bonus points, you can set up your Mac so that other computers on your network can share the connection. It’s not as simple as just starting up Internet Sharing from System Preferences, however, because System Preferences doesn’t know about the virtual network device we’re using.

Instead, we have to do it the old-fashioned manual way: Set up IP forwarding, NAT, and set up a DHCP server. I’ve created a service (loosely based upon Schley Stauffer Andrew Kutz’s akin service) that monitors the VM’s network state, and automatically does all this, sharing the VM’s connection via Ethernet and Wi-Fi.

Download the service resources here:

vmboxnat.zip

Extract, then go to the folder in Terminal and type:

sudo ./install

This will install to /usr/local/vmboxnat, and register the service with launchctl. This is a script which runs in the background and starts up internet sharing when the VM is detected, then stops it when the VM goes away.

If you open up Console now, you should see something like:

…au.id.tyson.michael.vmboxnat[13099]: Starting vmboxnat
…au.id.tyson.michael.vmboxnat[13099]: assigned DHCP address
…au.id.tyson.michael.vmboxnat[13099]: created alias interfaces
…au.id.tyson.michael.vmboxnat[13099]: enabled ip forwarding
…au.id.tyson.michael.vmboxnat[13099]: enabled natd
…au.id.tyson.michael.vmboxnat[13099]: established ipfw rules
…au.id.tyson.michael.vmboxnat[13099]: enabled bootpd

That means you’re all set.

Note that you’ll need to manually create an ad-hoc WiFi network, as we can’t automatically create a network the way the official Internet Sharing system does. Once you’ve created it, though, other hosts accessing that network should automatically receive an address via DHCP, and be good to go.

I’m doing some experiments with advertising my live looper app Loopy lately, and want a way to track the success of various approaches. It occurred to me that the totally freeform nature of the LinkShare “signature” field (which you can use to track traffic sources) lends itself to an even more flexible approach than that presented in the Mobile Orchard article.

Here’s a way to use that signature field to report the domain name of any referrer who links either to the app page, or to a download link (like, say, http://loopyapp.com/download).

This way, if, say, TUAW link to your app site, if someone clicks through then clicks the download link on your app site and buys, the resulting order will be reported as coming from TUAW. If someone clicks through from your Facebook page, it’ll come up as coming from Facebook. You can even modify the script further to report more precise details (like the path), if you like.

It assumes you’re using PHP, but the principle’s the same for any other language (BYO code, though ;-)).

Step 1: Sign up to LinkShare

First, if you haven’t already, Sign up to the LinkShare program — Once you’ve created a LinkShare account, join the Apple affiliate program via the “Programs” tab. After 3 days, you’ll get an email welcoming you to the program, and you’ll be good to go.

Step 2: Create a product link

Once you’re admitted to the program, open up the “My Advertisers” sub-tab from the LinkShare Programs tab, and open the “Link Maker Tool”. This lets you search for products, and create a link that will open up your app’s App Store page, and will be associated with your LinkShare account.

Step 3: Create a download redirection script

Now we’re going to set up a script on your app site which will redirect the visitor to the URL you just created (which in turn, redirects straight to the App Store page). It’ll add a “signature” parameter to the URL, which corresponds to the original referrer, so you can track where orders came from.

Create a file called ‘download.php’ in the root of your app site, with the following content, with your LinkShare URL inserted where indicated:

<?php
// Replace the following URL with the LinkShare URL you created
$linkshare_url = "http://click.linksynergy.com/fs-bin/stat?id=/yGrgMJzFG0&offerid=146261&type=3&subid=0&tmpid=1826&RD_PARM1=http%253A%252F%252Fitunes.apple.com%252Fapp%252Floopy%252Fid300257824%253Fmt%253D8%2526uo%253D4%2526partnerId%253D30";
 
session_start();
$referer = $_SESSION['original_referer'];
if ( !$referer ) $referer = $_SERVER["HTTP_REFERER"];
 
if ( $referer ) {
    $signature = preg_replace("@https?://(?:www\.)?([^/]+?)(?:\.com)?/.*@", "$1", $referer);
} else {
    $signature = preg_replace("@^(?:www\.)?(.+?)(?:\.com)?$@", "$1", $_SERVER["HTTP_HOST"]);
}
 
$signature = preg_replace("@[^a-zA-Z0-9]@", "", $signature);
 
header("Location: ".$linkshare_url."&u1=".$signature);
?>

This script looks for the original referrer in a session variable (which we’ll set up in the next step), so that the domain of the site that links to your app site is used, not just your app site’s domain. Then it creates a properly-formatted signature parameter (just alphanumeric), appends it to your LinkShare URL, and sends the viewer onwards.

Bonus points: I prefer to get rid of the ‘php’ extension to make the URL a bit cleaner. Pop the following into your .htaccess file to access ‘download.php’ as just ‘download’:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule . %{REQUEST_FILENAME}.php [L]
</IfModule>

Step 4: Remember the referrer

Now, on the landing page script for your app site (or the site header), pop this in at the very start:

<?php
session_start();
if ( !$_SESSION["original_referer"] ) $_SESSION["original_referer"] = $_SERVER["HTTP_REFERER"];
?>

This stores the original referrer URL in a session variable, to use when we actually link the viewer through to the App Store.

Step 5: Test it

To make sure everything’s working properly, open download.php again, and replace “header” at the bottom with “echo”, so that instead of redirecting the browser, we just print out the URL where we would be redirecting to.

Open your appsite/download URL, and make sure the URL ends with “&u1=appsite“. That’s for direct visitors. Now, click through to your app site from another site, then click your “download” link. You should now see the name of the original site you linked from as the “u1″ parameter at the end of the URL.

Once you’re satisfied that you’re good to go, make sure you replace “echo” with “header” again.

Step 6: Track

Now that you’re ready to track referrals, you can give out your http://yourappsite/download URL as your app’s direct iTunes download link (to reviewers, in your press releases, etc).

You can view a report showing clicks and orders associated with each referrer on the LinkShare page — create an advanced report by clicking the “Advanced Reports” sub-tab, then select your desired date range (I use “Since Last Payment”, and under “Report Type”, select “Signature Activity”. Hit “View Report”, and you’ll see your clicks and sales versus each referrer (“Member ID”, on the report).

Voila! Omnipotence achieved.

Addendum: This technique works for tracking referrers, but if you’re wanting to track the performance of ads (say, with AdMob), you’ll want to use your original LinkShare URL, with a custom “&u1″ signature parameter. As ad platforms like AdMob link directly (and don’t, as far as I know, send a referer parameter), this script won’t pick up that it’s from your ad platform.

Addendum 2: LinkShare’s reports don’t distinguish between products, so if you’ve multiple apps, you might want to add a prefix to your signature parameter to tell ‘em apart. You could, say, replace that header("Location: ".$linkshare_url."&u1=".$signature); line with something like header("Location: ".$linkshare_url."&u1=myapp".$signature);.

If you’ve been aware of the goings-on at camp A Tasty Pixel lately, you’ll be aware that Loopy HD is on its way.

This is the iPad-friendly version of Loopy, and it’ll be available on October 6.

In advance of the happy occasion, I thought I’d outline our Master Plan.

Once Loopy HD is out, there’ll be two versions of Loopy:

• Loopy will remain at its low $2.99 price point, and will remain iPhone only.
• Loopy HD will be available at a more iPad-esque price point, $7.99, and is targeted specifically at iPad users. However, Loopy HD will actually be a Universal app, so that iPad users can also use the app on their iPhone without having to purchase the app again.

Loopy HD will take advantage of that nice big screen, and will have a configurable number of tracks — 6, 9 or 12.

To cater for existing iPad owners who have already bought a copy of Loopy, Loopy HD will be available at a dramatically reduced price for launch, so you won’t have to pay full price — we’ll let you know via an in-app message from Loopy (and the usual channels) when it’s available.

Until then, I’m getting back to work!

• More Loopy HD news
• Watch the Loopy HD preview video
• Follow us on Facebook or Twitter for news and giveaways

Hands up, backing away

Disclaimer: I am not at all an expert in realtime programming, or Mach, or iOS-device optimisation, so this is pretty much a fumble in the dark. I won’t be at all offended if anyone wishes to shoot me down and offer a more sensible solution — in fact, please do! Until then, watch as I stumble on…

Also note that there are often ways to eliminate the need for precise timing of this nature, by architecting code appropriately — when it comes to audio, for example, CoreAudio provides a very accurate time base in render callbacks. For things like metronomes or audio synthesizers, it’s always better to establish a starting time, and use the difference between the current time and the starting time in order to determine state, rather than using a timer to advance the state. Still, sometimes, you just need a timer…

What the blazes?

So, I’m working on an update to Loopy, which uses a shared clock object to synchronise tracks and a variety of events (like user interface updates or timed track manipulations). A tester noted that the mute/unmute quantisation feature that I’ve recently implemented, which will mute or unmute a loop at its starting point (rather than whenever you tap it), tends to overshoot a little, resulting in a small part of the beginning of the loop being audible.

Of course, there are other solutions to this particular problem (like stopping or starting playback from the audio render callback, and using Core Audio’s timestamps for exact timing), but I use timers in other places outside Core Audio’s domain, which makes Core Audio’s timing mechanism unavailable, and I wanted to see how accurate I could get the timing.

Our friend, mach_wait_until

I read in several places mention of the Mach API utility mach_wait_until (from mach/mach_time.h), which is very low-level and supposedly fairly accurate. So, based on that lead, I put together an Objective-C singleton class that launches a high-priority thread, and uses said thread to schedule events.

An NSArray of events are maintained, and a scheduleAction:target:inTimeInterval: routine creates and adds events to this array, then pokes the thread.

The thread grabs the next event in sequence, then uses mach_wait_until to sleep until the time of the next event arrives, then performs the specified action on the target. It’s kinda a DIY NSRunLoop.

Here’s a comparison between this technique, and just using performSelector:withObject:afterDelay: (which schedules a timer on the NSRunLoop), observed while performing various scheduled events within Loopy running on my iPhone 4 with the debugger, and derived by comparing the time of event execution with the event’s scheduled time:

That was attempt number 1: This seems to give us about 11.4ms better accuracy on average (three times more accurate).

Not bad, but it turns out mach_wait_until isn’t really that accurate, particularly if there’s a bunch of other stuff going on in other threads.

Spinning, for fun and profit

For my second attempt, the thread performs a mach_wait_until until just before the event is due, then performs a spin lock until the time arrives, using mach_absolute_time to compare the current time with the target time.

This gave further improved results — here’s that table again, but with the new scheme added, with a few different spin lock times:

It appears that the more stuff there is going on in other threads, the more likely the mach_absolute_time call is to overshoot. So, the more time spent in the spin lock, the more leeway mach_absolute_time has to wait too long. Of course, that’s at the cost of making the CPU twiddle its thumbs for the duration.

Better than a punch in the knee

The results weren’t quite as fantastic as I’d hoped — still within the same order of magnitude, that’s for sure — but the average case for the 200ms spinlock approach is 14ms, or 5.8 times, more accurate than the traditional approach, and the minimum case is dramatically better.

You know, I think if I was aware of the results in advance, I might not bother, but I’ll stick with my hard-won 14ms now that I’m here (that’s 617 audio samples, I’ll have you know).

If anyone’s curious about the implementation (or wants to take a stab at doing better), here it is, along with a wildly simplistic commandline test app: TPPreciseTimer.zip

Now to get back to some real work.

Addendum: GCD follow-up

Chris in the comments below suggested trying a GCD-based approach, using dispatch_after. Curious, I rigged it up, and these are the stats, collected the same way as above, added to the prior table:

So, they appear pretty much the same as the NSRunLoop stats.