BPMinus 0.1.7 is live with the auto updater!

BPMinus

BPMinus has been getting steadily better since I released the first beta a little while ago. I believe I’ve had three intermediate releases that fix a whole bunch of bugs and crashes. The current version is 0.1.7 and it includes all sorts of things that make setting Loop Start/Stop points feel much more natural. Right now, the big beast I’m battling is in the realm of optimizations. I’m trying to address a couple of performance issues, but they’re a bit challenging. Look for more on that front soon.

WPFSVL on CodePlex has been updated.

WPF Sound Visualization Library

Along with BPMinus changes, I’ve made some fixes and improvements in the WPFSVL. These were mostly made to address issues in BPMinus. There were a lot of changes to the TimeEditor in particular. The validation code for time inputs was a little bit wonky, but hopefully that has been improved. There was also a problem with the binding in the TimeEditor theme templates that caused some issues during theme changes. That should be fixed now!

XAML Regions Now in Visual Studio 11

XAML Regions

XAML Regions has been updated – for the first time in about a year! There’s not a whole lot new here, as the update was mainly to add Visual Studio 11 compatibility. However, I did add support for XAML Regions to work in XML files – including your app.config file! I suppose I could call it XML Regions now. I know that will benefit a few of you.

That’s it for now! The upcoming weeks will bring more BPMinus updates. Enjoy!

BPMinus

Today, I am very happy to release BPMinus to the public. BPMinus was a tool I thought of creating a number of years back, being very dissatisfied with the the current time-stretching tools on the market. A while passed, and I was still sorely disappointed with the tool offerings out there. I decided to get to work. Very quickly I realized that this was a bigger project than meets the eye. There was a lot to understand about audio processing and even more to understand about how to create a nice user experience in such an application. BPMinus is still not a final product. I’m releasing it to the world as a beta so that I may obtain feedback, fix bugs, and implement new features with the helpful guidance of the community.

So, what does BPMinus do? BPMinus will slow your music down without changing the pitch. This is a fantastic way to practice, transcribe, and understand fast-paced and hard-to-learn songs. That’s not all it does, but it’s what I (and most people) will use it for. It also does pitch correction, analyzes BPM, and more.

The journey has been an interesting one. I started out creating the different controls I thought I would need in my application. That spawned into a fun open source project called the “WPF Sound Visualization Library.” I’m happy that a number of people out there are getting some great use out of my controls.

At some point after I had plastered my sparkly new controls on a Window, I had to start thinking about how BPMinus would become an actual usable program. This is where I must give a heartfelt and sincere thanks to my drum instructor, Dave, who was instrumental in helping me figure out what sort of features would be useful in a music classroom setting. I still have a number of his ideas in a big list to implement, but he has helped me turn BPMinus into something I hope music teachers and students will come to really appreciate.

Download BPMinus Now!

WPF SVL Has New Controls!

It’s been a long time since I’ve contributed anything to the code world, but this drought is coming to an end. Soon I will be launching a little application for musicians that I’ve been working on casually over the last year or so. As part of that effort (of which you will hear more soon), I’ve updated WPF SVL with a few new controls! As always, the controls are open source and free to use in your own projects (professional or personal)!

The Equalizer

The Equalizer Control

The first new control is the equalizer. The equalizer is really just a fancy collection of vertical sliders with a few other niceties that are illustrated in the various theme files. The control’s value is an array of floating point numbers (with an element for each equalizer band) that allows you to simultaneously get and set all equalizer values.

The Digital Clock

The Digital Clock

Next up we have an LED-style digital clock display control. A lot of audio applications feature a running clock, so I thought I would introduce my own version of a fast-rendering digital clock to WPF.

The Time Editor

The Time Editor

Finally, we have the TimeEditor control. One of the most obvious holes in WPF’s default control library is a numeric spinner control. This is a play on that control with fields for hours, minutes, and seconds (up t o 1/100th of a second). I’ve taken a stab at masking input and validating time logic (e.g., no more than 60-seconds per hour).

Grab the new controls on the WPF SVL CodePlex Site!

Phillip Givens' Blog

Hello, everyone. It’s been a while since I’ve posted anything. I have some great new stuff to reveal soon, including some nice updates to WPFSVL! However, for the time being, I’d like to redirect your attention to the blog of Phillip Givens. He’s started out with a nice article on XAML. Not XAML in the context of WPF, Silverlight, or any particular language – but XAML as a standalone language. Of course, most of us use XAML in the context of some sort of presentation framework, but it is a powerful markup language that should be evaluated for its own merits. Check it out!

WPFSVL Now Has NAudio Examples

By popular demand, I’ve added an example of how to use the WPFSVL with NAudio as the sound engine powering it. I’m still plugging away at the “getting started” documentation for both BASS and NAudio, but if you get the latest source for WPFSVL, you’ll now have an example application to work from. The way I do sample updates and stereo FFT updates is actually a bit different from anything included in the normal NAudio examples, so I encourage you NAudioers to check it out. The normal examples do FFT at every complete sampling. I have it set up to only do FFT on request from the spectrum analyzer, so my performance seems a bit snappier than other NAudio sample applications out there.

I haven’t had as much time to work out the kinks in the NAudio example, so let me know if you’re seeing anything odd. I know I’m still struggling with certain MP3 files returning strange level data on the waveform. Also, since NAudio is managed code, the performance isn’t quite as snappy as the BASS examples (but still quite decent).

Get the WPF Sound Visualization Library at CodePlex

WPF SVL supports themes/templating!

I’ve just launched my first CodePlex project, The WPF Sound Visualization Library. This thing is actually an extension of the Spectrum Analyzer control I made and part of a much larger secret project. Essentially, I’m taking all the WPF controls I’m creating in my other big project, dumping them out to their own project, slapping an MIT license on it, and releasing it to the public. They all have the common theme of being controls related to sound visualization/playback. Everything was designed so the look could be customized. I’m always looking for ways to improve their flexibility, so if you have ideas, let me know.

Stereo Waveform Timeline

Introducing The Waveform Timeline

First up is a Waveform. I’ve seen a few people struggling to create these on the BASS forums, so I hope this is useful to the community. Right now, it only has stereo support. I hope to support Mono, Quad, and 5.1 channel displays soon. Aside from displaying a Waveform, this thing has the ability to set track position and a repeat section in the audio stream it is rendering.

One of the challenges in displaying a Waveform in WPF is making sure that it doesn’t kill performance while not appearing blurry. I’ve taken advantage of BitmapCache and some special scaling code so that this is handled well. The Waveform Timeline is broken down into four template parts: the waveform canvas, the timeline canvas, the progress indicator canvas, and the repeat region overlay canvas.

Spectrum Analyzer

Our Old Friend - The Spectrum Analyzer

Next is my old friend the Spectrum Analyzer. Nothing really new to report here. I have lots of detail on this in my previous blog posts. I should note, however, there are a few minor fixes and an added property or two since the last time I posted Spectrum Analyzer source code to this blog.

Album Art Display

Album Art Display - For Those Who Bought Music Before iTunes

Finally, we have an album art display. Basically, it’ll take the album art image (presumably from MP3/AAC tags) and display it in a jewel case. I don’t know how much longer the kids will even remember jewel cases, but I still think they look cool in media applications. I’ve had the Album Art Display in a few of my example applications already, but I’ve refactored it a bit so it was a Control rather than a UserControl.

Check Out The CodePlex Project!

—

The Spectrum Analyzer Control

1. It didn’t support scaling.
2. It was a UserControl, which means that didn’t support custom templates/themes.

These two inadequacies severely crippled much of what makes WPF so great.

Supporting Scaling – Go Go Gadget Vectors!

My first pass at the Spectrum Analyzer was based on a very bad assumption. I assumed, foolishly, that a classic pixel-based rendering loop where I manually controlled the buffers would offer me performance benefits and control that I would not be able to achieve if I used vector-based rendering techniques. When I say “vector-based” I mean rendering Shapes on a Canvas. “Pixel-based” refers to me using a DrawingContext to draw shapes in a fashion similar to how things were done in the ol’ GDI+ days. I’ve left my old post in tact if you want to see how the pixel-based technique was done. Assumption aside, using pixel-based rendering has some consequences when a ScaleTransform gets applied to my control. Basically, things get blurry. It’s the same as resizing an image in Photoshop (that is, in the real world, where we don’t have CSI-like “enhance” commands). Since I’m a big proponent of using ScaleTransforms to “zoom” in on a Window’s content as the Window resizes, I felt like this inadequacy in my control was eating away at my soul.

To set about changing this, I had to first mentally break down the control into vector components. Luckily, the Spectrum Analyzer isn’t terribly complex. It’s essentially a variable number of rectangles laid out horizontally. Then, added to that, is another set of rectangles (of the same quantity) that make up the “falling peaks.”

Spectrum Analyzer - Now With Vector Scaling Support!

Template Support

This brings us to crafting the control as an ACTUAL Control rather than a UserControl. Really, the only component I require is a Canvas on which I can draw all these Rectangles. I’ve set up my Control using the conventional “PART_” naming convention (see TemplatePartAttribute). To actually get the bars or falling peaks to draw, an application author will also need to define the BarStyle and/or PeakStyle dependency properties on the control. Without these, they’ll still technically “draw,” but they’ll have no brush and be invisible.

Here’s an example of a style and template for the SpectrumAnalyzer control.

Revised Control Code
I’ve revised the rendering process a bit. When I first wrote the control code, there was a render method that drew a bunch of rectangles onto a DrawingVisual. Instead of drawing directly, I now just change the coordinates/size of a bunch of rectangles that are stored as fields on the Spectrum Analyzer. I let WPF handle their rendering. Thus, my “RenderSpectrumLines” method became a “UpdateSpectrumShapes” method. Also, since this is now a control, there is no XAML to go along with it per se. However, there would be a default template for it if it were placed in a Control Library. Here’s the updated code:

On Performance / Conclusion
So, where does this leave us? A peak at the Task Manager delivers a pretty telling tale. On my system, the control continues to use very little processor power. What’s even better, however, is you’ll see far less churning of the memory usage. It seems that when you let WPF handle the rendering, it gets to have better control of what sort of buffers get created and how quickly they’re cleared from memory. When we did it manually with our RenderTargetBitmap, we were at the mercy of the garbage collector.

I think there are still a number of controls where one will need to fall back on to pixel based rendering (e.g., a spectrogram), but this one lent itself well to being drawn with vectors. That said, I think the current iteration of this Control is far closer to how one should design their controls for other people to use. People incorporating this into their own applications should find it much more flexible in style, as well as much more performant.

Download Source Code

Our window at normal size

Stretching our window using the traditional scaling techniques

Implementing Scaling

At the heart of this scaling solution, there are two concepts at work. First, there is a LayoutTransform that will be applied at very root-most content element of your Window. Secondly, there will be some resize-detection logic in the Window to determine what sort of scaling needs to happen.

Stretching our window using WPF's ScaleTransform - note the relative size of the window's title bar

Now, in the code-behind, we’ll be creating a ScaleValue dependency property for the ScaleTransform to bind to. This ScaleValue is set whenever the size of the Window changes. The value is calculated based on the current width or height divided by the designed-for width or height. We take the lower of those two values and make that our scaling mechanism. This makes the zoom effect similar to what you’re used to seeing when you use a Viewbox when the StretchDirection is “Both” and the Stretch style is “Fill.”

That’s all there is to it! Beyond increasing the size of your Window, it works surprisingly well when decreasing the window size too, down to a certain level anyway. I find this solution to be robust enough to handle most cases my application, but be sure to read over the next section to understand some caveats.

Caveats

ScaleTransform can cause problems if any of your UI elements are rendered using pixel-based rendering techniques. What happens? Well, when you scale, the bitmap buffers of the controls start to stretch and appear blurry. Luckily, in my experience, very few third party components that were designed for WPF do this kind of pixel-based rendering. Kudos to the majority of WPF control developers for doing things the recommended way. In your own controls, there are a few key areas you need to be aware of where this can be problematic:

1. Controls that use the new CacheMode property.
2. Controls that use DrawingVisuals, RenderTargetBitmap or WriteableBitmap, and DrawingContext to draw.
3. Use of WinForms components in your WPF application.

Dealing With The Caveats

CacheMode: To deal with CacheMode when scaling, you can try using the RenderAtScale property. I do this semi-automatically on my custom controls by including a mechanism to automatically detect what ScaleTransform has been applied to the control. Then, I make the RenderAtScale property the same. I include a “UseAutoScaling” property to allow the control’s user to decide whether or not they want to have this behavior happen in their Application.

RenderTargetBitmap or WriteableBitmap: I have found no great solution for this. If the control is being drawn using these techniques, the only option is to alter the code such that it renders at a higher scale or change it dramatically to use vector-based drawing. Be aware that even if the control is tricked into drawing at a higher resolution, if it is being rendered to an Image, it will still appear blurry. The scale of the Image will also have to dealt with.

WinForms Controls: Stop using WinForms controls! No seriously, you’re killing your application’s memory usage and performance by dropping these into your WPF application.

I hope this gives you all a starting point to making your WPF application scale. It’d be really nice if more applications featured this ability, even if as a user-preference.

Download Sample Source Code

XAML Regions Extension For Visual Studio 2010

Using The Extension

There’s nothing particularly complex about using this extension. I wanted to make it so that people without this extension didn’t have trouble working with code from people who did have the extension. I chose to make it so that XAML regions were defined in XML comments. One would start a XAML region by having a few lines that consist of

Spacing, prefix hash characters, and description text are all generally optional. All of the following uses are supported:

That’s really all there is to it!

Grab it at the Visual Studio Gallery

Updated in 0.4

1. Added the ability to have hash character prefixes (e.g., <!– #Region –>)
2. IAdded the ability to have description text in the EndRegion area (e.g., <!– End Region (Your Text) –>)

Enjoy!

—

A coworker and I were recently talking about doing audio visualization with Windows Presentation Foundation (WPF). One of the more common visualization techniques for music applications is to slap in a simple banded spectrum analyzer. I thought such spectrum analyzers would be easy to find, as they’re included in many applications written in toward all sorts of platforms. A bit surprisingly, however, was that such visualizations in WPF aren’t as common as I would have expected. I thought I could use the rarity of such controls as an opportunity to play around with some fast rendering techniques in WPF. I was fairly pleased with the outcome, so I thought I would share the results.

The Spectrum Analyzer Control

About Playing Audio

If any of you have tried to do anything with audio in .NET, you’ve probably found the out-of-the-box functionality to be pretty limited. WPF has some enhancements in this area, but it is nowhere near some of the alternatives. Going the other way, one may choose to use direct references to DirectSound to get the power they need. However, this leaves it up to you, the coder, to deal with all the scaling back when the user’s machine doesn’t meet the needs. I find it much easier to use some of the third party sound APIs out there who take care of all these gritty details

My “sound suite” of choice is the BASS API. BASS is loaded with features. Along with getting sound set up to play, it also has the ability to read all sorts of file formats, do effects processing, record sound, and more. However, BASS is unmanaged. To interface BASS with .NET, one will need the aptly named BASS.NET. At a passing glance, one may see BASS.NET as a thin .NET wrapper over the BASS API. However, it actually has some very useful additions. Benefits include tag reading support, useful methods for parsing FFT data, and even some visualizers included (but they are targeted to WinForms/GDI+). It was actually the source code for these visualizers that I used as a starting point for this WPF control. BASS.NET’s author, Bernd Niedergesaess (a.k.a radio42), was kind enough to let me share this source code with you today even though he really did all of the heavy-lifting/pioneering for this project during his development of BASS.NET.

The Spectrum Analyzer

Now, I’m not new to writing Spectrum Analyzers. Previous software engineering jobs had me writing controls for Windows-based Spectrum Analyzers in the past. However, these weren’t for audio visualization, but were more for scientific measurements of radio and microwave signals. One of the things I noticed about audio visualizations is that a lot of accuracy is ignored in favor of making the visualizer look and feel in line with what we perceive. I won’t go into great amounts of detail on this, but when you see funky methods being applied to FFT results in the source code, this is probably what is going on. One of the most common examples of this is that FFT data is never displayed on the Y-axis linearly, but rather using a square root function and a scaling factor. Without this, you see most of the visualizer moving very little, except for the occasional large burst of energy. This is NOT how your ears/brain perceive the sound you’re listening to.

So, let’s take a look at what the control looks like in XAML:

It all looks pretty straightforward. Besides the attributes I’ve shown on the control here, I also have included dependency properties to set brushes for the bars and their peaks, as well as a dependency property for the linearity of displayed channel data. Here’s the XAML for the Spectrum Analyzer control itself.

Shockingly simple, no? That’s because the meat of this control is in the code-behind. I’ve chosen to do a more classic pixel-based rendering technique for this UserControl. This is good and bad, but not the norm for WPF development. It’s good because it gives me a bit more control in terms of performance. It’s bad in that WPF is meant to be scaled freely, and now it is my responsibility to make that work well. Now, here’s where the real work happens.