Rigelian 2.0 is in the mail

I just completed the last bits-and-pieces and posted the new 2.0 version of Rigelian to the AppStore and into the review and approval process.

When I started the development of Rigelian over 2 years ago, I had a couple of things in mind. The main goal was to create the best remote control for mpd-based players. That meant it had to be easy to setup and use (hide configuration where possible), very responsive and great looking.

But next to that I also had technical goals I wanted to achieve. To make sure that extending and supporting the app would be possible with a reasonable amount of effort, I started from scratch using the latest that Apples development eco-system has to offer. That meant Github, swift, RxSwift, cocoapods and later swift package manager, and many of the great open source packages made available by the swift developer community. And bye-bye to Objective-C after almost 30 years (yes, really 30 years, I did my graduation project in computer science back in 1990 using Objective-C on a DEC Ultrix machine).

And I wanted to use the experience I collected over the last 10 years building music remote controls: first MPoD and MPaD, and later the iOS controller for the Bluesound system. I set out to abstract the generic concepts of a music remote control, and create a front-end that could operate completely independent of the player it is controlling. For that I created ConnectorProtocol which defines a generic way to communicate with a player regarding discovery, control, browsing and status updates. The front-end will only know about the protocol, and have zero knowledge of the specific implementation. The first implementation against the protocol was MPDConnector, which has been the basis for Rigelian up-to 1.7.2. And for the last half year, in parallel to further developing the front-end I created a second implementation, this time for kodi: KodiConnector.

And by now this has reached the point that it’s actually possible to perform the main things you want to do with a music remote, and I’m releasing my newborn into the world. I’m very happy with the result where I can maintain a single code base for the front-end, and seamlessly control 2 completely different kinds of players with an app that looks exactly the same in both cases. It will also mean that future improvements like Siri support will be available for both types of players with almost no additional effort. How nice is that.

Using c-style defines with Swift Package Manager

When compiling the c-based library libmpdclient, I ran into the problem that it contains some #define statements which have to be set during the build. It took me while to find out how to set those when building the package with Swift Package Manager.

In the end off course the answer was right there in the documentation, but I only found that after watching one of the SPM videos from WWDC 2019.

let package = Package(
     name: "libmpdclient",
     targets: [
             name: "libmpdclient",
             publicHeadersPath: "mpd",
             cSettings: [
                 .define("DEFAULT_HOST", to: "\"localhost\""),
                 .define("DEFAULT_PORT", to: "6600"),
                 .define("ENABLE_TCP", to: "1")

Migration to swift package manager

After some initial try-outs with the swift package manager some months ago, I came back to it today to see if it’s possible to run it side-by-side with cocoapods, and gradually migrate packages over.

To begin with, I took out the libmpdclient sources of the mpdconnector framework, and put it into a framework of its own which can be built and included using swift package manager. While doing this I ran into various workspace and build issues, including a point at which the Xcode build server would crash every time I opened the workspace. But in the end I managed to get it all working again.

The framework is called libmpdclient-swift and is available on GitHub (I will gradually move over all sources from bitbucket). It’s based on the latest 0.21.17 version of the original libmpdclient.