SSFRR

New Performance Video (from 2013)

2018-01-08T00:00:00-05:00

I’ve just uploaded an performance from 2013 for my sensor-augmented upright bass using the mousetrap sensors I designed in 2007. You can see a more detailed overview video of the sensors here, as well as in the blog archive.

Fast array slicing in Julia

2017-11-03T00:00:00-04:00

I write a lot of stream-oriented code, where you’re working with data in chunks and manipulating them as they pass through the system. Julia 0.6 introduced some new functionality for expressing array manipulations more efficiently, which are described in depth in Steven G. Johnson’s post here.

When implementing read and write methods for streams you often end up copying chunks of data between arrays, so I wanted to explore how some of Julia’s features work together to make that as efficient as possible. From reading the performance tips section of the manual we already know that pre-allocating your result arrays is one way to reduce allocations and speed things up (assuming you’ll be writing to the destination array many times), so we’ll use that as a starting point and assume we have a result array a that we’re going to fill by doing some operations on b and c arrays.

I’ll be using the following toy operation to test some variants and discuss what’s going on:

a = rand(2000)
b = rand(2000)
c = rand(2000)

using Compat # currently needed because of an issue with BenchmarkTools
using BenchmarkTools

function naive(a, b, c)
    a[1:1000] = b[1:1000] * 2 + c[1001:2000]
end

And we can benchmark the code to see how long it takes to run:

julia> @benchmark naive($a, $b, $c)
BenchmarkTools.Trial:
  memory estimate:  31.75 KiB
  allocs estimate:  4
  --------------
  minimum time:     3.339 μs (0.00% GC)
  median time:      3.760 μs (0.00% GC)
  mean time:        4.666 μs (16.71% GC)
  maximum time:     95.044 μs (87.97% GC)
  --------------
  samples:          10000
  evals/sample:     8

Now it’s a little hard to evaluate whether 3.8μs is a reasonable amount of time to spend, but almost 32KB seems like a lot of memory to allocate when all our arrays are already allocated. Consider that we’re moving around blocks of 1000 elements of type Float64, so each block should be about 8000B (7.8KiB). So this allocation represents 4 copies plus some extra.

For reference, we can check against the following python code using numpy:

In [57]: a = np.random.rand(2000)

In [58]: b = np.random.rand(2000)

In [59]: c = np.random.rand(2000)

In [60]: %timeit a[0:999] = b[0:999] * 2 + c[1000:1999]
The slowest run took 30.76 times longer than the fastest. This could mean that an intermediate result is being cached.
100000 loops, best of 3: 2.7 µs per loop

Trying my best to match methodologies¹, our naïve Julia version ends up taking about 35% longer than the python equivalent with numpy.

Let’s discuss a little bit what happens when Julia executes this function. First we have the array slices b[1:1000] and c[1001:2000], which will each create a new copy of the 1000 sliced elements. We’re not modifying these arrays and throwing away these copies immediately after, so we’d prefer to create a view into the same data. We could do this with view(b, 1:1000), but we can also use the @views macro to turn both our indexing operations into views:

function views(a, b, c)
    @views a[1:1000] = b[1:1000] * 2 + c[1001:2000]
end

This definitely improves our run time:

julia> @benchmark views($a, $b, $c)
BenchmarkTools.Trial:
  memory estimate:  15.97 KiB
  allocs estimate:  4
  --------------
  minimum time:     1.615 μs (0.00% GC)
  median time:      2.332 μs (0.00% GC)
  mean time:        2.757 μs (12.35% GC)
  maximum time:     71.391 μs (90.06% GC)
  --------------
  samples:          10000
  evals/sample:     10

We see we’ve cut our allocations in half and runtime by about 40%. The allocation reduction makes sense as we’ve avoided 2 copies by using views instead. Numpy uses views by default, which probably accounted for the initial performance edge of the numpy version over the naïve Julia version.

Let’s try another tactic and use dot broadcasting and loop fusion, as described in SGJ’s post. To summarize the issue (though I recommend reading the post for more details), elementwise operations between arrays often create temporary copies that we’d like to avoid. For instance, y = 3x.^2 + 5x + 2 will create temporary arrays for 3x, and 5x, then another one for 3x.^2, and so on, until it finally assigns the identifier y to the final result. Even if you pre-allocate y and assign the elements with y[:] = ... it will still allocate temporaries and then at the end copy the final result into y.

The solution is to use dot syntax on the operators y.= 3.*x.^2.+5.*x.+2, which is transformed (more or less) into:

for i in eachindex(x)
    y[i] = 3x[i]^2+5x[i]+2
end

Which does all the processing in a single pass over the data without allocating any extra temporaries, and is super fast. Now that’s a lot of dots and looks pretty ugly, so you can use the @. macro to add the dots to all the operations in the expression.

Now let’s try this technique with our array slicing. We’ll take out the views so we can separate out the two effects:

function dotted(a, b, c)
    @. a[1:1000] = b[1:1000] * 2 + c[1001:2000]
end

Benchmarking this version shows that it avoids 2 copies for temporary values, and also gives a tidy speedup.

julia> @benchmark dotted($a, $b, $c)
BenchmarkTools.Trial:
  memory estimate:  15.92 KiB
  allocs estimate:  3
  --------------
  minimum time:     1.490 μs (0.00% GC)
  median time:      1.712 μs (0.00% GC)
  mean time:        2.085 μs (15.33% GC)
  maximum time:     57.836 μs (89.50% GC)
  --------------
  samples:          10000
  evals/sample:     10

Now the obvious question is whether we can combine these approaches, and of course we can! The following is exactly the same as our original function with both the macros prepended:

function dottedviews(a, b, c)
    @. @views a[1:1000] = b[1:1000] * 2 + c[1001:2000]
end

So now we’re creating the two views rather than copies, and using loop fusion to avoid the temporary copies. How does this affect our benchmark?

julia> @benchmark dottedviews($a, $b, $c)
BenchmarkTools.Trial:
  memory estimate:  96 bytes
  allocs estimate:  2
  --------------
  minimum time:     284.270 ns (0.00% GC)
  median time:      304.295 ns (0.00% GC)
  mean time:        310.547 ns (0.88% GC)
  maximum time:     3.001 μs (84.90% GC)
  --------------
  samples:          10000
  evals/sample:     278

There’s still some allocation, probably because views still allocate a small object that refers to the original array (there are improvements around the corner that would allow us to stack-allocate these as well), and this version now takes less than 10% as long as our original.

Conclusion

When trying to improve the performance of your code, checking for excessive allocation can be a very fruitful approach. Here we improved our performance by 10X by adding two macros to the front of our expression.

Notes

For the python benchmark, %timeit turns off garbage collection and gives the best mean from 3 runs, so the equivalent julia timing comes out to 3.64µs (calculated by running the benchmark 3 times, subtracting the GC time from the mean value, and picking the best result). There’s also the caching warning printed by %timeit, so the actual python runtime might be somewhat slower. ↩

Exploring noise distribution in Pure Data

2017-03-16T00:00:00-04:00

Defining some terms

This post is all about noise, so lets start with a quick discussion of what noise is. In some contexts noise is defined as whatever part of a signal you don’t care about and would rather ignore. It is a distractor and can obscure the information you want, and is usually what people mean when they’re talking about “signal-to-noise ratios”. In electronics this noise often comes from small random voltage fluctuations in the components themselves, and manifests as a sort of hissing sound, similar to shhhhhh. When evaluating these systems, engineers found that they could model this noise as Additive White Gaussian Noise, which we can break down as:

Additive: The composite noisy signal is just the original pure signal with the noise added to it
White: The noise has a flat spectrum, which means that all frequencies are present equally. In practice real systems always operate within a finite bandwidth, so to be white the noise just has to be flat within the bandwidth of interest. This term comes from an analogy with light, where light with all wavelengths in equal proportions looks white to human eyes.
Gaussian: The values the noise takes follow a gaussian (AKA normal) distribution. This means that values near the mean (usually 0) are more likely than values further away. This part is the focus of this post.

While in most engineering contexts noise is considered unwanted, it turns out to be tremendously useful in many audio synthesis applications. Lots of real-world phenomena have noisy components, from wind to snare drums to raspy violin bowing. Because it’s so common, most computer music and audio processing environments have some mechanism to generate noise, and I spent a little time exploring Pure Data’s [noise~] object.

Spectral Properties

The first thing to do is to check the spectrum to see if PD’s [noise~] object actually gives us white noise. To do this I put together a quick little spectrum viewer called [specplot~]:

And here’s what the spectrum of [noise~] looks like:

Looks pretty flat to me, which confirms that this is white noise.

Value Distribution

The next question to ask is whether the noise is gaussian-distributed. To check this out we just build a simple match that periodically samples from the noise output and updates a histogram plot. The histogram shows us how often different value ranges show up in the output.

This is definitely not gaussian, but looks more like a uniform distribution. We see that values anywhere between -1 and 1 are equally likely to occur. This decision is likely due to three factors:

Uniform random numbers are computationally cheaper to generate then gaussian-distributed ones
Uniformly distributed numbers are bounded, so the output of [noise~] will never go outside of the -1 to 1 range
Uniform and Gaussian noise sound the same as long as their spectral properties match

Filtering Noise

White noise tends to sound pretty harsh as it has a lot of energy in high frequencies relative to most naturally-occurring sounds. It’s common to use white noise as a starting point and then filter it to shape the sound more to your liking. First let’s see what that looks like spectrally:

This doesn’t look too dramatic because we’re using a relatively shallow filter (PD’s [lop~] object is a 1-pole filter so it rolls off at 20dB / decade) and also because we’re looking at a log-scaled plot, which makes it easier to compare signals with a large dynamic range. Still you can see that higher frequencies have been attenuated somewhat. Now lets’s check out the value histogram:

Now this is interesting! Our uniform noise has become more gaussian after filtering. To explain this we can take a quick look at what a 1-pole filter looks like:

Inspecting the filter, we see that the output at time n (y[n]) is a combination of the input x[n] and the previous output y[n-1]. The previous output was itself a combination of that time-step’s input and the output even further back, and so on. So this means that a given output is a combination of all the previous inputs, with exponentially-decreasing weights. We know from the Central Limit Theorem that adding together a bunch of uniformly-distributed random variables gives us a gaussian-distributed random variable and the output of our filter is just such a summation.

Summing up

I’ve never thought too much about the specifics of PD’s [noise~] object, but this little deep-dive had a few interesting rabbit holes to drop into, so I thought it was worth sharing. Let me know on Twitter if you enjoyed it or have questions or comments.

Async/Await and Types of Concurrency

2016-09-07T00:00:00-04:00

I just watched this talk by David Beazley about Python’s newish async/await functionality. Beazley is also known for his Curious Course on Coroutines and Concurrency, which is also wonderful. I’m not sure this talk really sells the paradigm to folks who haven’t been bitten by concurrent programming though, and gets a little bogged down in the yield implementation. I’m also surprised he didn’t reference previous async/await implementations like C#. That said, the talk is really engaging and well-done, and has a lot of great info on async/await.

I felt like this would be a reasonable time to jot down some thoughts I’ve had about concurrent programming, which I’ve mentioned conversations but haven’t ever written down. I’m certainly not an expert - this is informed by work in C++ using threads, bare-metal C using hardware interrupts and callbacks, Python using gevent, and Julia using the native Coroutine support, but there are probably other major types of concurrency that I’m missing. Let me know!

I find myself dividing concurrency systems into several types:

preemptive multitasking, e.g. os-level threads: context-switches can happen at any point in your code, code might even be running in parallel (on multi-core). Accessing shared memory generally needs to be protected with synchronization primitives like mutexes.
cooperative multitasking, e.g. gevent-style green-threads, or Julia Tasks: context switches only happen when a task explicitly yields, or does something blocking like I/O. As long as you don’t have any blocking calls in your critical section you should be safe. Unfortunately you have no idea if a function you’re calling ends up calling something blocking (maybe it prints to a log). In gevent you actually monkey-patch the blocking IO functions so that instead of blocking the whole thread at the OS level it just blocks the current task and hands control back to the event loop.
explicit callbacks: this seems to have been pushed pretty far in Javascript, but as far as I know is less common now that there are nicer primitives. I don’t really know JS though. One nice thing is that it’s very explicit when the context switch happens. The downside is that sequential processes become nested callbacks, and branches (e.g. different success/error callbacks) are hard to follow.
async/await (found in C#, python): To me this seems like a sweet spot where you can write sequential code, but anywhere that might possibly context-switch is marked by await.

The blog post linked in the video is well-worth reading. One issue I take is that there is an advantage to explicitly dividing functions into synchronous and asynchronous, in that you know when your task might block, and you can make sure it’s not in the middle of a critical section. That said, if you’re not using shared memory to pass information between tasks it’s less of a problem. The reason Go’s coroutine model works so well is because it’s coupled with Channels as the main mechanism for passing information between coroutines, so you generally don’t have to worry about unexpected context switches.

The Closure Problem in Python

2012-08-04T22:39:58+00:00

I’ve seen several posts now with people complaining about the following python code:

>>> funcs = []
>>> for i in range(11):
        def func(x):
            return x + i
        funcs.append(func)

>>> funcs[1](5)
15

Most people first looking at the code would expect the value of funcs[1](5) to be 6, which it is clearly not, but I’ve found many confusing and sometimes just wrong explanations for why this is so. I wanted to clarify my understanding of the issue and hopefully provide a simple and clear reasoning for others. Hopefully this is not one of those wrong explanations, and if someone who didn’t just learn about lexical scoping today wants to correct me please do. I also may be playing a little fast and loose with some terminology, so let me know if anything is confusing.

The surprise is the result of two non-obvious python features:

`for` loops do not create their own isolated scope

This is clearly demonstrated with:

>>> for i in range(10):
        j = 5

>>> j
5
>>> i
9

Where you can see that not only is the loop variable i maintained after the for loop, but j as well. This seems like a somewhat questionable design decision to me, but perhaps that’s because I’m primarily a C developer.

Expressions within the body of a function are evaluated when the function is called, not when it is defined

This is also clearly demonstrated with a simple bit of code:

>>> def func(x):
        return x + i

>>> func(5)
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 2, in func
NameError: global name 'i' is not defined
>>> i = 3
>>> func(5)
8
>>> i = 4
>>> func(5)
9

So you can see, even though i didn’t exist with the function was defined, the interpreter happily allowed us to use it in the body of the function, and then only attempted to evaluate it when it was actually called.

Putting these two things together it’s clear why python evaluates our first code example the way it does. The variable i inside the body of the function has nothing to do with the loop variable i until the moment that the function in the array is actually called, at which point python looks up the name i in the symbol table and finds the one that happens to have ‘leaked out’ of the for loop.

Solutions to this issue usually involve forcing evaluation of the variable so that the function references the value instead of the name. My favorite version involves adding the variable as a default value to the function, forcing evaluation at definition time. e.g.

>>> funcs = []
>>> for i in range(11):
        def func(x, inc=i):
            return x + inc
        funcs.append(func)

>>> funcs[1](5)
6

In this version i is evaluated and the value stored in inc when each copy of func is defined.

Now we’re cooking with Closures

OK, so things get a little more complicated when we need to specify where exactly the interpreter looks when it finds a variable in your defined function that’s not local to the function (a ‘free’ variable). As mentioned above, the interpreter looks up a value at the time of the call, but it looks in the scope within which the function was defined. More code!

>>> def inc(x):
        return x + y

>>> def outer():
        y = 3
        print inc(4)

>>> outer()
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 3, in outer
  File "", line 2, in inc
NameError: global name 'y' is not defined
>>> y = 1
>>> outer()
5

So here we see that when inc is called within the outer scope, the interpreter looks up y within the original scope where inc was defined, not the scope from which it was called. After we define y where it is in reach of inc, all is well and happy. This is where closures come into play, because what if the scope in which the function was defined no longer exists? In a language without closure support we’d be out of luck, but with closures those references stick around after the function that created the scope finishes executing.

‘Haskell Spectrograms 2: Array Slicing and Dicing’

2012-05-11T00:29:43+00:00

So we have a vector

Given a vector of audio, the first step in making a spectrogram is to slice up the audio into frames. This slicing process is defined by the frame size and the hop. The frame size is the number of samples in each frame, the hop is the number of samples between the beginning of adjacent frames. For instance, if slicing the vector [1,2,3,4,5,6,7,8] with a frame size of 4 and a hop size of 2, the resulting frames would be [[1,2,3,4],[3,4,5,6],[5,6,7,8],[7,8,0,0]]. Note that the last frame was padded out with zeros because it extended beyond the original vector.

Slicing an Array in Haskell

This is where the variety of vector/array libraries in Haskell started to become a bit more of a drag. hsndfile supports Data.StorableVector or Data.Vector as an output type. The haskell-dsp package (available through cabal) uses the standard Haskell Array type. So my first order of business was to convert my freshly-minted StorableVector into an Array.

import qualified Data.StorableVector as V
import Array as A

arrayFromVector :: V.Vector Double -> A.Array Int Double
arrayFromVector vect =
   let l = V.length vect - 1 in
      A.array (0, l) (zip [0..l] (V.unpack vect))

The above code converts the Vector to a list with V.unpack, then uses the array constructor to create an Array of Double (with Int indexes). Not the most elegant or fast, but effective.

Next we need to take this array and slice it into frames. Lets call that function “getFrames”, which will take a frames size and hop size and give back a list of subarrays of the original array.

getFrames :: A.Array Int Double -> Int -> Int -> [A.Array Int Double]
getFrames inArr frameSize hop =
   [getFrame inArr start frameSize | start  Int -> Int -> A.Array Int Double]
getFrame inVect start length = pad slice length
   where
      slice = A.ixmap (0, l - 1) (+ start) inVect
      l = min length (end - start)
      (_,end) = A.bounds inVect

Getting a subarray in Haskell is a little bit tricky. The Array library provides an “ixmap” function that takes what you want the bounds of the new array to be, as well as a transformation function to get an index into the old array given an index into the new array. getFrames uses a list comprehension to create a list of slices, each of which is created with getFrame using ixmap. The bounds of the new array are 0 and the length-1, the transformation function to get an index into the original array from the new array is just an offset operation. the pad function comes from the DSP library, available through cabal

The Furrier[sic] Transform

Once we have ourselves a list of Arrays, the DSP library provides an fft implementation for real signals called rfft, which returns the complex spectrum of an input array. Applying the FFT to each frame in our list is a simple map operation. Here we compose a getFrameMagnitude function with rfft, which takes the complex signal and gives us something that we can plot as a spectrogram.

getFrameMagnitude :: A.Array Int (Complex Double) -> A.Array Int Double
getFrameMagnitude frame = A.array (0,(l-1)`div`2) \
      [(i,log (magnitude (frame!(i+(l-1)`div`2)) + 1)) | i <- [0..((l-1)`div`2)]]
   where (_,l) = A.bounds frame
main :: IO ()
main = do
   audioVect <- readWavFile sndFileName
   drawSpec (map (getFrameMagnitude . rfft) \
      (getFrames (arrayFromVector audioVect) 1024 512)) "spec.png"

getFrameMagnitude looks a little hairy, but the gist is that we’re using list comprehension to create a new list that’s the second half of the input array, where at each sample we take the magnitude, add one to it, then take the log. We add 1 before taking the log so that the log-scaled output will start at 0, for ease of plotting

Join us next time to see how drawSpec works and actually make some spectrograms!

‘Haskell Spectrograms 1: Loading a Sound File’

2012-05-10T23:19:43+00:00

Intro

So I took it up as a challenge to generate a spectrogram in Haskell. How hard could it be? Turns out that what’s a few lines of python code using numpy and matplotlib took me down quite a rabbit hole.

For the impatient, you can find the finished code at https://github.com/ssfrr/scimitar in the “haskell” directory.

Disclaimer: I am not an experienced Haskell programmer, and I’m likely doing things all wrong. Please correct me via Twitter

hsndfile

I chose to use the hsndfile wrapper around Erik de Castro Lopo’s immensely useful libsndfile to load the file. This immediately forced me into the abundance of vector libraries for Haskell. This was a huge sticking point for me. There are literally about a dozen different libraries that one can use in Haskell to represent a vector of floats (or vectors of anything storable, but I digress).

Luckily hsndfile only has bindings to 2 of them, which cut down my options. I ended up using hsndfile-storablevector, which is available for installation through cabal. Loading a sound using hsndfile looks a little like:

import qualified Sound.File.Sndfile as Snd
import qualified Sound.File.Sndfile.Buffer.StorableVector as BV
import qualified Data.StorableVector as V

readWavFile :: String -> IO (V.Vector Double)
readWavFile fileName = do
   handle <- Snd.openFile fileName Snd.ReadMode Snd.defaultInfo
   (info, Just buf) <- Snd.hGetContents handle :: \
      IO (Snd.Info, Maybe (BV.Buffer Double))
   return (BV.fromBuffer buf)

To unpack this a little Snd.openFile takes in a filename, a mode, and an Info instance (check this out for more details on the individual datatypes), and gives you a handle to the file (wrapped up in an IO monad, of course).

Snd.hGetContents takes a handle and gives you a IO-wrapped pair. The first item is another Info instance that describes the soundfile you just read, and the second might be a buffer (or Nothing). The tricky bit here is that Haskell doesn’t know what type that it’s supposed to be, so you need to make the type explicit with the annotation shown above to make it a buffer of Doubles. The cool thing here is that if the datatype you request does not match the datatype of the original sound, hsndfile will do the conversion for you.

Once you have the buffer of doubles, you use the fromBuffer function to get back a normal StorableVector.Vector that you can do other fun things with. Come back next time for some of those fun things!

libmanta released!

2012-03-24T22:07:06+00:00

(photo nabbed from MusicRadar)

After more than a year(sporadically), several re-writes, and much learning about USB, cross-platform threading, concurrency, OSX device driver loading, and many more, the libmanta library and the included PD and Max/MSP objects are finally ready for release.

Get The Source Read The Documentation

libmanta is a cross-platform API for the Snyderphonics Manta control surface. The low-level USB communication uses hidapi to communicate with the Manta, and provides a way to subscribe to the different events the Manta can generate, as well as methods to set the LEDs.

There are currently binaries available for Pure Data on linux and OSX. Max/MSP binaries should be available shortly, as soon as Jeff (the inventor of the Manta) finishes the help patch and a wrapper that gives the new libmanta-based object the same interface as the old one.

gendy~ PD + Max/MSP object and libgendy 0.6.0 released!

2010-05-17T13:52:16+00:00

I’ve been working off and on for a bit on a C++ library to implement a variant of Dynamic Stochastic Synthesis, a technique developed by Iannis Xenakis. (For a great history and more details check out Sergio Luque’s thesis.

The library is still pretty rough around the edges and more or less completely undocumented, but the PD object that uses it should be pretty functional. Included with the code is a helpfile (gendy~-help.pd), as well as a gui (gendy-gui.pd) that should make it pretty easy to jump right in.

The basic idea of DSS is to describe a waveform with a set of “breakpoints” and interpolate between them to generate the actual audio signal. The set of breakpoints forms a single cycle of a waveform, and each time one cycle gets played, the breakpoints each move for the next cycle. So each breakpoint ends up on a two-dimensional random walk.

One improvement I’ve made to some traditional DSS implementations is the use of cubic spline interpolation instead of linear, which improves the aliasing considerably. It’s not a truly bandlimited signal, but is differentiable.

The other modification is the introduction of selectable center waveforms that the breakpoints will gravitate towards. Right now I only have flat, square, and sine implemented, but I’m planning on including basic triangle and sawtooth as well. The “h_pull” and “v_pull” controls effect how much the breakpoints are pulled towards the center waveform.

The external requires Thomas Grill’s Flext library. Once you have it installed simply run

FLEXTDIR/build.sh pd gcc

From the base gendy directory (Where FLEXTDIR is the location of your flext install) and you should have a shiny new binary in the pd-linux directory. The arguments to build.sh will vary depending on your system.

Downloads: Source Tarball x86_64 PD Binary

LTSpice Tutorial #1 - Basic Schematic Capture and Simulation

2010-04-20T22:53:18+00:00

This is the first in a series of tutorials intended to introduce LTSpice to the uninitiated. LTSpice has some rather unusual interface conventions that take some getting used to, but it’s an incredibly powerful tool that’s available for free!

The first step is to download it from Linear Technology’s website.

Unfortunately it’s a windows-only application, but the main developer, Mike Engelhardt has gone out of his way to make it work well under WINE, so Linux users aren’t left out of the fun.

In these tutorials I’m going to spend more time talking about using LTspice specifically rather than about the electronics themselves, so I will sometimes assume a certain level of circuit design knowledge.

Adding Components

When you first start LTspice you’re presented with an empty workspace. The first thing to do is pretty CTRL+n to open up a new schematic. Then we can start placing parts.

We’ll start our circuit with a simple ideal voltage source. F2 brings up a library of components divided into folders, we’ll leave most of them for later. The ideal voltage source we’re interested in is located in the default folder, so you can either scroll over to it or begin typing “voltage” into the text field and it will be selected. Press ENTER or double-click on “voltage” and you’ll see the window disappear and your cursor change to the voltage source icon. Click once on the left side of the screen to place a voltage source, then either right-click or press Escape to go back to selection mode.

You don’t have to go to the library for all components. Pressing r, l, c, d, or g will change your cursor into a resistor, inductor, capacitor, diode, or ground icon, respectively. You can rotate the cursor by pressing CTRL+r, and place the components with your trusty left mouse button. As before, right clicking or pressing Escape will get you back to the default mode.

Press ‘r’ and place two resistors one over the other, as in the schematic above. Press Escape or right-click to finish.

Now press “g” and place two ground points as above. As in most schematic capture software, all the ground connections are considered to be wired to each other, and always provide a ground reference that reads 0V. Any voltages measured in the circuit are relative to this ground. You also always need at least one grounded node in your circuit.

Moving and Deleting

Occasionally you will make a mistake, and want to delete a part or move it from where you originally placed it. LTspice follows the UI convention that first you specify an action, and then you select the parts you want to act on. To delete parts simply press your Delete key, then click on the items you want gone. You can also box-select around a group of items to be deleted.

To move items, press F8, or click the closed fist icon, then click on the item you want to move, and you can place it anew. You can also press F7 or selected the open hand icon, which will also move components. The difference is that the closed-fist version will also drag along any connected wires, while the open-hand will leave them be.

Wiring it up

Press F3 to change your cursor to crosshairs, and you’re ready to wire. Simply click where you want the wire to start, then click again where you want it to end. You can click at any point on the canvas to put add intermediary points. Holding down ‘ctrl’ lets you put diagonal wires while still snapping the endpoints to the grid.

Go ahead and place the wires as in the above picture.

Changing Part Properties

Once the components are placed, right-click on the component icon to change its parameters. You can use SI prefixes like k(kilo), m(milli), and u(micro), but you have to use MEG for mega.

Set the resistance of the two resistors to 500k and 1MEG (ohms), and the voltage source to 10 (Volts).

Simulation

Now we actually get to see what SPICE is all about: Simulation.

Click on the little running man icon on top to bring up the simulation menu. For DC circuits you’ll want to click on the “DC op pnt” tab and click OK. This will find out the steady state of your circuit. The first thing you’ll see is a text list of the voltages at all the nodes and the currents through each component. It’s not immediately obvious which node is which, so if you close the text window you can just let your mouse hover over a node or component and see the pertinent info on the status bar at the bottom.

A note about currents: Watch your signs! When you hover your mouse over a component, the current is taken to be positive if it is running down or right, and negative if it is running up or left.

Next Time

Hopefully this basic example has introduced you to the most basic elements of LTspice. As we continue I’ll introduce more sophisticated simulation types, parametric sweeps, and more!

A cute python scheduler

2010-03-03T01:29:57+00:00

I spent a couple of hours on Sunday whipping up this little scheduler in python.

It was mostly to have something fun to do in Python, and doesn’t do much that’s useful, but it does demonstrate some general process scheduling concepts.

It provides base classes for “Processes” and “Events”. Subclass a process to do something when it’s “run()” function is called. A process can also tell the scheduler that it wants to wait on an an “Event”. Any event that has a process waiting on it gets its “occured()” function polled, which returns true when the event has occurred, and the process that was waiting on it wakes up(it’s run() function starts being called again).

I’ve got some examples of a timer event that goes off after a time interval. There’s also a filewatcher event that goes off when a given file is created.

This is meant to simulate a scheduler that would run at the root of an OS, so it loops through as fast as it can and will take up %100 CPU while it’s running.

git clone git://github.com/ssfrr/pysched.git

Download the tarball

Back from Tour!

2009-07-07T13:05:46+00:00

Just a quick announcement that Capillary Action has finally returned from our ridiculous 4-month US-UK-Europe-US tour (except for 5 more east coast dates in another week and a half).

It was long and amazing and draining and eye-opening, and now I’m glad to be home.

My next project is to stop starting new projects and work on documenting the work I’ve already done, so check in soon for updated/better info!

Volume management without Nautilus

2008-11-21T16:40:05+00:00

So I’ve been playing around with WMII for a while now, soaking in the glory of tiling window managers. One thing that’s a bit inconvienient is easy automounting. I don’t want to have to manually create a directory in /media and mount each and every teeny-tiny usb drive I might plug into my system.

Turns out that recently the Ubuntu/Gnome folks have decided that Nautilus will be handling the automounting of drives and such instead of the gnome-volume-manager. This is all well and good if you’re using nautilus, but for console-junkies it’s not so helpful.

The gnome-volume-manager package in the repo is compiled with the “—disable-automount” configure option, so to enable it we have to recompile:

First make sure you have all the required libraries to build:

sudo aptitude build-dep gnome-volume-manager

Then download the source:

apt-get source gnome-volume-manager

configure:

cd gnome-volume-manager-2.24.0 ./configure --enable-automount --disable-dependency-tracking

build and install:

make sudo make install

Then just add /usr/local/libexec/gnome-volume-manager --sm-disable to your startup script and you should be up and running.

Don’t forget to use gnome-volume-properties to configure the volume manager to actually automount.

My first openembedded image

2008-10-17T04:43:16+00:00

After installing openembedded from these directions, I’ve successfully compiled the helloworld-image target and have it running on my beagleboard! After running bitbake helloworld-image and bitbake virtual/kernel and finding something else to do for a few hours while everything compiled, I had a usable rootfs and kernel image. I already had my SD card partitioned, so I just erased the old Ångstrom image and copied the new stuff over.

To install the image to the SD card (Where BUILDDIR is the directory form which you ran bitbake, MMC_BOOT is the boot partition on your MMC card, and MMC_ROOT is the root partition:

Go to BUILDDIR/tmp/deploy/glibc/images/beagleboard
cp MLO-beagleboard /media/MMC_BOOT/MLO
cp u-boot-beagleboard.bin /media/MMC_BOOT/u-boot.bin
cp uImage-beagleboard.bin /media/MMC_BOOT/uImage
cd /media/MMC_ROOT
sudo tar -xvf BUILDDIR/tmp/deploy/glibc/images/beagleboard/helloworld-image-beagleboard.tar

Boot time is about 8 seconds from when it starts to unpack the kernel to executing userspace code.

Installing PDa to the beagle board

2008-10-08T15:33:06+00:00

Well, today I got Günter Geiger’s PDa version of Pure Data compiled on the Beagle Board. I haven’t gotten HDMI output to work properly to my TV so I’m relying on X-forwarding for the GUI, which is pretty painfully slow at the moment, but I did get some sound out. Here are the steps I took:

Install libtk-dev and libtcl-dev packages using opkg. I had to use the -force-depends option because opkg complained about some missing dependencies. Hope it doesn’t come back to bite me later.
Install the compiler packages gcc and gcc-symlinks
Download the source code from here.
Unpack the source into a directory of your choosing
Edit the makefile in the src subdirectory and change libtk8.4.a to libtk8.4.so and libtcl8.4.a to libtcl8.4.so
type “make”

You should now have a pd executable in the bin subdirectory.

the arrival of the beagle board

2008-10-05T17:51:51+00:00

I have just received a beagleboard, flyswatter JTAG, 4GB SD card, USB ethernet adapter, and USB hub. Everything I should need to get started with embedded development.

I created the proper filesystem setup on the SD card as per these instructions, and installed koen’s demo image for the Ångstrom embedded linux distribution.

After hooking up the Flyswatter to the serial connector through the Flyswatter/Beagleboard adapter I got a boot prompt. My TV is complaining that it doesn’t recognize the input format, so I’m probably going to have to figure out a custom modeline in the xorg.conf, but I can live with a command prompt for now.

For those unfamiliar, the Beagle Board is a platform for embedded development based on Texas Instruments’ OMAP3530 System-on-chip board. Basically it’s a computer three inches square. It has handy input and output connectors for easy experimentation. Stay tuned for updates.

official launch!

2008-09-28T20:02:53+00:00

As of 4:00pm today my old Columbia site has been decommissioned and redirected to this one. The site is dead, long live the site.

Stay tuned for more frequent posting, now that I’m getting a couple projects off the ground and I’m pretty much done futzing around with the site layout/architecture.

recent/upcoming performances

2008-03-19T14:30:30+00:00

So it’s been a while since I’ve posted any info here. Since a recent re-wire of the sensorBib to switch all solid-core wiring with stranded(a mistake I will not make again), I’ve been working on putting music together to perform on my new sensor-augmented upright bass. My premier performance in Columbia University’s Dodge Hall was a smashing success. I was also able to do an in-class demonstration for George Lewis’s course “Jazz in the Global Imagination” that included a short group improvisation alongside George, with Mario Diaz de Leon and Steve Lehman. A video of the event will be posted soon to Columbia’s new jazz website, Jazz Studies Online.

On Thursday March 27th I’ll be performing alongside New York jazz drumming psychopath Kevin Shea, with a possible third member as yet undetermined. We’ll be performing as part of the Columbia Computer Music Center’s “CMC Fün Nite,” a monthly concert series to perform new electronic music. If you’re in New York City you should come on up to Prentis Hall at 632 W. 125th St.

it is finished(sort of)

2007-09-03T14:28:07+00:00

I finished the hardware portion of my sensor array right before I left for a tour and recording session with Capillary Action, but didn’t get a chance to post pictures, so here they are, only a month late. In the coming weeks I’ll be working on refining the PD patches that do the actual audio processing, as well as doing some composition. Keep an eye out for new videos and mp3s.

paper pattern

2007-07-19T14:24:17+00:00

I successfully printed out my pattern onto a bunch of 8.5x11 sheets of paper, taped them together and cut them out. I taped the patterns onto my bass to make sure that it all fits the way my model said it should, and so far so good. This also let me figure out exactly where I wanted to put the electrodes, MouseTrap boxes, and the Arduino on the bass itself, in places where the copper would be easily accessible, but the sensor boxes wouldn’t be in my way. I also tried to keep the boxes on the sides of the bass, to minimize their effect on the bass’s resonance. Now it’s off to a fabric store and then to track down a sewing machine.

bib design

2007-07-17T14:20:51+00:00

I’ve been playing around in Blender and QCad to figure out how I want to mount the sensors onto my bass, and I’ve come up with a design for a cloth covering that will house the sensors in pockets on the bass. Much thanks to Chromo for reminding me of those bass bibs that some players use. This will allow me to remove the sensor apparatus if I want to play acoustically, and also to non-permanently mount the sensors onto a different bass if I’m traveling. I put together a sewing pattern, so as soon as I get to a fabric store and select a cloth, I should be able to sew this up without too much trouble.

video with 5 sensors

2007-07-13T14:10:29+00:00

So now that I’m mostly done with the physical design part of this project, I thought it would be a good time to whip up another video demo to show it in action. I’m using a couple of custom abstractions that I’ve made make the sensor data as usable as possible, but the software processing is still very much in development, so I’ll put some releases up once I have something a little more stable. For now, enjoy the strange sounds coming out of your computer speakers and let me know if you have any suggestions. The sound translates pretty poorly to laptop speakers, so you might want to use headphones or external speakers to hear what’s going on.

5 boxes done

2007-07-09T14:05:50+00:00

I built 5 more sensor circuits and boxed them all up in these snazzy black boxes you can see in the picture. They even match my ThinkPad! I’ve been working on PD patches to explore different ways to map the sensor streams onto parameters. On Douglas Repetto’s suggestion I started looking at higher-order systems, and realized that if I look at the change in adjacent sensor samples, throw out high positive and negative values, and then run them into an accumulator, the output tracks slow-moving input, but ignores anything fast. This allows you to pump the value up or down by repeatedly moving slowly in one direction, than quickly in the other. You can also make a value stick if you pull your hand away quickly enough. Be on the lookout for some video examples. I also made a patch to detect when you’ve tapped the sensor, to be used for things like setting a tempo or delay time.

enclosed

2007-07-06T14:04:31+00:00

Nearing some sort of finality in this design, I’ve put the circuit in a box. I also put my arduino board in a box, which involved de-soldering the power connector and the header sockets, as well as cutting off the corners with a bandsaw, so I would probably advise using a bigger box if you’re planning on doing the same. Hopefully in the next couple of days I’ll give the main MouseTrap info page an update with the new developments, as well as part numbers for the boxes and all the connectors I used. I decided to go with a standard DC power jack, banana jacks for the DC output and ground, and a binding post to attach the electrode. Definitely an improvement. The boxes also have a solid feel to them without being heavy.

new pcbs!

2007-07-02T13:18:35+00:00

I received my 10 PCBs from Advanced Circuits today. They’re a big step up from the ones I’ve been making on the CNC machine, mostly because I don’t have to worry about solder bridges. The completed circuit you see in the picture worked the first time after putting it together, which was a lot nicer than the 20 minutes or so I had to spend after each CNC prototype fixing my sloppy soldering. They also gave me a circuit board coaster and 2 bags of microwave popcorn. You can see I’ve drilled out the corners so that they’ll fit in the project enclosures that I bought from Mouser. Construction details to follow…

new audio demo

2007-06-26T12:31:51+00:00

I put together something a bit more sonically interesting than the video that I posted earlier. I recorded myself improvising on double bass, and then processed the recording with a puredata patch that I wrote to use the 3 sensors that I have built so far. It’s pretty bass-heavy, and not EQ’ed or anything, so it probably won’t sound good on speakers without good bass response. All of the processing was done in one pass, and the only interface between myself and the computer was the 3 sensors. So if I had the sensors mounted on the bass, I could theoretically have performed this live with no pre-recording. The patch requires my granulator external, which is downloadable on my PureData page.

note - this used to be available at api.soundcloud.com/tracks/14146648 but it seems to be removed now

New video up

2007-06-23T14:40:30+00:00

Here’s a quick video I made of me waving my hands around the MouseTrap sensors, and sending the data through an arduino board into my laptop running puredata. The video footage was pretty out of sync with the audio, which is why there’s more screen capture than video. All that the patch is doing is modulating the amplitude of 3 oscillators running at 400, 500, and 600 Hz. Soon I’m going to set up some sort of media gallery so that there’s a more permanent home for things like this, but this is it for now.

3 sensors built

2007-06-22T14:40:15+00:00

I’ve got 3 of the MouseTrap distance sensors built, and I have just a little bit more tweaking before the the design will be ready. The blue board that you see the sensors connected to is an Arduino, which converts the analog signals to digital numbers and sends them to my computer over USB

rev3 board milled and stuffed

2007-06-12T14:15:20+00:00

Today I milled out Revision 3 of my MouseTrap board, after realizing some mistakes in Rev. 2. After stuffing the board I’m happy to announce that it seems to be working great! I had to change some component values because the PCB acts differently than the breadboard, but performance seems good. One of the pads ended up being connected to an adjacent trace, but I moved it over a bit in the newest board layout, so we should be ready to go.