New project: Should it be WPF or WinForms?

Hi,

I'm thinking of starting a new pet project (so not related to my daytime programming job). This project is going to be a DAW, or Digital Audio Workstation type application. You would be able to record audio into multiple tracks, add VST plugins (unmanaged code, so P/Invoke) that can also eventually do MIDI etc.

Now typically these are supposed to be high-performance, as-realtime-as-possible applications doing lots of DSP where every CPU cycle is valuable, so using C# might not seem to be the most logical choice. But for me this is not about whether C# is the best choice or not, but seeing whether it is possible to do it in C# and how much I can get out of it. I love performance challenges, and also .Net programming so something like this is ideal. If nothing else I'd learn a lot about performance tuning C# applications.

Anyway, I have done many WinForms applications (including my current job), but never any WPF applications. Since I have been out of the loop with the latest WPF developments, would this also be a good time to dig in and learn about WPF, or is this just not going to be a good fit? The UI of my application would need to do a lot of screen updates, track scrolling during playback, waveform drawing, VU meter graphics, etc, so not being familiar with WPF, I'm wondering which is better, WPF or WinForms.

I'm using VS 2008 and .Net 3.5.

Any help appreciated.

EDIT: I have done similar projects in the past using unmanaged code, as well as a few smaller DSP projects using C#, so I am somewhat familiar with this type of application. But doing a major application like this in C# is new to me.

IMHO WPF may well be good but as a first app you are going to need time to learn how to use it. do you have the time to do that?

drawing stuff ... well it's DirectX under the hood so that means if the target pc has a good graphics card you get to use that power.

also if you have the time for learning WPF i would also get VS 2010 and .net 4.0 as thenh you have the new bits and WPF for .net 4 has some things improved / fixed *AND* you can use the Paralel and Reactive extensions which may be usefull in this app.

I would guess that this app will be running on a decent pc with a dual core or an i7 cpu etc....

in that case Paralel can help you crunch numbers and stuff.

For an app like that WPF is a better choice. The only reason you'd use WinForms is if you want cross platform support (Mac OS X / Linux), as WPF is unavailable in Mono. WPF is quite different from WinForms, being a retained mode graphics framework, it uses a scene model approach to UI, which allows for simple combination of widgets.

The codebase I work on be similar to a DSP as it makes heavy use of the Fourier transform and friends. Almost all of the ML code I have written in C (also calling routines written in hand optimized assembly). The vast vast majority of time the application is executing within the C code. The .NET layer acts like glue between the C libraries and the model (DB).

Bass said:

For an app like that WPF is a better choice. The only reason you'd use WinForms is if you want cross platform support (Mac OS X / Linux), as WPF is unavailable in Mono. WPF is quite different from WinForms, being a retained mode graphics framework, it uses a scene model approach to UI, which allows for simple combination of widgets.

 

The codebase I work on be similar to a DSP as it makes heavy use of the Fourier transform and friends. Almost all of the ML code I have written in C (also calling routines written in hand optimized assembly). The vast vast majority of time the application is executing within the C code. The .NET layer acts like glue between the C libraries and the model (DB).

If you aren't worried about using too much new stuff all at the same time, I would go with WPF as a learning experience.

I don't have time for pet projects at the moment (I've been at my desk since 06:30 today), but when I get around to my next one, I intend to use WPF.

Herbie

Bass said:

For an app like that WPF is a better choice. The only reason you'd use WinForms is if you want cross platform support (Mac OS X / Linux), as WPF is unavailable in Mono. WPF is quite different from WinForms, being a retained mode graphics framework, it uses a scene model approach to UI, which allows for simple combination of widgets.

 

The codebase I work on be similar to a DSP as it makes heavy use of the Fourier transform and friends. Almost all of the ML code I have written in C (also calling routines written in hand optimized assembly). The vast vast majority of time the application is executing within the C code. The .NET layer acts like glue between the C libraries and the model (DB).

Less is more. Console.WriteLine FTW!

TommyCarlier said:

Bass said:

*snip*

Less is more. Console.WriteLine FTW!

I always have a console interface as well. Actually in one hobby project I am doing (a MUD, written in C#), the GUI actually calls the console interface with the parameters specified.

Thanks everyone for replying. I have been reading up a bit on WPF and it seems it is the way to go. I might as well take the plunge and learn something completely new while starting a new project. Makes sense I think.

BitFlipper said:

Thanks everyone for replying. I have been reading up a bit on WPF and it seems it is the way to go. I might as well take the plunge and learn something completely new while starting a new project. Makes sense I think.

WPF has a pretty big learning curve, so you may want to start with something a little simpler. But it's definitely the future of client apps so you might as well start learning it.

If you need any help once you get going, let me know. I've used a lot of DAW programs but have never written one. It might be fun.

spivonious said:

BitFlipper said:

*snip*

WPF has a pretty big learning curve, so you may want to start with something a little simpler. But it's definitely the future of client apps so you might as well start learning it.

 

If you need any help once you get going, let me know. I've used a lot of DAW programs but have never written one. It might be fun.

Thanks for the offer. Depending on how things go, I might very well come here and ask for help with various parts of the project. I think my first order of business though is to do a couple of small "Hello World" projects using WPF so that I can get the basics down. Just when I thought I knew enough about WinForms, something else comes along...

There is a library called NAudio, that you can find in CodePlex, that allows audio handling for .net Apps,  I use it for recording and playback in a project of mine.  I think that it have Midi capabilities, and certainly will spare you some p/invoking.

BTW: I'd go WPF

raptor3676 said:

There is a library called NAudio, that you can find in CodePlex, that allows audio handling for .net Apps,  I use it for recording and playback in a project of mine.  I think that it have Midi capabilities, and certainly will spare you some p/invoking.

 

BTW: I'd go WPF

Thanks for the great tip. I will check it out...

EDIT: Wow, I just checked out NAudio and it will help me out in a lot of areas! I was dreading having to figure out how to use ASIO but NAudio supports that so it will be helpful in figuring things out, especially from a managed pov.

BitFlipper said:

raptor3676 said:

*snip*

Thanks for the great tip. I will check it out...

 

 

EDIT: Wow, I just checked out NAudio and it will help me out in a lot of areas! I was dreading having to figure out how to use ASIO but NAudio supports that so it will be helpful in figuring things out, especially from a managed pov.

Hi BitFlipper,

Remember that VST.NET also does the hosting part of VST Use the VstPluginContext (in Interop) to load and communicate with managed and unmanaged plugins. Check out the Host VST.NET sample.

Also check out ASIO.NET on code project. No idea if its better or worse than NAudio; its just another option.

On topic: I've seen WPF front ends that take a considerable amount of processor cycles. So make sure you run your WPF app on a good hardware accelerated Graphics Card.

marcjacobi said:

BitFlipper said:

*snip*

Hi BitFlipper,

 

Remember that VST.NET also does the hosting part of VST Use the VstPluginContext (in Interop) to load and communicate with managed and unmanaged plugins. Check out the Host VST.NET sample.

 

Also check out ASIO.NET on code project. No idea if its better or worse than NAudio; its just another option.

 

On topic: I've seen WPF front ends that take a considerable amount of processor cycles. So make sure you run your WPF app on a good hardware accelerated Graphics Card.

Marc,

Thanks for the info, I will check it out as well.

Not sure whether you remember or not, but I was the person that posted on VST.NET about the reverse-P/Invoke trick to allow you to use a single C# DLL as a plugin in an unmanaged host.

EDIT: Thanks for the great link! Just checked it out and yet another invaluable source of information. Didn't know I was going to get this much valuable audio-specific info just by posting to C9, but there you go...

It seems that NAudio only contains WinForms visualizers. Would you (or anyone else) be interested in collaboratng on a collection of WPF visualizers built on WPF?

Bass said:

It seems that NAudio only contains WinForms visualizers. Would you (or anyone else) be interested in collaboratng on a collection of WPF visualizers built on WPF?

Hi there,

NAudio does contain some WPF visualisation. Have a look at the WPFDemo project in the solution. Also the VoiceRecorder project on codeplex uses NAudio and does WPF visualisation.

As for ASIO support, I'm afraid its not ready for the prime time yet. Needs a lot more debugging before it will work with all cards. (does seem to work with ASIO4All though). I did integrate ASIO.NET with NAudio at one point in the past & it worked quite well, although we have moved to a fully managed implementation since.

Finally, you need to know that you will never get really low latencies with .NET due to the garbage collector. A better approach would be to have the audio mixing engine unmanaged and just do the GUI in .NET.

Mark

I believe WPF would be a poor choice for that type of application. You will probably want something with less memory overhead.

sorry to resurrect this old thread but i was wondering how this project is coming along.

i just came across the naudio library and before getting into it too much was wondering if anyone had other recommendations for dsp/audio/midi in .net, preferably open source.

we desperately need a proper audio and dsp library. i've looked into xna and direct x but everything seems geared towards gaming. i also just read about this project to create wrappers for PureData, but no one is doing it for C# yet, but they have it for Obj-C and java. A wrapper for PD in theory would allow the engine to be embedded anywhere that could run native code but interact with it using whatever language you choose. There's currently a java wrapper so it probably wouldn't be too much of a chore to take on. hmm....

@itsnotabug: I haven't looked into it at all, but is WASAPI an option? I have no idea how hard or easy it is to program against.