So many things to do! Life as an indie developer can be a bit chaotic sometimes, and the last two weeks have been no exception – I’ve been busy with some urgent-ish tasks, which have taken time away from Masterpiece development. Let me tell you them.
No video this week, folks: I’ve decided to take a week or two to sort out a long-overdue Loopy update. It’s gonna sort out a few issues, include the improved clock sync stuff from the new Spectacular Sync Engine, and one or two other new things.
Read MoreI’m still working on The Spectacular Sync Engine this week, and talking about what’s involved in making a stable MIDI clock receiver. Hopefully it’s not all gibberish (I don’t even see the code – just blonde, brunette…).
Developers, if you want to stay informed about The Spectacular Sync Engine: http://thespectacularsyncengine.com
Read MoreI’m on a bit of a tangent this week, developing an open source MIDI clock implementation.
http://thespectacularsyncengine.com
Read MoreHappy New Year!
Hey folks – well, no post today, I’m afraid! To be perfectly honest, I’ve been playing Call Of Duty. Feels weird to be doing much work stuff at this time of year!
Anyway: Happy New Year, and I’ll speak to you in 2015.
Read MoreJust a short one this week (I’ve been Audiobussing/Xmassing), but I want to ask you about what annoys you right now in music tech.
Read MoreI’m trying something new this week: I’ve been designing Loopy’s code modules, and this week I’m talking about how I plan to implement the actions/sequence stuff we’ve been talking about in past weeks.
It’s gonna get a little technical – quite the learning curve for me, figuring out how to talk about software development!
Read MoreObjective-C, or Swift?
I’ve been pondering what language to use to write Masterpiece, and have been vacillating back and forth over the last few days.
Swift is the future!
Swift – Apple’s fancy new programming language destined to replace Objective-C – is designed to make some of the more heinous errors one can make with Objective-C totally impossible. That’s very, very nice, and with the clear message from Apple that this is the future of iOS/Mac development, it seems to make sense to start any new projects in Swift, rather than the decades-old Objective-C.
So: Swift is the natural choice, right?
Hold up. Swift is still very young.
But – and this is a massive “but” – Swift is very new, and although Apple report they’ve been using it to make their own products, I contend it’s as-yet largely untested. Reports of bugs in the developer tools, including nonsensical error messages, crashes and assorted other compiler and editor bugs abound. Just a quick search turns up all kinds of problems:
- http://footle.org/2014/11/04/misleading-swift-compiler-errors/
- https://twitter.com/SteveStreza/status/542830670301515776
- https://twitter.com/jnpdx/status/542493939152859138
- https://twitter.com/tewha/status/542150178476548097
- https://twitter.com/hyperjeff/status/542096016762494976
- https://twitter.com/DamienPetrilli/status/541964343420944384
- http://stackoverflow.com/questions/27371000/xcode6-swift-type-inference-bug
- https://discussions.apple.com/thread/6526114?start=0&tstart=0
- http://finalize.com/2014/10/08/xcode-simulator-bug-with-swift-to-objective-c-call-passing-cmtime-structure/
Good god! No doubt these problems will sort themselves out over the next years, but who wants to be the guinea-pig responsible for finding and reporting them?
Not me. I wanna make stuff.
There’s one other big factor that I think has settled the matter in Objective-C’s favour, once and for all.
Swift and realtime audio is going to be hard.
I’m writing an audio app, and a pretty damn complex one. See, when you’re writing code for realtime audio, it’s absolutely critical you write code that’s fast, doesn’t allocate or release memory, and doesn’t wait on any locks. If you don’t get that right, you open yourself up to the risk of a nasty little thing called priority inversion which, with audio, means glitches because your code can’t provide audio fast enough to the hardware.
At the heart of the Objective-C runtime is all kinds of stuff that can’t take place on an audio thread without risking glitches: locks, memory allocations and the like. That means you really shouldn’t write audio code in Objective-C, but should drop down to plain C where it’s safe.
And you know what? The same thing almost certainly goes for Swift. At the very least, it’s untried and totally undocumented, which isn’t a good sign.
But the lovely thing about Objective-C, is that you can write C code right alongside Objective-C code, and directly access properties of Objective-C classes, with no additional cost. As far as I can tell, that’s really, really messy to do in Swift.
So, that’s that. Objective-C it is.
Read More