After a lot of messing around an researching the issue, it seems like automatically determining latency for bluetooth audio is a long shot. Not only is it hard to determine the latency, but it seems like it can vary during a session too. Variousothersequencers I have tried do not seem to attempt to do this.
Nevertheless, I think there should be an option for adjusting this manually, in a user friendly and simple way. You might think that using bluetooth headphones is not the way to go for music making, and you’d be right, but especially since phone vendors have been removing the headphone jack from many models, it will probably come in handy.
Finally, after way too much refactoring, experimenting and re-thinking, Sputter 1.1.1 finally went out the door to Google Play today. This release will probably seems quite subtle to most users, with the movement of the playhead indicator being the only visible change. However, this will pave way for better A/V sync with regards to audio latency, which will be tackled in a forthcoming release.
If Sputter is going to live a long and healthy life, it is crucial that a good foundation is layed and we don’t end up with an unrecoverable mess. I realize that some of the code structures used in previous versions were not optimal and actually quite dumb. This was the reasons for several crash reports I have received through Google Play. Starting from version 1.1.1 code quality has been vastly improved, and will be cleaned up further during the next couple of releases.
Sputter 1.1.1-beta1 was released today. Within hours I discovered several bugs which I was able to fix, so I uploaded an additional beta2. At the time of writing beta2 is still under review by Google Play, but I assume it will be available shortly.
The plan for me going forward is to attempt to make another demo tune and video. The smoothly moving playhead indicator brings a quite improved look and feel to the app, so this should be showcased in the video on the Google Play product page. Another good reason for taking a break from coding to make music is being able to proper beta test the app myself. It is amazing how many bugs float to the surface only when actually using the app as opposed to just testing specific features.
After way too long of a development period, I am finally releasing Sputter 1.1.1-alpha1 to internal testers on Google Play. As you already know if you have been reading this blog, this version features a smooth moving playhead as opposed to the current stable version which moves 1/16th at a time. This makes for a much nicer visual look, and allows for forthcoming improved A/V sync.
There will probably be a couple of bugs, but possibly less crashes than on the current stable version. With some luck the only faults you will experience are some minor glitches on the (smoothly moving) playhead when deleting tracks, using the Copy To function, playing with undo etc.
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.
