hodnick.com

Fluent Silverlight Audio Synthesis API With UI Injection

Fri, 06 Nov 2009 22:34:08 -0600

I’m in the middle of working on my Silverlight audio synthesis API which lets you very easily define audio signal chains. I’ve now built support to include the ability to wire up your UI controls into the “fluent” calls.

Let’s say you have a Slider control in your XAML:

Let’s say you want to play a sine wave that changes its frequency with the Slider’s changing value. All you have to do is this:

StereoPcmStreamSource source = new StereoPcmStreamSource();
source.Input =
   Oscillator.Create()
      .SetFrequency(this.freqSlider, Slider.ValueProperty)
      .SendToMixer();
MyMediaElement.SetSource(source);

You can try an exmaple of this app out for yourself.

I’ve added similar UI “injection” methods for attenuation, panning, and modulation:

Oscillator.Create(120)
    .SetFrequency(this.frequencySlider, Slider.ValueProperty)
    .WaveForm(this.waveFormList, ListBox.SelectedItemProperty)
    .AmplitudeModulate(this.ampHz, Slider.ValueProperty)
    .Pan(this.panSlider, Slider.ValueProperty)
    .Attenuate(this.volumeSlider, Slider.ValueProperty)
    .SendToMixer(this.mixer);

If UI injection isn’t your thing, you can hard-code all these values too:

Oscillator.Create(120)
    .WaveForm(WaveForm.Sine)
    .FrequencyModulate(2, 10000)
    .FrequencyModulationWaveForm(WaveForm.Saw)
    .AmplitudeModulate(50)
    .Pan(short.MinValue)
    .Attenuate(-3)
    .SendToMixer();

Full code and a larger demo app are coming soon.

Azure Lessons from the Trenches

Fri, 06 Nov 2009 15:16:11 -0600

For the past two months I’ve had the fortune of working on an Azure cloud project. Within the Azure technology spectrum, our project team is using a lot of Azure features including web roles, worker roles, storage (table, blob, and queue), SQL Azure, and calling native/unmanaged code.

It’s been quite a wild ride for the last two months.

Azure offers up many new features that can make projects and development easier, but in many ways Azure makes projects more difficult. If our team knew two months ago what we know now about Azure, we’d probably be farther along in the project - and we may have approached the project a little differently.

At the time of this writing Azure is in a “CTP” state, so there are bugs and the technology is subject to change in the near future. However, I think there are some high level takeaways from the technology that you will want to account for on your Azure project:

Differences between the local Azure dev fabric and “live” Azure
Minimize web.config and app.config usage
Visibility into your application
Availability of Azure environments for your team
Deployment time

Azure “dev fabric” vs. the real thing

What you develop on your own computer with the Azure SDK and the Azure Development Fabric won’t necessarily work on the live Azure site. Even better, features of Azure that work on the live Azure site won’t necessarily work on your local dev fabric. For example, programmatic creation of new tables in Table Storage is not allowed in the local dev fabric. We’ve also seen problems where our native c++ code works fine in the dev fabric but won’t run in the real Azure cloud.

This local-versus-live issue also applies to SQL Azure, as it is a completely different animal than SQL 2005 or SQL 2008. The database scripts you use in your local dev environment were likely generated from a SQL Management Studio script wizard (or another 3rd party tool) and likely won’t pass the SQL Azure litmus test. SQL Azure offers a limited subset of the Microsoft SQL Server features you are used to. I guarantee SQL Azure will bark at you about things it doesn’t like in your auto-generated scripts [1]. You are asking for trouble if you run your generated scripts in SQL Azure for the first time the morning before a live demo.

You will need to handle these challenges through frequent test deployments to a live Azure environment. There is no other way to make sure your app works in the cloud than to actually deploy it to the cloud. Make time in your development process to deploy often to Azure and test your features.

Minimize web.config and app.config usage

In an Azure application package, web.config and app.config files are “compiled” into a single package file (.cspkg) along with binary and static content. You deploy that package to Azure and start up your web or worker roles. If you need to make a configuration change to a setting in a config file, you need to re-package your entire Azure application, suspend your Azure roles, upgrade them, and finally spin up your roles again.

This is obviously a lengthy process for an otherwise simple change - especially if you merely need to make a config change on a test site (which you will do very often during development and testing).

In short, don’t use web.config or app.config files for your configuration settings. Instead, leverage the Azure configuration settings files (.cscfg) to store your settings or obtain them from a database table or another storage location. Azure configuration settings can be updated while your Azure roles are running and doesn’t require them to be suspended.

This may be the simplest lesson you can take away from this article. It’s easy to account for and it will save you tons of time during development.

Visibility Into Your Application

When you run your app in the Azure cloud, it’s kind of like driving a car blindfolded: you might get to your destination but do you know if you hit any mailboxes? Since your app is “in the cloud” you can’t obtain any operating system debug output or use any operating system tools to help you see what is going on in your app. Azure provides some logging features, but at the time of this writing those logging features are disabled. The rumor is that new logging features are coming.

Granted, the new logging features may solve all of your problems with visibility into your app, but until those features arrive you will need to provide your own visibility.

I highly recommend using a logging library such as log4net as it will allow you to write diagnostic and error statements consistently from anywhere in your app (including web roles and worker roles). Through configuration you can direct those logging statements anywhere you choose such as database tables.

On our project we’ve favored logging to SQL tables, but you may want to consider logging to Azure Table storage instead as I believe it is cheaper by the byte (please do your own research to verify that). The down side is that Table storage isn’t as easily queried as SQL tables. Logging to text files won’t help much as you can’t really get at them in the cloud.

If the Azure logging features play out nicely, you may want to consider looking at this Azure log4net appender: http://neilmosafi.blogspot.com/2009/01/azure-event-log-and-log4net.html.

Through logging, you’ll be able to get a near-real time snapshot of what is going on in your app.

Availability of Azure environments for your team

Your team will likely have one Live ID and one Windows Azure host for your production app. Windows Azure hosts offer two “slots” for deployment: a production slot and a staging slot. Let’s assume that your production slot is the real .com site and that the staging slot is a “QA” site that you use for beta testing or to give a controlled user base a preview of the next release. For all intents and purposes, both the production and QA slots are always live.

Thus, you will need another slot to quickly and frequently test your app because you won’t want to overwrite or disrupt the live or QA slots. Since each host can only hold two “slots”, you will need another Azure hosting account on another Live ID to do this. At the time of this writing, CTP accounts are free and you can sign up for them quickly and easily. However, when Azure goes live with “v1” I don’t know if that will be the case.

I’d recommend having Azure hosting accounts for each person who will be performing any type of deployment on the project. This could be both developers and testers. You don’t want to risk only having one “deployment guy” since Azure deployments aren’t trivial. Make sure you can pass the “hit by a bus” test [2] for this.

Deploying an Azure app to the live cloud isn’t like creating a virtual directory on an internal server - it requires a Live ID account and only offers two slots per Live ID. In other words, treat Azure accounts and deployment slots as a scarce resource. You will probably be able to allocate them, but they are owned by an individual Live ID and Azure accounts are handed out and controlled by Microsoft.

Deployment Time

I laughed out loud when I saw this message for the first time on the Azure deployment screen:

“90% of the time, this operation takes less than 54 seconds”. It appears that the duration is dynamically calculated and is a real-time system metric. The metric and message may be true, but are misleading. That “Deploy…” button only involves uploading your deployment package and configuration file. It does not account for the time spent spinning up your roles

Spin up time has been highly inconsistent in my experience. By spin up time, I mean the time it takes for your roles to be in a “Ready” state:

Be prepared to get extremely frustrated with the length of time it takes to spin up your roles and how reliably Azure will actually spin them up successfully. Again, I’m speaking from a CTP perspective here and the technology isn’t even “v1” yet, but this is something to watch out for. On a great day, the entire upload and initialization process can take less than 10 minutes. On a bad day, the services may take more than 30 minutes to spin up - or not spin up at all.

This assumes that your code and configuration are correct the first time you upload and spin up the roles. If you find a bug with your configuration or code, you’ll need to suspend the services and start the entire process over again.

For larger, more visible deployments at the end of a development cycle you’ve probably allocated more time for performing a deployment and you can probably cope with a longer deployment if there are any mistakes. However, in the middle of a development cycle when you need to test changes in a live environment and there is a lot of code churn, you will be prone to make mistakes or find bugs in the code or configuration - and you will need to deploy again and again. Be prepared for a lot of frustration.

Are you sure about this?

In conclusion, make sure you are ready to invest extra time into your development process to make sure your Azure projects are successful. Part of the extra time will be due to an Azure learning curve (which I have not addressed here). The remainder (and possibly the majority) of the time will be spent dealing with these issues I’ve talked about here. You will need to weigh this extra time and potential stress against the benefits you will gain from Azure as a cloud host.

[1] Microsoft may provide SQL Azure scripting tools in the future which would help deal with this challenge.

[2] The “hit by a bus” test passes when you can confidently say your project won’t suffer (much) if any of your project team members gets hit by a bus

Another Beginning

Thu, 05 Nov 2009 23:09:20 -0600

It’s late on a week night, I really need sleep, and what am I doing? That’s right - I’m completely overhauling my internet presence.

Welcome to hodnick.com, my new web home.

First off, my RSS feed is still at the same Feedburner location, so your RSS reader should pick this major change up just fine. For those of you keeping score, the Feedburner url is http://feeds.feedburner.com/kindohm.

Now, why have I made this change? Kindohm.com hasn’t gone away - it’s just not going to host my “blog” any more. Kindohm.com still hosts all of my old blog content for the time being. The main reason for this is so that permalinks to old posts don’t break and so that Google and all those old articles can still be friends.

Why am I moving my blog to hodnick.com? The main reason is blog/content management software. Kindohm.com uses the Subtext ASP.NET blog engine, and I just don’t want to use it any more. It’s an outstanding application but it just doesn’t have the support and flexibility I’m looking for. Plus the app dominates my domain in an ASP.NET sense. Getting custom ASP.NET web apps to run in sub-directories is a challenge sometimes.

Hodnick.com is running on Tumblr.

Someday, I’ll probably remove the Subtext app entirely from kindohm.com. Jake suggested generating static, archived content from the Subtext database to keep the old article urls intact. I’ll tackle that at some point…

If you view the new landing page of kindohm.com (http://www.kindohm.com) you’ll see a little bit of information on kindohm.com’s new purpose. It’s really going to be my app server from now on where I’ll dump code and apps.

That about brings you up to speed. Hopefully nobody will get lost in the process. There are a few quirky remnants hanging around from when I started my Tumblr account originally, and those items will probably sneak in to the RSS feed. Sorry for that :)

Code

Thu, 05 Nov 2009 21:19:00 -0600

I’ve been writing software on the Microsoft platform since 1998. Today, I develop web and desktop applications using Microsoft .NET. In all honesty, as long as my computer has a text editor and a compiler or interpreter, I’m happy.

I work for Inetium in Bloomington, MN. We focus intensely on Microsoft technologies and specialize on Microsoft’s SharePoint and CRM products. We also provide application development, infrastructure, and business consulting services.

For the last 5 years I’ve focused heavily on Microsoft SharePoint. SharePoint often scares a lot of developers away. That’s understandable. It’s a huge product with a lot of features that are hard to understand. It also makes a developer’s job a living hell. If you can tame this beast of a product with code, then congratulations my friend, you have a rare and valuable skill!

What really gets me excited about going to work these days? For good old HTML, you can’t beat jQuery and Javascript. For fancy stuff, it’s Silverlight. I’m a web guy.

If you’re interested in a taste of my work, check out the app links on this site (currently on the left-hand nav area).

Bio

Thu, 05 Nov 2009 21:16:00 -0600

My name is Mike Hodnick. Let’s see… where to start… this web site of mine is a mix of personal and work-related stuff. Here you’ll find anything from technical, work-related blog posts to new music I’ve worked on. This site really is a gateway to the rest of my life (well, at least what I choose to put out on the internet), so browse around and take a look at whatever you like.

I’ve worked for Inetium since the end of 2004. Inetium is a Microsoft partner in the Twin Cities area, and we develop and consult primarily on Microsoft’s SharePoint and CRM products. We develop intensely on Microsoft’s .NET development platform and bend (and often times break) SharePoint until it submits in agony.

Prior to Inetium, in 2002 I worked as a Lead Developer at Nextel Partners (no longer in existence) building intranet ASP.NET web applications - oh the days of .NET 1.0. Before Nextel Partners I worked at Alto Consulting - a Microsoft partner in the Twin Cities area. Before Alto I had an engineering career in the manufacturing sector. I worked as a Manufacturing Engineer at a small circuit board shop in Hopkins, MN named Advanced Circuits - which was bought by Allied Signal, which merged with Honeywell, and then completely shut down shortly after I left. Prior to Advanced Circuits/Honeywell I worked at United Parcel Service in their Industrial Engineering department - where I actually did classic ASP programming against SQL Server 6.5. All of my gigs have been in the Twin Cities area.

I grew up in Duluth, MN and lived there for about 25 years. I went to Duluth East High School and graduated from the University of Minnesota Duluth with a degree in Industrial Engineering. Despite that the only Comp Sci class I took in college was Fortran, my interest in programming and web technology skyrocketed in college. I loved tinkering with my personal student web site, HTML, CSS, CGI and Perl, and wrote a few Java Applets. I learned Visual Basic 5 on my own, which completely confused me while I was also trying to learn object oriented programming.

These days I live in Chaska, MN with my beautiful wife and daughter, Nicole and Eva. We’ve lived in Chaska since 2003. Prior to Chaska I’ve lived in Crystal, MN and Falcon Heights, MN (adjacent to the MN State Fair grounds).

I write music, play drums, and do a lot of home recording. My main instrument is drums, and I’ve been playing since I was twelve. I also play guitar and bass, am self-taught on those instruments, and it shows. I love heavy music, but will pretty much listen or play anything. Yes, anything. Most people say “anything but country” or “anything but rap”. Country is just pop rock with a twang. Hip hop is just… like no other genre. The best paying drum gig I ever played was a polka gig at a VFW. I’ve played a number of concerts with the Duluth Superior Symphony Orchestra - most notably I played on Rachmaninoff’s Symphonic Dances and Shostakovich’s 5th Symphony. I taught drum lessons for a while but really didn’t enjoy doing it. I’ve also played a lot of jazz gigs around the Duluth area (Duluth has an incredible jazz scene, by the way. Just kidding.).

I’m a Minnesota Wild season ticket holder. I love hockey. I love camping, hiking, and traveling. I’ve at least driven through every US state except Alaska, Hawaii, Louisiana, and Alabama. My right foot is crooked and angles to the outside by about 10 degrees. I have a strange appeal for llamas and alpacas. Some days I absolutely hate technology and want to go live in the mountains. Some days I can’t get enough of technology and don’t own enough computers or know enough programming languages. I like the dark, rain, snow, and quiet. Most of all, I think about how big the universe is and how small the Earth and humans are… and there really isn’t much of a point to living in this blink-of-an-eye life unless you lighten up, barely take anything seriously, and have fun.

HodsAudio

Thu, 05 Nov 2009 20:38:00 -0600

HodsAudio

Sat, 17 Oct 2009 11:28:41 -0500

Thu, 08 Oct 2009 16:07:59 -0500

homies: Homies

Tue, 06 Oct 2009 09:07:39 -0500

homies:

Homies

Id: id

Mon, 21 Sep 2009 16:20:50 -0500

Id:

Chillin on a bench: Chillin on a bench

Mon, 21 Sep 2009 01:50:56 -0500

Chillin on a bench:

Chillin on a bench

0910091926.jpg

Fri, 11 Sep 2009 09:34:42 -0500

0910091926.jpg

Photo

Fri, 11 Sep 2009 09:34:00 -0500

0906091041.jpg

Tue, 08 Sep 2009 22:00:35 -0500

0906091041.jpg

0831091530.jpg

Tue, 01 Sep 2009 09:02:13 -0500

0831091530.jpg

0825091932.jpg

Wed, 26 Aug 2009 03:17:47 -0500

0825091932.jpg

0825091933.jpg

Wed, 26 Aug 2009 03:17:42 -0500

0825091933.jpg

downsized_0816091853.jpg

Mon, 17 Aug 2009 18:19:18 -0500

downsized_0816091853.jpg

0810091911a.jpg

Tue, 11 Aug 2009 22:58:44 -0500

0810091911a.jpg

0810091928.jpg

Tue, 11 Aug 2009 22:58:39 -0500

0810091928.jpg