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. Also, we had a tight deadline at work the last weeks and I could not take my usual day off to work on Sputter.
Anyway, for the time being I am still working on refactoring the playback control code of Sputter, with the purpose of having a smooth, stable playhead and allow for latency compensation. To be honest it has turned into a way more elaborate rewrite of the core logic code of Sputter than I first imagined. It is funny how well it aligns with YouTube channel Funfunfunction’s video about estimating code rewrites:
Contrary to the points in the video, though, there had been no way to implement latency compensation or smooth playhead movement without this rewrite. It is also just for parts of the code, but still it has panned out the way he says in that it has taken way longer than expected.
On the way I have also discovered and fixed a few bugs. One very obvious can be found in earlier revisions of Spitback:
For those not familiar with Pure Data, the automation receiver for the “Spread” parameter of the Delay effect, actually controls the “Wet” parameter. This is so embarrassing. If you want to see for yourself, try automating the “Spread” parameter in Sputter 1.1.0, and you will be looking forward to the next version.
To fix it,the patch was refactored, so that an error like this is no longer possible:
Another effort to reduce future bugs and make the code more robust is the introduction of unit tests. This should be done a long time ago. Actually it was, but I abandoned it not feeling it was worth the effort. After spending a few hours watching Uncle Bob on YouTube recently, I decided this was a perfect situation for setting up tests again. I was going to mess around in the sequencer logic and wanted to be able to change stuff while being confident that nothing would break. As a total newbie I can not claim that this is anywhere near proper test driven development, but going forward tests will be written for all bugs I (or YOU) discover, as well as for all changes done in the code. Here is a taste of the first baby steps so far:
A new alpha version (sans latency compensation) is closing in, and I hope to be able to release it in the next few weeks.