Sputter: Status of Next Version

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.

Refactoring Madness

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.

Preview: Latency Compensation

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: This seems like a big improvement over the current version.

Smooth Playhead

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.

Bluetooth Latency Issues

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. So, I tried it out on a bluetooth speaker, and sure enough, the latency is not only noticeable but quite annoying:

Sputter 1.1.0 released!

After a lot of back and forth, Sputter version 1.1.0 is finally released. Compared to the last stable version (1.0.2), this release brings: Possibility to select multiple notes while adjusting note properties Note velocity and retrigger mode are now visualized on notes Improved contrast on note names in the grid Fixed note velocities not being set when loading songs Fixed faulty graphics after adjusting “Display size” on some devices Some crash and bug fixes In addition, the note velocities are now shown in numbers on the notes themselfes:

Sputter 1.1.0-beta1 released!

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 several times before. 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.

Sputter 1.1.0-alpha1 released to alpha testers

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.

Pixel Ratio Quirks

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.

Note Properties Progress

Finally I had the opportunity to work with the improved note properties functionality previously described. This is what I have achieved so far: There now is a visual representation of wether or not a note is retriggered, which will hopefully make them easier to use as well as more obvious what they do. Also, the color of the notes will be lighter on notes with lower velocity. These changes will make it unnecessary to open the note properties to inspect the velocity and retrigger status of a note.