Sputter 1.5.3 Released

Recently I got myself a Google Pixel Pro phone, and was quite dismayed when I discovered that Sputter does not handle the camera cutout very well. Notice the camera hole obscuring the normalize button in the wave editor:

The issue also occurs on multiple other screens throughout the app.

My previous phone, the OnePlus 6, drew a fake bezel on the display edge where the camera cutout is located. Likely a consequence of the new edge to edge philosophy in newer versions of Android, the Pixel phones and probably many other models do not draw the fake bezel.

Luckily, LibGDX (the graphics engine in Sputter) provides a getSafeInsetLeft() API, so Sputter can draw the fake bezel around the camera cutout:

As you can tell this makes the useable UI area a bit smaller, but not by much. On todays tall phones it will probably not be an issue. However, we could do something more useful with this (as it stands) wasted space, perhaps highlighting the track color or something like that. We’ll see…

Of course the target Android SDK version is also updated to the newest Android 17, as is demanded by Google.

Another minor improvement is handling of swipes from the top and bottom of the screen. When swiping up from the bottom to switch between apps, or swiping down from the top to reveal the status bar, Sputter would also receive those events and attempt to switch between tracks. There is an API in Android to detect the margins of these gestures so it can be determined if Sputter should handle them or not.

Update on C++ rewrite

It has been about 10 months since the previous update on the C++ rewrite of the sequencer engine. At that point I wrote that playhead movement was fully implemented. It was not a lie, but soon after it became evident that handling edits with regards to the playhead was not so easy. At the same time I did not want to end up with the kind of spaghetti code which resides in the current version.

For example when deleting a pattern or group, the song/pattern/group ratios you see on screen must be updated immediately, although the actual change in the audio might be delayed because of buffer sizes and bluetooth latency. In some cases the playhead will also jump to another position as a result of the edit, like if you delete the currently playing pattern. In those cases there will probably still be position events in the queue with invalid positions. In other words, position events pointing to a deleted pattern or group. These situations can be real head scratchers to properly figure out.

Good news is I have come up with a way of doing it which works fine and has clean and manageable code, and it seems like we are not that far away from a functioning implementation. Will be posting more about it once it is done.