Generating blue/violet noise without FFT
Less expensive than filtered noise will be hard.

Practically all numerical implementations of colored noise that I've encountered so far are based on some random number generator designed to be as white as possible, followed by some noise shaping.

Violet noise itself is sometimes called differentiated white noise (according to wikipedia, at least), but implementing a differentiation in DSP is no different than designing a FIR with a specific high-pass characteristic, so that doesn't help you either.

In fact, that's what my "let's whip this up in less than a minute" attempt looks like; I'm a GNU Radio nerd, so that was my DSP framework of choice to get a blue noise generator done; I made the mistake of calling the files "violet"/"purple", although the noise is blue:


Left: visualization of signal spectrum (frequency scale was arbitrarily set to $\pi$ MHz); Right: GNU Radio Companion showing generating Flow graph.

To explain this flow graph: The idea was to shape the noise with a filter. Now, (FIR) filtering in time domain means convolution and that's terrible computationally. But convolution in time is multiplication in frequency domain. So, signal->FFT->element-wise multiply with constant vector->IFFT is usually faster than direct filtering, at least for filters of length >> 16 on PCs, as far as my experience goes.

Usually, one would use the existing FFT FIR block to implement that, which will take care of applying overlap/add, so that the filter response is actually identical to the time-domain FIR being replicated, but: we don't need that. Not doing the zero-padding before DFT'ing, and not doing the overlapping will not really change the white characteristics of the input signal.

Since the FFT blocks already come with the option to apply a window, I'm choosing a rectangular (i.e. constant 1) window for the FFT (a no-op, practically), and a upramp/downramp window (Python: range(0,fftlen/2)+range(fftlen/2,0,-1)) for the IFFT.

Note that albeit you said you wanted to use this for an audio application, I've done this with complex noise – the reason is simple: The (real-mode modified) FFT is less than twice as efficient for real data than it is for complex, so I just told myself "well, then you get two streams of purple noise; that's fine, too". 

For your listening pleasure, I replaced the sink with a file sink, and converted the result to a stereo 24bit FLAC file; you can download the audio file, and find the GNU Radio companion file in that state in this Github Gist.


  a little less computationally expensive


Benchmarked this on my PC workstation, removing the graphical sink. Average throughput is ca. 10315 IFFTs per second, which, at an FFT length of 1024 that I used, equals to 10.56 MS/s (and, also, a lot of time is spent generating the white noise, because I just used the much-higher-quality-than-needed MT19937-based noise source with a Gaussian shape). That means that per second of processing time, you get two streams of purple noise worth 220s audio at 48 kHz. In other words, if you had e.g. a sound card throttling the amount of samples consumed, this flow graph, which effectively occupies two CPU cores, would be running only 1/220 of the time, ie. consume 2% of one core, if you were to restrict it to running on a single core.

I claim that to be computationally inexpensive.

Now, admittedly, if you're doing this in hardware, things might be different, because FFTs can be quite space-consuming – but it's probably still not what breaks your back at audio rates; by multiplying in frequency domain with a ramp, you're eliminating the need to store FIR coefficients (you'd just count samples and generate the factors ad hoc), and that's much cheaper than having a direct FIR implementation.