In the last post I mentioned I did not want to post updates unless there is something substantial to report like a new version. Quite a while has gone since then and no new updates has been made to Sputter, so I thought a status update would be appropriate in any case.
First and foremost, there has been significant progress in making the playhead move smoothly. Here is a video showing the current working revision (sorry about lack of sound):
It has been a while since I did the previous blog post. One reason is that I felt it got boring writing about incremental enhancements in the same areas week after week. The main purpose of this blog is to have a developer log of Sputter, Spitback and other developments at Casual Computing, as opposed to being a news outlet. So perhaps I should have reported some more the last weeks even if there was nothing really newsworthy going on. Also, we had a tight deadline at work the last weeks and I could not take my usual day off to work on Sputter.
In the previous blog post, it was described how some refactoring was needed to get the smooth playhead with latency compensation working properly. Well, it turns out that big parts of what controls song position and how it is presented in the UI has to get a relatively major overhaul. On the plus side this will fix some minor quirks and awkward code in addition to solving latency issues.
The refactoring is necessary so that the grid playhead, groups and main menu timeline can show the same smooth, latency compensated playhead. Additionally, the notes has to draw sparks at the same time the playhead crosses them, which can be in the future relative to when they were sent to the audio hardware. The grid also might show non-retriggered notes differently, and with different velocities, depending on wether they are currently playing in the speakers or not. This makes the issue a bit more complex, as there has to be maintained a log of notes and what happened when those notes got played.
Today further progress has been made with smooth movement of the playhead, so that it is now possible to have it working with a fixed and hard coded latency compensation. Take a look at the following video, where the app is playing on a bluetooth speaker. Compare the playhead in the grid (left) and the playhead on the pattern (right) to the timing of the audio:
As part of implementing latency compensation I thought I’d do something about the erratic movement of the playhead in Sputter. Since the app considers a generated chunk of audio currently playing, there can be more than one sixteenth measures generated in one go. This makes for uneven speed of the playhead, especially on devices with large audio buffers.
Today I have begun rectifying this. In a coming version the playhead will be moving smoothly along at 60 FPS, in contrast to jumping directly from one sixteenth measure to the next.
About a week ago I was horrified to find a one star review on Google Play:
At first I thought it was something wrong with the app, but then it struck me: The user is probably using bluetooth headphones, and there has not been made any effort in the app to compensate for the latency introduced by these.
Finally I am pleased to announce that Sputter version 1.1.0-beta1 is released to all open beta testers on Google Play. It features the changes to the note properties functionality mentioned severaltimesbefore. Additionally the color of the note names in the grid are now more visible, something which has been requested from several users.
The reason this is not in production is that there are a few minor additions I would like to make. Also, LibGDX has been upgraded to a new version in this release, and I want to make sure everything runs smoothly.
The seemingly everlasting work on new note properties functionality has finally made its way into a release. Note velocities and retrigger status is now visible on the notes themselves, which makes it much easier to work with and what they actually do clearer.
This release is only available to alpha testers. Wanna become one? Pop me an email to support@casualcomputing.info and include the gmail address you use on Google Play.
On all modern devices has a device pixel ratio property. It describes how many physical screen pixels corresponds to one logical pixel in the development platform. For example, the first iPhone had a pixel ratio of 1, which corresponds to a 160dpi screen. The iPhone 4 had a pixel ratio of 2 with a screen of 320dpi. This makes it easier for developers to handle different screen resolution with regards to the physical sizes of UI elements.
