There has been some progress made with regards to MIDI file export, and the challenge described in the previous post has now been solved. Actually the first MIDI file containing actual notes, with all events lined up correctly, has been exported from Sputter:
The original song in Sputter looks like this:
As you can see the first group repeats twice, and the longest note does not retrigger, so the exported MIDI file is correct.
So I have looked a bit more into bringing MIDI file export to Sputter. This could be very useful, making it possible to use Sputter as an on-the-go drafting tool.
This summer I have been reading up on and implementing code for the MIDI file format. This has gone really well. By this point it is a quite old and simple format, so writing the code for it was quite easy.
Yesterday Sputter 1.1.4 was made public on Google Play. This release fixes some cringeworthy glitches in the UI, as well as an attempted fix for file export issues.
Additionally I am happy to report that work on MIDI file export has finally begun. This has been a frequently requested feature, and would make Sputter become a decent on-the-go sketching tool for ideas to bring back home to a fully featured DAW.
Initially I had intended to implement a feature suggested by several users, which I also sometimes feel the need for when using Sputter: Highlighting the currently “active” instrument, something like this:
My first thought was that this would not make 100% sense since after making a change to the “current” instrument, like adjusting ADSR, you are not strictly speaking on that specific instrument any longer since it has been altered. The solution proposed from a user was to mark it as “edited”, something like this:
At last, the changes made to Sputter during the last 10 months has been made public in the form of version 1.1.3!
The planned automatic detection of output latency for both bluetooth and internal speakers has boiled down to a settings screen where it can be set quite easily, although manually, like this:
Later I am planning on porting the audio engine of Sputter to the Oboe library, which will allow for lower output latency, possibly also for bluetooth. In the meantime you will have to adjust it manually.
Some days ago, this crash report was sent to my Google Play Developer Console:
For those not in the know it basically means that the UI is requesting a sequence position which does not exist in the sequencer logic. This was not unheard of before the great refactoring, but I thought I had taken care of it and that it couldn’t really happen anymore.
I first thought this was caused by some unlikely but possible condition in which two or more threads do operations on the same data in parallel. That is a classic case in software in general, but I did not find anywhere where it seemed likely to happen.
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.
