FMSynth v0.1: Making Mac OS X Applications Distributable

fmsynth0.1Off an on I’ve been working on an FM synthesizer.  Today I finally hooked up an ugly UI so I can at least pass it around.  Since I wanted to pass this app bundle around and I was using portaudio as a dynamic library I had to do some magic to make the application distributable.  If you run xcodebuild then just hand off the app bundle to someone the app will crash at launch when the dynamic libraries are loaded.  The built app has by default an absolute path to wherever your dynamic library is stored.  You can check this by running “otool -L <executable path>” to see what dynamic libraries your executable is referencing.

At any rate, here is the script I wrote to make my app bundles distributable:

After you do something similar if you run “otool -L” everything should look sane.

Here is a link to an early release to the fm synthesizer.  You can play it with your keyboard.  There are tons of things that don’t work yet, like saving patches and the decay and sustain elements of the envelopes, but have fun anyways.  Maybe I’ll get around to posting more about how it works: FMSynth 0.1

Emacs Lisp Script to Replace Decimal Number with Hexadecimal

 

Removing Push Notifications from iOS Apps

The developers at my company were recently tasked with removing push notifications from an iOS app.  We ran through push notification tutorials in reverse, removing anything that got mentioned, but still we would be asked for permissions for push notifications on app launch.  We were unable to duplicate the ask for permissions when building to device from Xcode so we were left building ad-hoc distributions, and you had to reset the device each time you installed the IPA.  On top of that our app is a media heavy app that has half a gig of resources, so we were wasting alot of time building ad-hoc builds.

We spent alot of time fiddling with provisioning profiles since we already searched the binary’s symbols looking for any reference to anything push notifications related and we were pretty confident the changes weren’t in the code.  Eventually we had to just start ripping the app apart, removing bit by bit until the notification didn’t show up.  The culprit was finally found, it was a call to -[UIApplication setApplicationIconBadgeNumber:].  I have no idea what this is, apparently it is related to push notifications.  I never setup the push notifications so I had no idea to look here.

This was an unfortunate perfect storm of compounding complications arising from developing for a close embedded system… sad sad sad.

Design Code Better With Inferior Version Control

machupichuwallNew tools come out for software development all the time, usually they do more good collectively for productivity than not, but sometimes the limitations of the past had their hidden gems as well.  Our industry is obsessed with the latest greatest thing, I’m not a curmudgeon that’s going to badmouth everything that came out since 1990, but like everything else, the truth is somewhere in the middle of those 2 extremes.

I was lucky to have started my professional career before the advent of Git and Mercurial so I got a couple good years using the previous generation of version control software (VCS).  The major difference between using SVN (a previous generation VCS) and Git for me was the ease of managing branches with Git.  With SVN it was such a hassle, it was rarely done by me.  With today’s VCS’s you use branches all the time for things like trying out experimental changes or editing things without getting in the way of your colleagues.   Just because our VCS’s didn’t have branches didn’t mean that we didn’t do these things though.  What I, and I imagine alot of people, did was edit our code’s design to be more flexible so that with one line of code I could toggle the behavior of the program.  All you had to do was make sure your object allocations were inside factory functions then introduce a new interface so that just swapping the factory function would change everything.  It was a bit more work but it left a lasting modular plugin point to your code that could be used later and usually forced a more clear definition of the relationship between the objects via the interface.

I’m sure you are already seeing the danger here; if over prescribed this could lead to a more confusing, overly modular, code base.  It was something I was always cognizant of, and it never became a problem that I saw, but I respect the danger.  Today I use the branching the tools provide, but more than once I’ve recognized in hindsight some branches as missed opportunities to make my design more dynamic.  Opportunities that I would have seized in a previous age out of necessity.  So, we should see branching and modular design as overlapping tools and just make sure you weigh the benefits of both before you default to VCS branching.  My guess is that 10% of the time you might want to modularize your design… then you can still branch, it will just be a single line difference.

photo credit: Remon Rijper via photopin cc