Jump to content
  • Advertisement
Sign in to follow this  
KillKRT

[.net] Developing a DAW in C# with OpenTK

This topic is 2632 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

I'd like to develop a music environment where users can create their own instruments and effects (using module composition), and also write songs, something like Reaktor and Max/MSP, but with a great/cool integrated sequencer. This application should run on Windows, Linux and Mac OS X.

I'd like to rely on C# because I am quite experienced in .NET programming and I find C# a very elegant and productive language, I would prefer to avoid C++ since even if I'm not afraid of pointers (I started with 68000 assembly! rolleyes.gif), but I hate #define, including, linking and other inelegant stuff, and I think it is not so easy to port code from a platform to another (while in .NET is quite easy).

Since this application should be very attractive and easy to use, I was thinking to create my own UI toolkit library (with animated combobox, circular menu,...) rendered via OpenGL (I think OpenTK could be a choice for .NET wrapper). Same story for audio processing, I was thinking to use OpenAL (OpenTK still be the choice) for audio input/output.

The application must run in realtime, a song could include up to 64 instruments and 8 chain effects per instrument. User can play with a MIDI keyboard it's own instrument with a tolerable audio latency less than 200ms (max).

I was wondering if .NET could be actually a valid option for this kind of application or if, due to performance issues, it should be avoided (thus C++ should be hardly preferred).

So... Why am I talking about a DAW (digital audio workstation) development in a game dev forum? huh.gif Because I think game developer daily fight with performance issues (related to audio and graphics), and so they can say if a language (better a framework) such C#/.NET has some limit!

Thanks!


Share this post


Link to post
Share on other sites
Advertisement
Hey!

Very interesting!

C# is indeed a very elegant language! I do think, specially when you start-off by talking about multi platform dev, that it is not the best solution since the only way to run .NET on linux and mac is mono (imo) and I dont know how performant that would be..
When developing multi platform, C++ is sadly still The language of choice, specially when it comes to performance applications, even more so with DAWs. You will want to have as much CPU for all the buffering and effects that youll have to avoid any translation layer in between and the C# performance killer, the garbage collector. Furthermore, are there any SDKs available for C# when it comes to audio driver integration (ASIO) and plugin support (AU/VST/etc)? Since youll also have to link with an audio interface. Have to admit at this point I dont know OpenAL, so I cant tell you how that works out!

Otherwise, WPF would be a very elegant solution to all your UI needs and implementation would be quick as well. Have you thought about combining native C++ with managed C#?

On another note, 200ms will NEVER work out. Usual latency goes (or should go) down to around 10ms. I can hardly work when I set my buffers to 17ms latency.

Hope that helps!
cheers

Share this post


Link to post
Share on other sites

...

Furthermore, are there any SDKs available for C# when it comes to audio driver integration (ASIO) and plugin support (AU/VST/etc)?


I know that exist a VST SDK for .NET, but I was thinking to not support VST or AU... I know it could be a limitation.


Otherwise, WPF would be a very elegant solution to all your UI needs and implementation would be quick as well. Have you thought about combining native C++ with managed C#?
[/quote]

WPF is only available for Windows system, and Mono team has not plan to include WPF implementation in the near future. Furthermore I think WPF are a little complicated and no so performance oriented. I know implementing a UI toolkit in OpenGL is quite hard, but I just want to try! biggrin.gif


On another note, 200ms will NEVER work out. Usual latency goes (or should go) down to around 10ms. I can hardly work when I set my buffers to 17ms latency.
[/quote]

Yes, I agree, but this is the max latency, I'd like to guarantee latency about 20ms...

Maybe I already know the answer (go with C++), but I was hoping someone said me: "You can do with C#, I create a game with million of spinning and textured polygons and a lot of audio effects computed in realtime and it runs at 60fps!" biggrin.gif Just dreaming...

Thanks!

Share this post


Link to post
Share on other sites

Maybe I already know the answer (go with C++), but I was hoping someone said me: "You can do with C#, I create a game with million of spinning and textured polygons and a lot of audio effects computed in realtime and it runs at 60fps!" biggrin.gif Just dreaming...


No need to dream, you can certainly do this with C#. A million spinning, textured polygons and audio effects can be calculated in realtime, provided you utilize your resources intelligently.

How?
1. By moving as much rendering to the GPU as possible (e.g. use instancing and batch-render polygons as much as possible. Don't issue a separate drawing command for each polygon, that won't work even if you use C++).
2. By keeping your memory graph simple and/or by avoiding memory allocations at runtime (a good rule of thumb is that the GC will run for every 1MB of object you allocate). This is not hard to achieve - preload everything at startup (or level change for games), use structs for temporary objects, use object pools for short-lived classes.
3. By parallelizing what can be parallelized. Move audio processing to a different thread. Use task-level parallelism. .Net has builtin frameworks for that and C# 4.5 is adding keywords to make that even simpler.

C++ can be faster than C# but requires more effort during development - and often significantly so. My suggestion: go with C#, it's faster than people would have you think. Worse comes to worst, you might have to move one or two bottlenecks to C/ASM and p/invoke that through C#.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!