I’m working some utilities for OSC support in node, and I noticed that there was no really simple way to convert from native javascript types to and from the binary buffers required for OSC messages.

It turned out to be a nice project to get my feet wet with making native node extentions.

The code is free on github, and it’s uploaded to npm. To grab it, first make sure you have npm installed, then run

npm install binpack

The source code should provide a good example of a simple node extension.

Here’s a video demo:

Here’s the compiled, ready-to-use standalone and audio unit

And, all the source code is on GitHub:

Recently, I’ve been looking a for quick ways to make audio effects and add them to my workflow. I’m a big fan of puredata for prototyping and quick editing, but it’s not too easy to use if you want to process audio coming from an AU or a track on an audio workstation. What I usually do is start up JACK, attach PD’s ins and outs to that, and then run the JACK AU in my sequencer. While this is okay, the problem is you have to perform the somewhat complicated set-up procedure each time you want to start working. It’s also very hard to run multiple pd-based effect or synths at once, as each needs its own output routing.

The answer to all these problems seems to be to try to fit PD more naturally into the audio workstation, probably in the form of a plug-in. There’s been some work on this, namely pd-vst, but that doesn’t seem to be maintained very well these days. A much more active project is Peter Brinkmann’s pdlib. Pdlib allows embedding pd into your own app, and seems to be focused on smartphone platforms like Android and iOS. However, its smart, fast and minimal API seems pretty useful for regular old PC, Mac, and Linux apps, too.

So, recently I’ve been using a combination of JUCE and pdlib as a quick development platform for plug-ins. If you have a puredata patch that you want to make into a plug-in, it should be pretty simple to edit the source code (all you should have to change is PD_characteristics.h, in addition to using the jucer UI editor to edit PluginEditor.h/cpp – no knowledge of c++ required). Right now I don’t support any MIDI, but it should be fine for midi-less effects and synths – I plan to get midi working in the future (if you want to try your hand, the source code is right there!)

The one problem with this system is that puredata uses a lot of global state, so you can’t have more than one copy of puredata in any process. While this is fine for standalone apps, it means that if you directly use pdlib in plug-ins, you can only have one instance loaded at any one time. This kinda sucks, as that was the main problem with my JACK-based set-up. So, I’ve made the plug-in launch a UI-less process to run PD in. There are problems with this approach, too – right now I’m using JUCE’s interprocess communication layer, which doesn’t really seem to be fast enough for this. Things like switching programs and expose will sometimes block execution and cause audio drop-outs. If anyone wants to help out by speeding up the interprocess communication stuff, that would be really cool! The relevant code is in PluginProcessor.cpp and PDSubprocess.cpp . Also, I’ve heard mutterings that there is some plan to remove the global state from PD – if anyone has any info on this, drop me a line!

The only reason the system is mac-only right now is because I don’t have regular access to any sort of linux or windows-based system. It should be as simple as building a project and hitting the compile button! If anyone has some time and a windows or linux machine please e-mail me and we can try to get a version working for your platform.

Photo by J. Robert Lennon

One of my favorite things about electronic dance music is how tirelessly and mindlessly popular synth sounds are exploited. It’s awesome! One of the big sounds of the turn of the millennium was the so-called supersaw, an extremely bright, cold, digital, huge lead sound. You rarely hear it now in non-ironic music, but anyone who was listening to anything dancey and stupid around 2003 will surely recognize it.

Here’s a fairly typical example:

Other big choons that have similar leads are “Ramp” by Scooter, and “Heaven” by DJ Sammy.

The canonical synth for producing this kind of sound is the Roland JP-8000 (or the rack-mount JP-8080), released in the mid 90s. As the sound became trendy in dance music, the ability to produce these obnoxious, blindingly bright monstrosities quickly became a bullet-point feature for competing synths – Novation’s Supernova 2, and the later Virus TI had similar features.

So, what is the supersaw? According to roland’s marketing material, it “sounds like seven saw waves sounding simultaneously”.

Okay, fine. But what is it really? It’s important to remember this was the mid-90s, processing power was tight, and running 7 saws for each note sounds pretty expensive. There must have been some trickery at play.

I always think it’s awesome when products of economical engineering remain relevant long after their shortcuts are no longer needed. This seems to happen a lot with music equipment, and Roland had a pretty good run of devices in this category – the TB-303, D-50 and the Juno series all remained popular long after the constraints they were designed for no longer applied. Once you get into the digital era, these stories of engineering ingenuity get harder to tell. With discrete circuitry, you can just look at the circuit to see what choices the designers made, and how those choices create the sound you hear. With software, all you really have to go on is the output of the device – which can sometimes be a bit inscrutable.

I had sort of resigned myself to never knowing how wonders like the supersaw were produced, until I stumbled upon this awesome thread on KVR. It turns out there are some tell-tale signs that give pretty strong indications of how the supersaws were produced – and the engineering is just as goofy, simplistic, and beautiful as I had hoped, and I’ll spend the rest of this post reviewing the results from that discussion, and re-creating a JP-style oscillator in pure data.

The fundamental problem of digital oscillator design, at least for simulating analog waveforms, is aliasing. Directly synthesizing a saw wave produces harsh noise all over the spectrum. There are lots of ways of getting around this – wavetables and oversampling are probably the most popular commercially, but academia has given us other options too. A lot of hobby programmers use something called BLEP. Korg recently patented a variant of BLEP, too.

Of course, another path is to do nothing to the aliasing and embrace its roughness for what it is. There’s good reason to believe that’s exactly what Roland did in the supersaw.

First, for reference, here’s a nice, modern, anti-aliased (bandlimited) saw wave at 130hz, generated by the free TAL Noisemaker.

As you can see in the spectrogram above, there’s defined peaks at each harmonic and not much noise in between.

Let’s see what a totally aliased, digital-as-hell saw sounds like. We easily use puredata’s phasor~ to make a aliased saw:

You can hear it’s a bit more nasally and unpleasant. It doesn’t sound too different because the frequency of the note is relatively low – the aliased harmonics aren’t very loud. In the spectrum above, you’ll see more differences: the harmonics are still there, there’s lots of aliasing noise between them.

If you turn down the “mix” slider for the supersaw, it becomes a simple saw wave – but with some interesting properties. Here’s the JP-8000′s attempt at a non-super saw at 130 hz.

As you can see and hear, it’s closer to the aliased saw wave from than the saw from band-limited synthesis. There is a notable difference, though, pointed out by the folks at KVR – the noise *below* the first harmonic is significantly less. To make this more clear, here’s the PD aliased saw at 520 Hz:

And the JP at a similar frequency:

Now the low-frequency noise is quite different between the two. It seems that the JP generates an aliased saw and then runs it through a high-pass filter set to only pass frequencies at or above the fundamental of the note. This leaves in all the aliasing noise above the fundamental, so it’s still pretty nasty/noisey sounding, but there’s no energy below the frequency of the note to distract you from the pitch.

Let’s try to approximate that with PD:

Clearly not exactly the same as the filtering scheme is different (the JP seems more like a biquad hi-shelf), but it’s still not a bad likeness.

Now let’s try to reverse-engineer the spread of the saws – originally in the KVR thread people were suggesting complicated schemes based on a chorus effect, but it seems clear from the spectrum of a fully detuned supersaw wave that no, the JP really is generating 7 saw waves:

This makes sense when you think about it – efficiency was king, and it’s hard to beat the efficiency of two extra adds per sample – things are a lot easier when you embrace aliasing rather than reject it, huh?

Int the spectrogram above, we can see that there are indeed 7 peaks at each harmonic – indicating that there are 7 saw waves. Each peak is pretty well defined, indicating that there’s not a lot of low-frequency vibrato going on.
The third harmonic seems like the easiest to pick out the peaks, we’ve got:
(rounded to whole numbers):
350, 368, 384, 392, 400, 417, 435.

So, the detuning ratios are then
(.893, .939, .980, 1.0, 1.020, 1.064, 1.110), or slightly assymetrical.

Again, let’s try this in PD.

Not entirely dissimilar, huh? To be fair, a lot of detuned waveforms have a spectrum that kinda looks like that. But if I use my ears I can definitely hear some similarities.

Now that we have no-detune and max detune in the bag, lets look at what happens at other detune settings. At 0% detune on the slider, there’s still a little bit of audible detune, but not quite enough to see it on the spectrum. We can’t see anything on the spectrum until about 3/4 of the way on the slider, which has a spread of around 15hz at the harmonic at 520 hz:

That means the total spread is around 0.987 – 1.013 rather than the full value of 0.893 – 1.110. This dramatic increase in detune at the end of the sweep of the slider implies there’s some sort of exponential scaling occuring.

To simulate this in PD, I’m just making a guess about the endpoints of the detuning and the fact that it uses log2 scaling.

Sounds pretty good! This PD patch definitely captures the major character points of the JP supersaw oscillator. Here’s some sweeps of the detune knob:

Hands Up!

The beer came out with a clean sour flavor that allows you to detect the heather underneath. Final alcohol content was 4.4%.

Our heather beer

The 1 gallon recipe was:

2 lbs. USA Two-Row grains
1/4 lbs. 120 Crystal Malt grains
90 minute mash
1.5 oz. Heather (beginning of boil)
.5 oz. Heather (filtration)
.5 oz. Heather (dry; 1 week into fermentation)

Suggestions for improvement would be to decrease the amount of crystal malt used to decrease the sweetness.

Slow, but deadly.

]]> http://www.ghostfact.com/sloth-sloth/feed/ 3 http://www.ghostfact.com/spooky-electronic-fireplace/ http://www.ghostfact.com/spooky-electronic-fireplace/#comments Mon, 31 Jan 2011 06:07:03 +0000 russell http://www.ghostfact.com/?p=94 Continue reading →]]> For our Halloween party last year, we made this electronic fireplace to fit in with our cold color palette for the evening.

The form was made with some acrylic laser cut by the always talented Ronan, and I whipped some arduino code to blink the LEDs. The arduino has a few modes, each of which perform some simple algorithms on the current states of the lights to generate the next state. One mode runs some binary 1D cellular automata, to which it randomizes the generation rules. Feel free to modify this code for your own projects.
fireplace.pde

The beer came out to a final 9.5% alcohol, with an (expected) cidery taste, but surprisingly dry for the alcohol content, and with lots of fresh apple flavor.

The 5 gallon recipe was:

32 oz. Honey
2 lbs. Dry Wheat
4 lbs. Dry Extra Light Extract
0.5 oz. Cluster Hops boiled for 40 min
0.5 oz. Cluster Hops boiled for 5 min
2 tbsp. Orange Peel (dried) boiled for 15 min
1/4 Gallon Fresh Apple Cider (half at the end of the boil, half in fermenter)
5 Lbs Fresh Apples (peeled, in fermenter)
White Labs WLP051 California Ale Yeast

Possible improvements would be to increase the honey to cider ratio to add a little more sweetness, and to not leave the apples in the fermenter for the full 3 week fermentation to avoid the grossness seen above…

This morning, as my first encounter with processing, I came up with this simple sketch to map out chords and scales in alternate guitar tunings.  

You’re free to do as you like with the source code:
Processing Code:Guitar_Tuning.pde
Pre-processed Java Code:Guitar_Tuning.java
Mac Application:guitar_tuning.macosx.zip
Windows Application:guitar_tuning.windows.zip
Linux Application:guitar_tuning.linux.zip

Things should be fairly self-explanatory, but here are some notes:

• Click on any text to change it, right click to cycle backwards.
• Click on the labels for the strings to cycle through tunings
• I’m not really sure about the proper semantics for modes in the pentatonic scale, so I just made something up that is probably pretty useless.
• If you want a dominant seventh chord, switch to lydian or myxolydian mode.
• Switching modes in the harmonic minor is a little exotic and I’m not sure why you would want to do it.

If you download the code, you’ll see that this is easily adaptable to instruments with more or fewer strings (simply change the “numGridX” variable at the top of the file), or even grid based controllers (although the sketch does assume that the strings are chromatic along the y axis).

<br /> No Java 2 SDK, Standard Edition v 1.4.1 support for APPLET!!<br />

A ghost’s scaryness is proportional to the length of its arms.