Posts Tagged ‘iPhone’

Music :: Logic + Github

logic+github

 

This morning, I discovered a cached of sketch recordings from my phone that I haven’t yet reviewed. The list contained over 4 years worth of material, which gives some indication as to how good of a job recording this stuff I’ve done lately / in the last couple of years. Anyway, to spur myself on to actually start fleshing this stuff out, I decided to (very sketchily, just using the mic on my MacBook) record them one by one into new Logic projects – a format much more conducive to actually working on them in the future than random, hidden snippets of audio on my phone.

In an interesting twist, I’ve made each project into a Git repository that’s sync’d up to my GitHub account – you can find it here. I did 6 out of a total 106 this morning, so the whole process might take some time, but once I’m done, I think that taking a ‘software development’ approach to creating music might be quite an interesting way to work. And I, or anyone else, for that matter, can check up on how well I’m doing during the whole process. Cool!

 

iPhone 4S Camera :: 1981 MESA/Boogie Mark IIB

It struck me while I was playing today how awesome the Mark II looks, sitting on top of a 1×12 EV loaded extension cab and pumping out just the best tone. This thing really delivers. Anyway, as I’ve had the 4S for a couple of weeks now I decided to have a go at taking some more decent pictures of the Boogie. Bottom line: I’m really starting to enjoy the camera on this phone.

The parallels between MESA/Boogie and Apple are pretty clear to me – the beautiful hardware, the build quality and unparalleled functionality. While I’m certain I won’t be using the 4S in 30 years time, at this moment in time is seems like a nice pairing of camera and subject.

More pictures below

(more…)

Step Back From the Mainboard

Great consumer technology is a pretty complicated thing to pull off. Building something great needs a rock solid technological foundation with a beautiful and intuitive user interface.

Working solo on a project puts you in control of both of these processes. The obvious hurdle to overcome is for one person to possess a decent level of skill in both disciplines. But I don’t think this is the biggest issue. As a primarily technical person, I find it all too tempting to go right for the engineering challenge and tack a UI on later. When it comes to design, technical considerations are constantly dictating my design choices and the product ends up crappy.

It’s a new kind of discipline and level of mental agility to look back and forth between the outward facing interface and the code under the hood, but that’s what’s required to step back from the parts and start designing an experience. And it’s a challenging leap to make.

[image via Seattle Times]

Reading List :: Wednesday 19th October 2011

I’m in the middle of a big (final, major) software project at the moment which has prevented me from posting any longer bits to the site in a few weeks. This project isn’t going anywhere – as in, I’m definitely going to be working on it for the next few months…it’s progressing, but it’s also big – so in order to keep the site ticking over I’m going to start a semi-regular ‘Reading List’. If there’s anything insanely great that pops up in my morning reading session – guitars, code, consumer electronics, whatever – it’ll get featured on the list. Simple!

This morning has been pretty much dominated by coverage of the joint Google/Samsung press conference which, having been held in Hong Kong, took place at strange o’clock in Europe and the US. Oh, and Motorola (Google?!?) also had an event and announced the coolest Android phone in the world for all of about, oh, half an hour. Rather than any of the ‘news’, which in Android-land is ridiculously ephemeral and kind of difficult to get excited about most of the time, the most interesting article I found was Joshua Topolsky’s interview with Matias Duarte, the Danger/webOS UI designer who has been tasked with classing up Android and who’s first wide release of the OS (I’m not counting Honeycomb) will be the stupidly named but intriguing Ice Cream Sandwich. I full on dig this guy’s attention to detail, and his shots at the faux-wood/leather/etc are so, so justified – even Gruber said so. Google should give him carte blanche; he’s totally got what they’ve been missing.

I’ll be downloading the Android 4.0 SDK for a play at some stage – I’m an iOS developer, but like so many I learned the ropes on Java…so the only thing stopping me from writing for Android is the godawful SDK. And Eclipse. Hopefully this one will bring parity with Xcode, but I’m not holding my breath.

This is actually from yesterday, but is very creative, very cool and very creepy indeed. Nothing we didn’t know already (what, Facebook has loads of my data? Whoa!), but man, what a visceral way to present it. Just remember to delete it from your applications after use.

Lastly, Forbes’ profile of Dropbox. I love Dropbox, but interesting that Jobs told them he’d crush them with iCloud – I’ve already got it synching my MacBook Pro and iMac, and will add my iPhone 4S when it arrives later. iCloud has already obviated two of my regular cross-machine sync solutions, might Dropbox be next?

Solving the MBProgressHud _WebTryThreadLock Error

MBProgressHud is a really nice bit of plug in code to add fancy status and loading notifications to your iOS app quickly and easily. It looks great! Unfortunately, there’s an irritating error which cost me some time this morning, and hopefully I can save anyone else in the same position some trouble.

The error:

bool _WebTryThreadLock(bool), 0x7b9b5500: Tried to obtain the web lock from a thread other than the main thread or the web thread. This may be a result of calling to UIKit from a secondary thread. Crashing now...

This appears when a method which needs to update a UI component is called directly by the MBProgressHUD object.

The most basic usage of MBProgressHUD is thus:

HUD = [[MBProgressHUD alloc] initWithView:self.view];
[self.view addSubview:HUD];
HUD.delegate = self;
[HUD showWhileExecuting:@selector(fetchNewData) onTarget:self withObject:nil animated:YES];

In which ‘fetchNewData’ is the method which is executed while the progress HUD is on display.

Using this technique, fetchNewData will be called on a secondary thread, which causes the crash error we’ve already experienced. UIKit, which handles all the user interface business, should only be running on the main thread, so when the secondary thread makes a move on a particular UI element, its going to throw the ‘web lock from a thread…’ error. (It should be noticed that you can update some UI components using the standard MBProgressHUD setup detailed above, but in most cases you’ll get the error.)

In the case of this example, ‘fetchNewData’ updates part of the UI, so it needs to be called on the main thread. The quick and dirty workaround I used to force it to execute where I wanted it to was to create an intermediary method which can be called by MBProgressHUD as normal but in turn calls ‘fetchNewData’ specifically on the main thread.

You could, for example, call this method ‘performFetchOnMainThread’:

-(void) performFetchOnMainThread    {
[self performSelectorOnMainThread:@selector(fetchNewData) withObject:nil waitUntilDone:YES];
}

Instead of directly calling ‘fetchNewData’ from MBProgressHUD, use it to execute ‘performFetchOnMainThread’, which uses the ‘performSelectorOnMainThread’ method to force ‘fetchNewData’ to be executed on the main thread.

This isn’t the most efficient or beautiful way to accomplish this, but it works, so if you’re getting a ‘web lock from a thread…’ error and you need to make sure your code is executed on the main thread, you can use this technique to get the job done quickly.

Colorshare – Available in the App Store

Hot off the presses and approved by Apple mere moments ago, colorshare will become available in regional iPhone App Stores the world over over the next 48 hours or so.

Colorshare is a simple utility which allows you to quickly design a palette of colours on your iPhone or iPod Touch and with the tap of a button share it with the web using the unique palette ID number, which you can punch right into the colorshareapp.com homepage.

Once you’ve entered the ID of the palette you want to work with, it will appear on screen alone with a full breakdown of each colour in RGB, hexadecimal and CMYK.

Colorshare is completely free, and you can grab it from the App Store by following this link.

Apple ’97 & RIM ’11: Round 2

A few days ago I published this post after watching Steve Jobs’ Q&A session on the final day of WWDC ’97. What struck me about the footage was how much the 1997 Apple shared with Research in Motion today, particularly their ineffective leadership, incoherent platform strategy and confused developers.

Apparently I wasn’t the only one who thought this: earlier today, Boy Genius Report published an open letter from an anonymous RIM executive to the company’s senior management team highlighting his/her frustrations with the way the company was being run, including an 8-point list of suggestions to rectify the highlighted issues. Point three on this list, entitled ‘Cut projects to the bone’, is rounded off thus:

Look at Apple in 1997 for tips here. I really want you to watch this video because it has never been more relevant. 

To hear somebody at a ‘high level’ within the company (verified by BGR) making these connections is hopeful for RIM. In 1997, Apple was blighted from the inside by ‘good engineers who were bad managers’, only able to create products from a technical perspective and with little regard for user experience or consumer relevance. When Jobs returned to the company and sought effective change to right the sinking ship of Apple (first puppeteering then-CEO Gil Amelio and then as CEO outright) he did so by doing exactly what the anonymous exec prescribes in their letter: ‘Cut[ting] projects to the bone’. RIM’s inability to ‘kill their babies’ is costing them dear.

The comparison of RIM to the 1997 Apple is actually not as disadvantageous a position to be cast in as it may first appear. There are two reasons for this:

As evidenced in this open letter, there are executives at the company who are open to outside reason and influence, who just want the best for the company, who hate to see it suffer and want to restore it to past glory. The anonymous author of the letter may not have the gravity of Jobs, but they are not alone:

I know I am not alone — the sentiment is widespread and it includes people within your own teams.

Again, this is great for RIM if it is indeed true, and it sounds perfectly plausible that a widespread sentiment of lost confidence and disillusionment might be prevalent at the company right now. In numbers, this voice of reason may grow loud enough to be heard.

Secondly, and to further RIM’s advantage, is that 1997 was 14 years ago. That’s 14 years of turnaround strategy, platform change and growth, alterations to business models and more upon which to draw. Even if the company was faltering for other reasons, they could do far worse than to study the changes made by Jobs and his team when they returned to Apple. The plain similarities between the problems of RIM ’11 and Apple ’97 make it almost a cut-and-paste job in some cases (sending clear messages to your developers, for example).

However RIM chooses to proceed, the opportunity to enact the ruthless and effective change in the company encouraged by the open letter is likely not one that they will apparently be ‘aggressively addressing’ according to the reply posted on their corporate blog earlier today. Right now, the company seems too preoccupied and defensive to take the effective action it desperately needs to: it seems that the program of self-protective corporate blog posts, meaningless shareholder appeasement programs and public CEO-meltdowns is set to continue.

On Apple and RIM – WWDC ’97 Steve Jobs Q&A

 

This video has been doing the rounds on the internet since John Gruber posted it to Daring Fireball a few days ago, and whatever your thoughts on the present day Apple it’s a remarkable and insightful piece of footage which has profound resonance in the context of today’s industry.

At the time of filming, Gil Amelio was still CEO of Apple and Jobs had returned as a ‘Special Advisor’ after the purchase of NeXT. Rather than taking the keynote speech on the opening day of the developer conference, Jobs rounds off the week with an open Q&A for attendees, with topics ranging from marketing strategy to graphical development software and his personal choice in PDA.

There’s some very amusing moments – Jobs discussing how much he enjoys working with Gil Amelio when a matter of weeks later he led a boardroom coup that sent the CEO marching, and an early appearance of ‘work[ing] their butts off’, made famous by the 2010 Antennagate ruckus – but of particular significance are the prescient technological and business strategy allusions. Ten years later at the same event, Jobs unveiled the iPhone, but in 1997 he was already envisioning a portable device with a constant connection to the internet and email. It may have lost the keyboard in the intervening decade, but the nascent concept of the iPhone was already formed even before Jobs became CEO.

Accompanying the iPhone on its stratospheric rise to success over the past four years has been the App Store, and in 1997 mention is even made of the importance of creating a cheap and easy means for developers to get their software into the market place. On iOS (and now the Macintosh), the App Store is the fruit of this vision, and 10,000,000,000 downloads later it’s clear that it was a good one.

While there’s a certain amount of geeky nostalgia to be enjoyed (and laughs to be had) watching relatively vintage clips like this one with the benefit of hindsight, there is also a great deal of business sense on show here which is still of great relevance today. One question from an audience member regarding Jobs’ thoughts on the Newton MessagePad yields an answer which the co-CEOs of RIM would be wise to listen carefully to.

At the time, Apple was building a next-generation operating system (Rhapsody, see my articles here and here) based on the Unix-derived NeXTSTEP. While this platform was in development, the classic Mac OS also required maintenance and improvement to sate the requirements of the existing install base. In addition to these two desktop software platforms, the line of Newton MessagePad PDA devices was a third, fully independent platform which itself required the same maintenance and enhancement efforts as the desktop Mac OS. With the company cash-poor, developing and maintaining three simultaneous software platforms was a dangerous strategy – the future success of the company required a new, great operating system, which a development team stretched thin and on a shoestring budget simply would not be capable of producing.

Today, Research in Motion has an almost identical problem – two existing platforms and one in development – yet seem to be rushing head forwards (eyes closed) into this demonstrably dangerous OS strategy. The existing line of BlackBerry smartphones runs on version 6 of their operating system, however while the OS is soon to be updated to version 7.0, software written for the new version will not be compatible with the old, and existing handsets will not be upgradeable. Similarly, compatibility between existing software and the new platform is not guaranteed.

In addition to their two largely incompatible smartphone platforms, RIM has a third OS, currently in the market running on their PlayBook tablet and based on the QNX operating system, which is destined to eventually replace (the as-yet unreleased) BlackBerry OS 7.0. As with Apple ’97, the company seems unable to stick to just one or two definitive, coherent ecosystems with clear, logical development guidelines. Instead, they opt to simultaneously operate multiple weaker operating systems and a non-cohesive, bewildering array of software development options. As Jobs said, some companies can’t even handle one platform properly, and RIM is proving that three times over.

One thing that is conclusively proved about Apple’s growing success over the past 15 years is that planning, vision and clear thinking rules. In the face of crowd protestations over the cancellation of OpenDoc, Jobs coolly explains it purely as a business decision to cease a project conceived by ‘good engineers who were bad managers’. The notion that development should be consumer- rather than technology-facing is extolled here, yet 15 years later it seems that the lessons of the past have not been learned by some.

OpenDoc, Newton and the Macintosh clone market were all casualties of Steve Jobs’ business process upon his return to Apple, but those were other people’s ideas on the chopping block. The real testament to Jobs’ ruthless methods is his willingness to scrap his own projects. In their quest for perfection, design students are reminded at every stage of their training that the most important thing to be able to do is ‘kill your babies’, something apparently missing from computer science degrees. Steve Jobs’ and Apple’s mastery of this principle is exemplified by their brutal treatment of MobileMe recently, but it’s their ability to make these decisions and enact necessary change which continue set them apart from the competition.

BRB – Glastonbury Festival 2011

For the next week or so I’ll be camping in the middle of a hopefully dry field, soaking up music, vibes and possibly even sunshine at the world famous Glastonbury Festival.

Of course, for the less committed geek this would spell disaster – a whole week without my MacBook?…without Wi-Fi?…outdoors?

Luckily, my party this year are all smartphone addicts (three parts iPhone, one part BlackBerry), and we’re going to be sharing a Shenzhen-special battery-powered USB charging station. This means I’ll be Tweeting, Instagramming, WordPressing and generally getting as far from the party spirit as possible over glorious 3G for the whole week. I’m also taking equipment for making fresh coffee.

The trip is going to be equal parts 2011 and Glastonbury for me, and while I’m pretty sure VMWare don’t have a tent, it’s not going to be totally disconnected. [Prays for sunshine…and signal]

iPhone 3G Crashed During Restore [Unbricked]

I was restoring my iPhone 3G (iOS 4.2.1) on my Mac when iTunes suddenly and unexpectedly quit. All I was left with on the screen was the Apple logo and a static progress bar. The thing wouldn’t even power off at all (I had to open it and disconnect all the ribbons from the logic board to cut the power) and the ‘helpful solutions’ from the internet all seem to revolve around Jailbreaking, which I’m not into.

Opening Console.app, I noticed an easter egg error message:

Jun 11 12:04:35 imac iTunesHelper[489]: _MobileDeviceConnect_locked (thread 0x7fff706eaca0): This is not the droid you're looking for (is actually com.apple.mobile.restored). Move along, move along.

Funny, but pretty jarring considering my phone was broken. There was very little information about this particular console log entry online, but it seemed to point to the device being locked in a semi-restored limbo.

I even tried using Jailbreak tools – for Macintosh and Windows – to force the thing into recovery mode. No avail.

Anyway, to cut a long story short, the way I managed to get the thing working again:

– Open up your phone (ifixit has great guides)

– Disconnect all the ribbon cables from the mainboard

– Leave the phone for a few hours

I left the stripped down phone on my desk, went shopping for two or thee hours and plugged it in on my return. To my amazement, I was given the ‘Connect to iTunes’ screen. iTunes initially recognised the phone was in recovery mode and offered to install the latest firmware. I accepted, and it downloaded and attempted to install. However, I was informed that the device was ‘Not Eligible’ for the file downloaded. The iPhone then – astonishingly – rebooted straight into iOS, with all of my old files, contacts and apps present.

While this might not be completely scientific, I encourage anyone with a ‘bricked’ 3G to persevere. Try disconnecting everything from the logic board – it worked for me. Bizarre.