<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Press Play and Go: Posts</title>
    <link>https://pressplayandgo.app/posts/</link>
    <description>Short posts, tips and comments about the Press Play and Go app for fitness instructors.</description>
    <language>en</language>
    <atom:link href="https://pressplayandgo.app/feed.xml" rel="self" type="application/rss+xml"/>
    <lastBuildDate>Tue, 20 Oct 2026 00:00:00 GMT</lastBuildDate>
    <item>
      <title>App History – The First Version</title>
      <link>https://pressplayandgo.app/posts/introduction/</link>
      <guid isPermaLink="true">https://pressplayandgo.app/posts/introduction/</guid>
      <pubDate>Tue, 20 Oct 2026 00:00:00 GMT</pubDate>
      <description>This is a potted history of the first version of the app. It describes how it came about, various decisions that were made, and why I decided to do a complete restructure and rewrite to produce the current version. The original app was first written back in 2010 when I first decided I wanted to finally learn how to develop for iOS. That meant learning Objective-C at the same time. Or as it quickly became known: [[[[[[[[Objective-C] is] the] one] with] all] the] brackets] Since the best way to learn is to actually create something I decided to combine it with my other love of Les Mills group fitness programmes. The first version was a little flaky. The Cocoa frameworks weren&#39;t at the level of stability and polish that they are today. Especially the audio playlist one which was a bit of a problem since the app used it heavily. A helpful instructor used it in a few classes that I attended and we discovered issues such as switching on airplane mode before class prevents her mother calling and interrupting a series of jump kicks in the middle of a track. Phones then had nowhere near the level of ubiquity they do today so it was also learning about how best to use them in the environment of the time. Eventually I put it out for public consumption and was surprised to get even a few downloads. I made it free because I wasn&#39;t completely happy with how it turned out. Despite that it picked up a bit of traction through word of mouth. I could tell that because I was getting a few support emails. That was mostly split between &quot;it&#39;s not finding my music&quot; and &quot;it stopped playing during class&quot;. The latter was the most serious and came from trying to use the built-in AudioPlayer class. While it worked for most things it had trouble working reliably with the continual checking I needed to do to track things during a class. So I ended up rewriting that component using AVMutableComposition. That turned out to be far more reliable and the problems playing in class tailed off. The matching was an issue in the early days and it remains one with the current version all these years later. The problem was how to detect which song on a user&#39;s device matches the one in a Les Mills release. Back then phones had nowhere near the processing power they do now. That meant you couldn&#39;t do the obvious way of today in generating a SHA256 hashcode on each file as that would have taken an unacceptably long time and chewed through the battery very quickly. So I decided on the technique of &#39;fingerprinting&#39; a CD (no music downloads at that time) which involved getting the running time and order of the tracks then matching that against the albums in a user&#39;s library to see which ones lined up. In most cases it picked up quite a lot. The advantage was that as long as the same album title was on all tracks and they were numbered consecutively it didn&#39;t mind what the song titles or artists were. That naming was a major concern back then as no-one used the same format for those fields when ripping from a CD. There were a few issues because most people simply let the ripping software pull the data down from the internet and it wasn&#39;t always correct. Even today I still get BODYBALANCE 50 albums that state they are BODYATTACK 50. Getting clean data from lots of people is not an easy task so there&#39;s a fair bit of pre-processing that goes on before I can add it into the system. The matching had two sources of problems. The first was when two releases had the same fingerprint. This was something that became increasingly common as the number of releases increased with time. It was affected by the need to have a 5-second leeway on each song as CD-ripping software back then varied with some adding a few seconds before and/or after a track. So the matching process had to be a little fuzzy. Around that time there was a fight between the gym industry and the music industry in Australia over the cost of playing music in class. The music industry won in court which meant the cost would have risen from around $1 a class to $15. So a lot of gyms switched to using cover music. That now meant two versions of a release could easily have the same fingerprint. It meant adding in a workaround where the user had to select which album matched which release if there was a conflict. It worked but I was very unhappy with the implementation. The main issue with matching was that it checked against the music in the iOS Music Library. Most people already had their music in there and given that devices then had very limited storage space you had to minimise the amount of data in your app. If people put the whole album into the music library things worked fine as the data worked with that. But some people only put a few songs because they&#39;d never be teaching the others again. So my support emails were mostly explaining this to them. There was one point in 2013 that I had a bad day and having got another support email decided to put a price on the app just to stop too many more people using it. Bizarrely this increased the number of downloads. I can only assume it was on the basis that if it costs something then it is viewed as having a greater inherent value over something that is free. I wasn&#39;t going to knock back the income even though this does show that as a businessman I&#39;m a reasonably good software developer. Things ran better after that. Some Les Mills staff even gave me a mention which helped with sales. Then Apple stepped in with their cloud music. That product was a complete disaster with their matching. Many remember their live albums were suddenly half-filled with studio versions. It was even worse for group fitness instructors as their purchased versions which has been specially remixed to fit the choreography were replaced by something which had the same name but didn&#39;t have the repeated bridge and chorus. Which made it useless to be played in class. So I had to find out what was happening and then communicate it to all the affected users. While the severity of that reduced over years I was still having to explain it users on occasion eight years after the issue first started. It was always my intention to produce the next generation of the app because like most people who have built something and see it every day we can spot the flaws and where it chafes at the user. So I finally decided to do so. (that&#39;s called ending on a trailer for a later post)</description>
      <content:encoded><![CDATA[<p>This is a potted history of the first version of the app.  It describes how it came about, various decisions that were made, and why I decided to do a complete restructure and rewrite to produce the current version.</p>
<p>The original app was first written back in 2010 when I first decided I wanted to finally learn how to develop for iOS. That meant learning <em>Objective-C</em> at the same time. Or as it quickly became known:</p>
<p><code>[[[[[[[[Objective-C] is] the] one] with] all] the] brackets]</code></p>
<p>Since the best way to learn is to actually create something I decided to combine it with my other love of Les Mills group fitness programmes.</p>
<p>The first version was a little flaky. The Cocoa frameworks weren't at the level of stability and polish that they are today. Especially the audio playlist one which was a bit of a problem since the app used it heavily. A helpful instructor used it in a few classes that I attended and we discovered issues such as switching on airplane mode before class prevents her mother calling and interrupting a series of jump kicks in the middle of a track. Phones then had nowhere near the level of ubiquity they do today so it was also learning about how best to use them in the environment of the time.</p>
<p>Eventually I put it out for public consumption and was surprised to get even a few downloads. I made it free because I wasn't completely happy with how it turned out. Despite that it picked up a bit of traction through word of mouth. I could tell that because I was getting a few support emails. That was mostly split between &quot;it's not finding my music&quot; and &quot;it stopped playing during class&quot;. The latter was the most serious and came from trying to use the built-in AudioPlayer class. While it worked for most things it had trouble working reliably with the continual checking I needed to do to track things during a class. So I ended up rewriting that component using AVMutableComposition. That turned out to be far more reliable and the problems playing in class tailed off.</p>
<p>The matching was an issue in the early days and it remains one with the current version all these years later. The problem was how to detect which song on a user's device matches the one in a Les Mills release. Back then phones had nowhere near the processing power they do now. That meant you couldn't do the obvious way of today in generating a SHA256 hashcode on each file as that would have taken an unacceptably long time and chewed through the battery very quickly. So I decided on the technique of 'fingerprinting' a CD (no music downloads at that time) which involved getting the running time and order of the tracks then matching that against the albums in a user's library to see which ones lined up. In most cases it picked up quite a lot. The advantage was that as long as the same album title was on all tracks and they were numbered consecutively it didn't mind what the song titles or artists were. That naming was a major concern back then as no-one used the same format for those fields when ripping from a CD.</p>
<p>There were a few issues because most people simply let the ripping software pull the data down from the internet and it wasn't always correct. Even today I still get BODYBALANCE 50 albums that state they are BODYATTACK 50. Getting clean data from lots of people is not an easy task so there's a fair bit of pre-processing that goes on before I can add it into the system.</p>
<p>The matching had two sources of problems. The first was when two releases had the same fingerprint. This was something that became increasingly common as the number of releases increased with time. It was affected by the need to have a 5-second leeway on each song as CD-ripping software back then varied with some adding a few seconds before and/or after a track. So the matching process had to be a little fuzzy. Around that time there was a fight between the gym industry and the music industry in Australia over the cost of playing music in class. The music industry won in court which meant the cost would have risen from around $1 a class to $15. So a lot of gyms switched to using cover music. That now meant two versions of a release could easily have the same fingerprint. It meant adding in a workaround where the user had to select which album matched which release if there was a conflict. It worked but I was very unhappy with the implementation.</p>
<p>The main issue with matching was that it checked against the music in the iOS Music Library. Most people already had their music in there and given that devices then had very limited storage space you had to minimise the amount of data in your app. If people put the whole album into the music library things worked fine as the data worked with that. But some people only put a few songs because they'd never be teaching the others again. So my support emails were mostly explaining this to them.</p>
<p>There was one point in 2013 that I had a bad day and having got another support email decided to put a price on the app just to stop too many more people using it. Bizarrely this increased the number of downloads. I can only assume it was on the basis that if it costs something then it is viewed as having a greater inherent value over something that is free. I wasn't going to knock back the income even though this does show that as a businessman I'm a reasonably good software developer.</p>
<p>Things ran better after that. Some Les Mills staff even gave me a mention which helped with sales. Then Apple stepped in with their cloud music. That product was a complete disaster with their matching. Many remember their live albums were suddenly half-filled with studio versions. It was even worse for group fitness instructors as their purchased versions which has been specially remixed to fit the choreography were replaced by something which had the same name but didn't have the repeated bridge and chorus. Which made it useless to be played in class. So I had to find out what was happening and then communicate it to all the affected users. While the severity of that reduced over years I was still having to explain it users on occasion eight years after the issue first started.</p>
<p>It was always my intention to produce the next generation of the app because like most people who have built something and see it every day we can spot the flaws and where it chafes at the user. So I finally decided to do so.</p>
<p>(that's called ending on a trailer for a later post)</p>
<p><img src="https://pressplayandgo.app/images/posts/firstversion.png" alt="The first version of Press Play and Go app"></p>]]></content:encoded>
      <enclosure url="https://pressplayandgo.app/images/posts/firstversion.png" length="478341" type="image/png"/>
    </item>
    <item>
      <title>Welcome to Posts</title>
      <link>https://pressplayandgo.app/posts/welcome/</link>
      <guid isPermaLink="true">https://pressplayandgo.app/posts/welcome/</guid>
      <pubDate>Mon, 19 Oct 2026 00:00:00 GMT</pubDate>
      <description>Writings, tips, and comments about Press Play and Go will appear on this page. There&#39;s an RSS feed because I&#39;m an old tech guy and if something works well then you keep using it even if it isn&#39;t the latest and coolest thing. I&#39;ll also add feeds for the less-worse social media platforms.</description>
      <content:encoded><![CDATA[<p>Writings, tips, and comments about Press Play and Go will appear on this page.  There's an RSS feed because I'm an old tech guy and if something works well then you keep using it even if it isn't the latest and coolest thing.  I'll also add feeds for the less-worse social media platforms.</p>
]]></content:encoded>
    </item>
  </channel>
</rss>
