[music-dsp] my own projects
joshscholar at yahoo.com
Wed Feb 16 20:17:31 EST 2005
Actually I'm using antialised line drawing routines with floating point
inputs. It does the same as the OS X model.
The 16 to one isn't in the line-drawing it's in what you might call
So if the width of 1 pixel represents 1024 samples then it would draw 16
linearly antialiased lines each representing 1/16 of 1024 samples (which
comes to 64 samples). Each antialiased line covers the peak to peak extent
of the samples it represents (with that height incremented by 1 so that if
the extent has a range of 0 then the line is one pixel high).
All of the 16 lines but one of them would be blurred horizontally between
two pixels with different weights each.
When you zoom in far enough that 1/16 of a pixel covers less than one sample
then it has horizontal lines within a sample connected by virtical lines
between pixels. The effect is bright marks at each sample.
There's a brightness control, and the brightness saturates (not
overflowing - that would be bad).
You can also switch between right only, left only (in yellow) or both (red +
green). I don't have a spectrum display in yet. If I turn this into a
product then I'll want there to be an option to have multiple panes with
different views (you can already view one file in multiple windows - there's
a "New Window" pulldown) and to put filters on the view.
In fact I want generally programmable views - write a filter in C++ and see
(and/or hear) it.
At the moment files are memory mapped which is a problem since Windows only
has 2 gigabytes of memory mapped space per process, and there are problems
with fragmentation of the virtual memory space. My plan is to use memory
mapping to access files but to only map in small views, with small windows
into a file mapped at once.
----- Original Message -----
From: "Brian Willoughby" <brianw at sounds.wa.com>
To: "music-dsp" <music-dsp at shoko.calarts.edu>
Sent: Wednesday, February 16, 2005 4:22 PM
Subject: Re: [music-dsp] my own projects
> [ Hey you'all, I threw together a wave visualization program a week
> [ It's very pretty - I plot the peak to peak at 16 times the resolution
> [ screen, with the brightness cumulative and the channels overlaid (right
> [ red and left in green), with and there's a brightness control knob.
> [ the results look like an ocilliscope - it's surprisingly revealing to
> [ the waveform at a higher resolution than the pixel width.
> Sounds like an interesting visualization technique.
> The Mac OS X graphics model, based on PDF, allows for fractional pixel
> coordinates. If you set the step to .0625 (1/16th) pixel and draw line
> segments connecting each audio sample at that stepping, the graphics
> system with automatically anti-alias the resulting waveform. This is also
> rather beautiful, but rather straightforward in that it looks almost
> like a future monitor with more pixel resolution might appear (although
> Your algorithm is a little unique. Is there any height information in
> plotting? You describe combining 16 samples into one pixel width using
> brightness, but is your display one pixel tall or do you assign vertical
> position to the PCM value? Screen shots might help.
> I think the difference between the AppKit visualization and yours is that
> anti-aliasing would hint at the relative positions of the 16 samples,
> your algorithm aligns 16 samples directly on top of each other and then
> next 16 samples are stacked, and so on...
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book reviews,
More information about the music-dsp