Thursday, September 21, 2017

dream => crawl => walk

I am making some progress towards creating a replacement (yet to be named) for RatioKey. Of course, that is no guarantee it will ever be published, but I'm feeling more hopeful in that regard.

I'll post any real milestones here, but if you would like to follow this project in more detail, I've created a Twitter account just for that: @harmonicLattice. That handle contains a hint about what I'm currently working on, but only a hint.

Saturday, September 03, 2016

Version 1.1 has become an embarrassment

Rather than subject myself to the tension of wondering whether Apple would choose to remove RatioKey 1.1 from the App Store, I have chosen to remove it myself. My apologies to the handful of you who might still have found some value in it.

I can't promise that I will ever manage to publish an updated (reconceptualized) version, but it is still my intention to make the attempt, although that project may not bear the same name.

Thursday, January 28, 2016

RatioKey partially broken in iOS 9.2.1

Well, it's been a good run, far better than I had any right to expect, but after five years RatioKey 1.1 is no longer entirely functional.

I was already gearing up to do an update, but this development adds some urgency to that intention.

I'm still undecided about whether to support anything at all from version 1.1 since it was less than thoroughly well thought out. Some elements will most likely make it into version 2.0, but certainly not the very difficult to use keyboard arrangement. Expect something really quite different!

Time frame? Can't say with certainty, but the project is moving from the back burner to the front.

Friday, August 14, 2015

progress report

I now have code that I believe will do the job of feeding sample values to iOS's sound output system, using the new (as of iOS 8) Audio Engine facility, and I've begun work on the rest of the app (a complete rewrite) that I think will prove more interesting, in part because it will no longer have to complete renders while the sound system is waiting for input, which should eliminate artifacts caused by a lack of timely input.

Before I can test what I've already written, I'll need to complete some other parts of the app, but that is a matter of making time for it; the part I had only the vaguest idea how to do is already done, assuming it's correct.

Sunday, March 22, 2015

outdated assumptions

I have just discovered that, as of iOS 8, Core Audio no longer requires either C or fixed-point sample values. This hugely simplifies the task at hand!

At least my difficulty in putting together enough time to get anything done has saved me from having any code to speak of that needs to be rewritten.

Saturday, July 26, 2014

the perils of spare-time programming

So, it was only three days ago that I posted this, but already I'm having second thoughts and afterthoughts. These appear below as block quotes.

Frankly, I wasn't making much headway before, hardly managing to keep up with changes to Objective-C, and significant changes to the frameworks, like ARC, and to the developer tools.

Shortly after completing RatioKey 1.1, I became involved with the Robots Association, the organization behind Robots Podcast and This involvement relates to another consuming interest of mine, which is detailed in my Cultibotics blog. As I began to feel I was making headway on that front, the amount of time I gave to it increased until it consumed nearly all of the spare time I could muster, at which point I burned out (not completely, but I had to dramatically reduce my level of involvement to keep it going). However, I couldn't just pick up where I'd left off with RatioKey, because the intervening time had left me unfamiliar with my own code, and only vaguely acquainted with the changes Apple has introduced, so I began the process of getting back up to speed.

Now there's a whole new language (Swift) to learn, and learn it I will, even if it means putting off everything else until I've done so.

(Hopefully not to the point of another burn out!) The introduction of Swift has helped to focus my attention. Since I don't have a large Objective-C code base, it doesn't make much sense for me to continue to work in that language, especially considering that the language has continued to change while I was looking the other way.

Even if, as I expect is the case, Swift can't yet be used with Core Audio, which is a C-based API, it will be otherwise applicable, and important for me to get an early start with it, rather than trying to put off the inevitable change.

Actually, I may be wrong about Swift not working with Core Audio. At the very least, I should be able to import a C header into Swift.

Besides, there's quite a bit to like about Swift. It's clear that a lot of thought has gone into its design, and it continues the trend, which began with the addition of declared properties to Objective-C, of reducing the amount of code needed to get something done.

Beyond that, from what I've seen so far, it strikes me as being closer to the metal, not of the machine, but of the essence of programming. I presume this is a result of it evolving out of compiler technology, rather than the compiler being created to fit the language. This impression gives me confidence that what I haven't yet seen will also make sense to me.

...out of compiler technology and modern programming concepts...

Understand that I wasn't one of those who was easy to convince regarding the need for a new language. I like both C and Objective-C. In particular I like being able to use numerical variables as logical values (zero being false and everything else being true), and, while I haven't used it much, pointer arithmetic strikes me as an elegant solution. Admittedly, it took me more time and fretting than it should have to wrap my mind around expressions like primativeValue** or &scratchpadMemory, but I did eventually catch on, and now I appreciate the precise control they allow. On the other hand, having to use malloc() to obtain scratchpadMemory is a pain.

It's actually worse than that, because you sometimes have to first ask for the size of the data to be received, then allocate a block of memory to hold that, then ask for the data itself, passing in a pointer to the memory block you've allocated, but that pattern typically applies to C APIs and likely isn't going away just yet.

But this is all moot. Apple wouldn't have introduced Swift with such fanfare if it weren't destined to be the future. There are already Swift versions of frameworks that worked with Objective-C, and lower-level frameworks, like Core Audio, are sure to be given the same treatment or replaced with updated versions that are Swift compatible, and that's a trend I don't care to buck.

Actually, "Swift versions of the frameworks" is probably imprecise. It's more like they've created a very fast translator, but I really don't understand how it works, only that it does and is fairly easy to use.

So, RatioKey 2.0, or whatever it ends up being called, if and when I get it done, and provided that it's accepted for distribution by Apple, will be a complete rewrite, using Swift, and probably targeted for iOS8, or, realistically, maybe even iOS9.

Emphasis on "if and when"...

Thank you for your patience!