liscio

Yes, it's entirely my fault that the account has lapsed: I took a bit of a sabbatical for full-time grad school, and it was a very busy few years.

But how crazy is it that an email marketing company thinks it's a good idea not to inform users before an account is deleted? At the very least, you'd think they'd use it as a scare tactic to drive paying customers back to the product: "If you don't send a campaign in the next X days, we'll delete your account!"

Ugh. Say "no" to spec work: http://www.no-spec.com/about/

That is false.

RAM and HDDs in MacBook Pro machines are user-replaceable parts. No warranty is voided provided you install the proper stuff, and don't break your system in the process. I believe the manuals include detailed instructions for the replacements.

The RAM is _very_easily_ upgraded in an iMac. Apple's even designed a nifty door to make this process incredibly easy.

The only point of annoyance here is the HDD in an iMac. The design simply doesn't allow for the HDD to be accessed, and hence it's not user-installable. Personally, I'd never buy an iMac, and I very seldom recommend them.

I've always wanted to try Numpy for this purpose, but I get exposed to so much MATLAB code in research papers for DSP that it hardly seems worthwhile.

Furthermore, I've built an entire Objective-C math framework (https://bitbucket.org/liscio/smugmath) that operates very similarly to MATLAB (i.e. vector-oriented) and allows me to easily translate DSP algorithms found in research papers over to shipping products (http://capoapp.com, http://fuzzmeasure.com).

Boy do I love me some Octave.

I do all my DSP algorithm research in Octave, because the price of MATLAB is just too high. I think I'm looking at somewhere on the order of $4k for a single license to obtain the signal processing stuff that I need in addition to the core license.

Would I prefer to have more graphing options, and some assurance that researchers' MATLAB code will work out of the box? Of course!

That said, Octave gets me really close for a fraction of the price. Also, I can peek inside the Octave source and get an idea of how the underlying routines work.

You mean 10.5, right?

I've got a fairly large install base, and I'd like to keep them happy if at all possible. In the future, when I have to get them to buy a v2 release on the App Store, then ideally I've made a good impression on my customers and they'll happily buy a license.

It's also not that big a deal to do. As long as the developer tools continue to let me target 10.5 from 10.6, I'll be OK.

I think there's not much benefit of staying on Leopard if you run an Intel Mac these days. The upgrade cost is pretty cheap, and the benefits do developers are quite heavenly.

I've been keeping Leopard support in TapeDeck because it's been pretty easy to do so, but with the work I'm doing on 1.4 right now, I've been tempted to hit that kill switch...(But I won't.)

If they email you the .app, it will be locked down to the purchaser's machine.

In terms of Snow Leopard-only, that's not necessarily true. However, it will be Intel-only.

The version of TapeDeck I submitted to the App Store had to be stripped of the ppc binary in order to pass validation. However, the version on http://tapedeckapp.com (the demo) is ppc/intel and 10.5-friendly.

I've yet to have one of the "bad" problems with PayPal, but I'm always trying to stay a step ahead of them when I can.

For instance, if you're expecting a higher-than-normal sales volume (e.g. a launch day, version upgrade, promotion), it doesn't hurt to give their Merchant Services department a phone call (the number I was given was 866-837-1851).

Be sure you ask for Merchant Services if you're not connected to them by default—it's a whole other support organization from what I could gather on my last phone call with them a month or so ago.

They may be taken aback by the reason for your call, but you can go over your phone numbers and addresses with them to make sure they can get a hold of you in the event that a fraud trigger is hit. If they can't speak with you, they have no other choice but to shut you down until you call them.

You can also get them to put a note on your account about the expected volume increase, so that when the activity does go into review, it may not be such a harsh reaction (e.g. freezing withdrawals temporarily rather than totally shutting down incoming funds.)

For the price of their service, the wide range of things you can do with their APIs, and the support I've received thus far, there's not a whole lot left to complain about IMO. Maybe my tune will change if I experience some of the "trouble" you hear about online, but I think that the proactive approach I describe above may help prevent that from ever happening.

Poor battery life? My Magic Mouse would last 3 weeks of constant use with NiMH batteries on average.

However, this was only the case after I applied the software update for my aluminum bluetooth keyboard. The first few weeks with the mouse would get me only a few days worth of use, at best.

Maybe there's another bluetooth device nearby that's causing your Magic Mouse to work too hard, and suck up too much juice?

(Note: I don't use my Magic Mouse anymore because I've since fallen in love with the Magic Trackpad, which has survived even the most precise work with Photoshop for mocking up pixel-accurate UIs.)

Are all the features accessible in non-contract plans?

I've got a few contract-only perks here in Canada on Rogers, such as the 6GB data plan add-on for $30/mo, and an "Employee Purchase Program" discounted voice service at $17/mo.

I don't think you can get non-contract data plans for under $30, and that only buys you 250MB/month, and voice plans start at around $25-30/month.

I may be able to set up a similarly-priced plan up here, but I would lose out on many of the important features (tethering, visual voice mail, larger data caps, free evening/weekend calling, etc.)

It's hard for any company to try and work against the carrier-subsidized pricing of handsets. As long as carriers are supplying the access, this will continue to be the case.

To pay $500 for a phone, versus the $100 subsidized price, is a silly move—especially if you're planning to upgrade every 2-3 years.

I say this because the service from the carriers still costs the same regardless of how you obtained the handset, and in some cases you may be paying even _more_ for service if you don't have a contract.

(Of course, I'm speaking with the US/Canadian carriers in mind. I know things are better outside of North America.)

I think that the kind of folks who are _capable_ of building significant iOS based apps simply choose not to, instead of simply producing fart apps.

I avoided the platform for as long as I could. During that time: the tools improved, hardware and APIs have improved greatly, provisioning hardware got a lot easier, and the review process shortened significantly.

So now, I'm dipping my toes in and embarking on a fairly significant app. However, because I'm a long-time Mac developer, much of my existing code and experience moves over without much fuss—perhaps the developers of "signifiant" apps just have a different kind of "fart app"?

Rob's situation is fairly unique, and unfortunate. The whole ordeal is a load of BS, and I hope things change for the better for him. Briefs is a great idea, and it was easily the coolest iOS product demo at C4[3].

I can't speak for mmastrac, but in general Rogers devices roam onto AT&T as their first choice. I've noticed similar lameness in AT&T's network while traveling...

It's probably the algorithm in question that's to blame, in conjunction with the slow OpenCL implementation for the 8800GT, as you found.

On my machine (I'm the article's author), even Apple's GPU-tuned version of Galaxies runs much faster on the Mac Pro's CPUs than the GPU. So, something's up. I think only the GTX285 for the Mac Pro beats out the CPUs on that test, but I could be wrong...

The 1-2 seconds of overhead could also be contributed to by the compilation of the OpenCL program for the GPU, as I do a compile of the .cl kernel on each run of the program.

Furthermore, I wasn't very scientific about the GPU case, because I wasn't planning to ship a GPU-tuned algorithm. To actually pull this off for a consumer app is easier said than done.

For instance, I'd prefer not to ship the .cl kernel in the application, and would rather provide binary-compiled kernels. Doing this for >1 flavor of GPU is nontrivial, from what I gather, as I'd have to actually own the GPUs in question to get compiles for the different targets (I could only cover the GeForce 9400M, and 8800GT from my own collection of hardware).

That said, I still want to stay open to the idea in the future as I play around with the algorithm, and understand it further.

Thanks for the nudge, though. I really should dig deeper.

From the brief description on the site, it sounds possible.

Kernel support is not mandatory, as it only provides optimizations. So you're good there.

You will have to supply a build of the GCC compiler that supports blocks, and make it play nicely with Xcode (provided you're talking about end-user apps to take advantage of libdispatch). This shouldn't be too bad, but requires more Xcode-fu than the majority of Mac devs have.

The thing is, you should still use NSOperation for most multithreaded coding tasks in Snow Leopard, as it is now implemented using GCD underneath. You should only really monkey around with libdispatch calls directly if you're seeing performance problems with NSOperation (verified using profiling, of course).

I think the real benefit of this OSS project is going to be porting libdispatch to entirely different platforms (Linux, BSD, Windows, ...), and building NSOperation-like constructs in other languages/APIs to be used on many platforms (including the Mac, in the end).

Not always the case.

For example: Watson (http://www.karelia.com/watson/), was killed by Apple's Sherlock. Later, SandVox (http://www.karelia.com/sandvox/) was later followed up by Apple's iWeb. The list goes on...

Indie Mac developers have taken to calling this act, "Sherlocking". See a mainstream usage of the term here: http://blogs.zdnet.com/Apple/?p=1137

So, Apple swings both ways. :)

To me, I'd question the 'full suite' of Office that was supposedly included. Even when building through Dell, and packing in the OEM version, I'm pretty sure that alone adds $3-400 to the price.

That said, Office doesn't ship with Macs. I'm pretty sure that Macs don't even ship with the 30- or 60-day evaluation version these days.

I couldn't agree with you more. So many well-known sites are publishing terrible native apps for the iPhone which could have been much more effectively implemented by some CSS/js tweaks.

For instance, the PayPal app is utterly terrible, and gives only a fraction of the functionality you get from PayPal's full site. A few weeks, at most, could turn the PayPal site into an incredible custom iPhone web app.

And to add insult to injury, they don't even take advantage of the benefits that a native app gives you on the iPhone. For instance, they don't use the keychain to securely store login credentials so you don't have to re-login each time you launch the application (if the user requests it).

If I was worried about harsh comments, I wouldn't have started a thread, on the internet, looking for feedback. Anyway...

You bring up some interesting features—a few of which I have planned for future releases. I can't do it all in a 1.0 release, though. Someone with a "strong professional background" should be well aware that getting to a 1.0 is the toughest part of the battle.

I obviously plan to add far more functionality going forward, and you can rest assured that I have some amazing stuff up my sleeves.

Whether my customers perceive the application as a "Hello World" audio program (which I strongly disagree with, by the way) is a whole other story.

I don't think they care what's under the hood as long as it meets their needs, and does it better than anything else, and with ease. Many of the customers I've shown Capo to have never even known that time-pitch correction was possible, for instance. I can't fathom a user looking at my software and claiming, "Hey, I can code that in a weekend."

However, looking at any of the other solutions, I'm sure users would be intimidated. I want to bring this mature technology to a user base that isn't really interested in opening up a myriad of plugins and digging through complex UI.

No, these users want to be playing a song in iTunes, realize they should try and learn the song, and drag the song onto the Capo dock icon and start learning right away. That "simple" feature alone cost me about a month of off-and-on experimentation and hacking.

And, I was nice enough to share the solution to that problem on my blog for all to see, so that folks like you can make your "Hello World" solutions that much more quickly.

However, once you get to Capo's 1.0 state, I can assure you that you'll be far behind, eating my dust...

You really should download and use the free trial to decide for yourself. In fact, all the slow-downers on the market have free trials.

In Capo, you have all the functionality you need, with the limitation that after 5 minutes of audio pass through for a given song, audio quality will begin to degrade.

Learn a handful of songs with Capo, a handful with the others, and let me know (use the Feedback item in the Help menu) how it went!

Capo is selling to a market that includes folks who (and I'm included) would easily throw an extra $100 into a guitar because it has a nice rosewood back & sides versus mahogany.

That $100 isn't going to help you play any better. It'll make you sound different, but it isn't improving your ability to play. The same can be said for buying a $30 guitar strap, quick-release pins for $20, a pedal for $80, etc...

For $50 (as of July 1), Capo _will_ help you play better, and using it regularly will make you a better overall musician. So will the other tools, which also cost $50.

My reasoning is probably quite similar to why they're priced the way they are--it is a seriously helpful tool to those that need it, and it is worth the money.

Now, why do I think someone would choose Capo over the other tools? I think Capo is easier to use, more well-integrated with iTunes, performs very well, looks far better, and is generally more Mac-like (see point 1 below). Any one of these reasons would be a valid reason to choose Capo.

In some respects, one could argue that I should charge more than my competition based on those 'better' points (see Eric Sink's software pricing article, for instance). However, Capo is a 1.0 product, and I need to build Capo's reputation, and a large following of users.

I hope this answers your question (and helps others out there looking for more discussion about pricing their own products)!

(point 1) The other apps are cross-platform, and have some odd quirks. The UI isn't quite right in areas, the keyboard shortcuts are strange (to me, anyway), and behavior isn't always what I'd expect.

It's not difficult to detect all the notes via FFT, slightly more difficult to detect only bass notes (harmonics come into play), and quite a bit more difficult to pull useful chords out.

That said, my first Mac app, FuzzMeasure, is an audio analysis tool---so I know my way around the FFT/etc. Read into this comment however you please. ;)

I'm using the Apple-supplied time-pitch audio unit because:

(a) it has excellent audio quality (b) it's well-maintained (c) it performs well; and (d) I don't like to reinvent the wheel :)

Actually, I designed Capo for one-handed use. And, if you don't have a newer keyboard w/ the option key right beside the arrow keys, you can use pgdn/pgup to go between the markers, rather than opt-left and opt-right.

Thanks! John was very kind to have written such a glowing comment.

I think this comes down to really "living with the app for a while" to make that decision.

I've used other apps, including other 'slow-downers', and I really just couldn't find my footing in them. Some are horrid cross-platform apps with unfortunately chosen keystrokes, and pretty much all of them had terrible UIs.

After using them, I decided to write Capo. It was a need that, in my opinion, just wasn't being met.

I wrote an app that can run on your laptop, with your guitar on your lap, and you can control it very quickly and figure out a song with no fuss. I take guitar lessons weekly, and this app scratches my itch beautifully.

You don't have to visit deep menus, fancy settings panels, or anything out of the way to accomplish the main task which Capo does very well.

I hope this answers your question (albeit in a very wordy, roundabout way).

You subclass NSScroller, and get an awesome interface designer to draw the required art for the active/inactive states. :)

You can pick apart iPhoto '09 to get an idea of what bits you need, but I wouldn't advise stealing the art.

I've been a full-time indie Mac developer since Feb 2008, and this is the third product in my Mac products lineup.

It's not the same kind of 'startup' that you folks tend to talk about (not a hosted service, in the cloud, etc), but it's what I do for a living.

Questions about the business, the tech, the features, etc.? I'll gladly answer them here.

I'll second the python challenge. Unlike Project Euler, this challenge required the participant to rely on finding and using some python libraries (for imaging, networking, compression, etc.) to solve the puzzles. So, not only are you researching the language to figure it out, but you're actively engaged in self-directed research to find out how to complete real tasks with python.

I've also read the "Dive Into Python" book, but that was equivalent to reading a book about an instrument without actually holding or playing one.