I thought I’d take a moment to outline the progress of the project and upcoming developments.
Syntə has a new limiter! I’ll do a more fully featured write up of this in a separate post.
Briefly, the new design is what was originally intended, has been better characterised and works well so far. It’s in the repo if you want to take a look.
Talking of which, at some point soon I’m planning to rename the repository to “synte” (as opposed to syntelang). This is one part of the roadmap to take us to…
…porting
Yes, it’s finally almost time to port Syntə to the mac platform. Which will involve the following stages:
- housekeeping - reorganising the project directory, mainly for producing binaries, but the sound engine and some types might become separate packages too.
- create a simplified build/install process for the current form
- integrating portaudio bindings
- optionally setup a github flow to produce binaries
- obtain a mac developer certificate and sign the binary
- testing - beta testers required!
I have scheduled work on this to commence sometime in April(ish) and will do some kind of announcement if it all works out.
In preparation I have been working on getting the figurative house in order. Since I overhauled the transfer data structures there have been a couple of issues that I’ve been ironing out. I’ve recently fixed a problem with the panic/restart feature which managed to escape testing. You can see more on this in commit fc7f1f5.
Verbose mode was also broken, now fixed. Also other fixes and corrections such as the updated pause logic, which wasn’t properly finished in the first place, oops.
testing, testing
Evidently a tighter testing regime is required! Testing audio output is an intrinsically intractable problem, for end-to-end at least, as it’s not straightforward to programmatically determine the effective operation of the sound engine except by using one’s ears.
Up to now, a few meagre unit tests and a suite of listings compiled from the readme were all that stood in the way of bugs being let out into the wild, on a semi-automated basis at least. I’ve found the most effective way to uncover problems to date is just to indulge in ‘human fuzzing’ jam sessions, I seem to have an un-erring ability to go off-piste and discover all manner of undocumented behaviour!
The next step on this is to write more test scripts comprising of listings using the new wait command to simulate human input. This hasn’t been pushed yet, and will likely remain something of an easter egg (very seasonal!) as it’s not intended for usual use.
Previously I had split out the main loop into a run function, so these tests can be incorporated into the ‘synte_test.go’ tests, but they may still have to be listened to to ascertain all is well. Any suggestions on testing will be happily received.
re: factor
I’ve also been slowly continuing the refactoring work that was begun in January. Shorter and more readable functions will definitely aid testing. The old code worked surprisingly well given what it looked like, but I’ve gained some efficiency due to less thread-locking mainly and overall more slick operation.
One other thing that is a bit of an experiment - the main CLI/UI has been stripped down in favour of a more conventional terminal style where the flow of commands is displayed, as opposed to the pseudo ncurses style it had before.
I decided that until I do a proper implementation using tcell, it might as well be as basic as possible. The info display now shows the soundcard bit width and sample rate.
The readme also needs an update, which will probably wait until everything is settled.
nerdtube
Once these changes are complete and before I start work on porting, I should really do an update for the youtube channel, which has been languishing in obscurity for some time. This update would include an introduction to the new sync paradigm from last year, as well as detailing how the sound engine now degrades gracefully on overload.
Another scheduled video for the ’tubes is a general introduction aimed at live-coders specifically, which would accompany a TOPLAP blog post kindly suggested by @HighHarmonics. I think it would make sense to wait on this until a succesful porting, given that the work happens in a reasonable time-frame…
Watch this space!