Saturday, 19 August 2017

Tizen studio is a bunch of broken shit

"Write cellphone apps" they said to me, so I thought I'd have a go. Of the offerings, Tizen, the upcoming cellphone OS, seemed the most promising, promising to compile for X, Windows, Android, IoS and itself. It took me two days to manage to download the Tizen Studio IDE and it's been three days that I've been trying to install the "Native IDE" and "emulator" packages on top of that. After five days fiddling with crap internet and proxies I'm burnt out. Crapware. Slow. Burns 400% of the CPU because written in Java. Doesn't cache partial downloads, so you need a constant fast internet connection to be able to work. I don't have that. It's the usual story: as soon as you touch closed-source software, time stands still and it feels like wading chest-deep in mud. Bastards. Open source it for fuck's sake - we might be able to fix your broken crap. Do I *really* have to figure out how to use it from the command line? After all, that's all I've been able to install! Go figure!

Friday, 12 February 2016

HIdden sounds in Pink Floyd's "Wish You Were Here"

This is a log-frequency-axis spectrogram of the start of Pink Floyd's "Wish You Were Here.
The vertical axis covers 9 octaves from 27.5Hz to 14080Hz.

Those bunches of parallel lines are the first solo guitar notes. But what's that diagonal line at the top, a sine tone that sweeps between X and YkHz with a period of N seconds for the duration of the piece until it breaks loose at the end? It should be audible among the higher harmonics of the guitar - maybe try listening to the piece on headphones?

Wednesday, 9 December 2015

Scientific Debugging and "Where should issues live?"

After reading Andreas Zeller's book "Why Programs Fail", I've ben using scientific debugging method while tracing defects in programs.

As I understand it, if you can't fix a bug intuitively in 10 minutes, apply scientific debugging:
- write everything down, keep all generated test files (or, more to the point, the exact commands used to create them)
- follow a cycle of making observations, formulating a hypothesis, devising an experiment that should either confirm ot reject the hypothesis. If it's rejected, you have to formulate a new hypothesis. If it's confirmed it either leads to a diagnosis and fix or to having to refine the hypothesis for a new cycle of tests.

My first attempt was while tracing the causes of timing errors in a buggy FPU, documenting the (many!) steps of the above cycle until I found the cause of the bad floating point results making a test suite fail: that if the result of one FPU instruction happened to be used by a following instruction exactly N clock cycles later and with the right FPU-result-pipeline delays in the intervening instructions, then the result was picked up as garbage.
I'm pretty sure I'd never have got as far as I did without SD.

What I'd like is to integrate the scientific debugging method into the current bug trackers. Where the Scientific Debugging Method is appropriate (variances from desired behaviour with unclear causes), should we look at integrating the finer-grain documentation of the bug's resolution into the issue tracker itself so that, instead of having issues, each with a linear sequence of comments, each would have any number of hypotheses, experiments, observations, with a confirmed hypothesis leading to one or more refined versions of it, and a rejected one having no children.

At present, I'm trying this just by using plaintext and images. Here are two examples with pretty sonic diagrams for sndfile-spectrogram on GitHub: Strange florets in sndfile-spectrogram output and Horizontal comb of shadows in what should be smooth spectrogram output

A few months ago, in a private two-person project without a public tracker, we created a folder in the source tree called "issues", containing text files named "1", "2", "3" and so on, each of which is added to the git tree as an issue-creation commit, together with any associated test files. These text files are then modified as issue investigation and resolution proceeds, and the issue file is removed from the source tree with the commit that resolves the issue. It lacks some things, like being able to see, for example, all resolved issues, though I guess a shell script should do it.

But, hang on a minute, a source code tree's issues *should* be part of the source tree.
If you take a copy of a source tree, you should get the list of known bugs in it too.
Web-based bug trackers like Github divorce the code from its issue tracker and keep the list of issues on their servers. I mean, I think web-based issue trackers are great! But can we think about doing something similar, that travels along with each copy of the code it speaks of?

And can that the operations on that in-source-tree mechanism embody scientific debugging steps in its logic, dealing in Observations, Hypotheses, Predictions, Experiments, Rejections or Confirmations and Diagnoses-Fixes? Is the SciDebug workflow diagram comprehensive enough to make it a mandatory procedure in a bug tracker? If so, it would give speed and power to our collective debugging by forcing everyone working on the project into a "scientific" way of reasoning in their work, as well as documenting the reasoning that led them to their conclusions.

Saturday, 10 October 2015

MaverickCrunch code runs on HEAT deep space telescope at -80°C

I just heard that the High Elevation Antarctic Terahertz telescope runs code generated by my MaverickCrunch FPU patches for GCC, making it three or four times as fast at doing its scientific calculations to map the formation of stars. Cool. 

 The HEAT telescope sitting in an Antarctic landscape

Saturday, 10 May 2014

Bam! (Ruinous 2014)

Amazing. After being sacked and thrown out of home in January, losing most of my stuff, now on April 27th, my 50th birthday, having to leave my girlfriend's place thereby losing everything else except two clothes and a miniature plastic chess set.

 As if that weren't enough, now sets firefox ringing
alarm bells saying it's a malware site with red banners saying that you go there at your peril.

That said, I am in good health, eat and sleep well and the web sites' hosting is paid up until April 2015, so I've gone back to the lifestyle in which I don't use money and work anyway for what seems most useful or fun at the time.

I even find internet access occasionally. And play a lot of chess.

Friday, 17 August 2012

Audio spectrograms with a logarithmic frequency axis

I've wanted to do this since 1990.

The Pattern Emerges by Delia Derbyshire

Detail of start of melody and chords
Audio spectrograms with a logarithmic frequency axis turn a piece of music into a picture in which the musical notes are evenly spaced up the y axis from the bass notes at the bottom to the accompaniment and melody at the top. Time runs from left to right and the colours show how much energy there is in the sound at each frequency at each instant.

This makes it simple to score a piece accurately when only its audio survives.

It's made by warping a linear spectrogram created by the sndfile-spectrogram program in sndfile-tools using ImageMagick's -fx operator.

For further details and to listen to the above piece against its spectrogram, see

Update 2016-02-22: I've modified sndfile-spectrogram to enable it to produce log-frequency-axis spectrograms directly, now included in the master version of sndfile-tools.

Thursday, 2 February 2012

Gasp! Ed written in Lua

Finally, there is a small, simple, powerful text editor written in Lua.

With no known bugs again \O/