Host Audio Engine Logic

[arakula]

... since its not going to be in C/C++.

Now who would have guessed that SCNR

[obiwanjacobi]

COBOL!

Nah, just kidding. It's gonna be a .NET managed host in C#. Hopefully in Mono (cross-platform). I figured if Microsoft can build a gaming platform in .NET - something the hardcode C/C++ boys said would never work - I figured I could try my hands on a managed DAW

But like I said. It's not about the code, its about the logic.

[arakula]

I figured if Microsoft can build a gaming platform in .NET - something the hardcode C/C++ boys said would never work - I figured I could try my hands on a managed DAW

It surely burns a lot of excess calories (meaning it uses much more precious CPU cycles than necessary), but it should work. Today's computers are more than fast enough for that; in my experience, the host program (which doesn't need to apply extremely time-consuming algorithms) uses something in the range of 1-2% of a contemporary CPU's power, so even if you use managed code to the maximum extent possible, my estimate is that it won't use more than 5%.

[AdmiralQuality]

COBOL!

Nah, just kidding. It's gonna be a .NET managed host in C#. Hopefully in Mono (cross-platform). I figured if Microsoft can build a gaming platform in .NET - something the hardcode C/C++ boys said would never work - I figured I could try my hands on a managed DAW

But like I said. It's not about the code, its about the logic.

Oh dear. Let us know how that goes. (Anybody have any real host or plug-in products running managed C# code?)

I don't know why anyone would choose C# over C++ for an app where efficiency matters (and in audio, it's paramount). Wouldn't you rather program the CPU than the operating system?

Anyway, I'm willing to have my bias dispelled. Prove me wrong! (I am however registering an official "I told you so" at this point. )

[hugoderwolf]

1) Would a sort of double buffering technique be advantageous?
So when the driver calls back to receive a new buffer, the only action you have to perform is copy in a buffer that is ready and waiting...?

This adds latency. Latency sucks. You will probably need SOME buffering, but always remember to consider how much latency everything adds.

Not necessarily, only in realtime portions of the host (say, the selected track you play on). For song playback, you have all the time in the world for prerendering stuff.

If you're doing some fancy parallel processing of tracks, you most certainly need double buffering. I don't think today's state-of-the art hosts perform any plugin processing right in the audio callback. They'll have some sophisticated thread scheduling to trigger parallel rendering and combining of slices (according to the audio routing graph), so that the final output is ready when it's requested.

[obiwanjacobi]

My view is that with the multi-core CPU's available today, the profit is in parallelism - even when that means consuming a little more resources - the experience should be better.

Well at any rate, I will start at humble beginnings and build from there. I do not plan to build a Ferrari off the bat, but a nice Mercedes...

Pump from the driver - sync up midi and audio tracks and get the plugin handling in there. When I'm at that stage I am happy. We'll see what happens after that. I know you need experience (in the problem domain) before you can come up with really clever stuff. Of course I have some idea's right now, but lets prove them valid first

[nix808]

All success man,
it's no small task.
I will soon release a 16 track daw that hosts VSTs,
but I am using MAX/msp.
I was talking about doing it in Usine,
and someone asked me a good question-
why?
what do you see being implemented in ur proggy,
that you don't have currently?
I've got no good reason really,
except I can integrate all my previous work.
The hardest bit for me is saving states.
Like I say- success and i hope it's a rewarding task

[obiwanjacobi]

Thanx!

[nix808]

np-
I'll take it for a spin.
But hmm-
what's your logic(hehe),
why r u doing it?
it's gonna be a business?
Certainly understanding the workings
of processors is in demand,
it will make you very capable.

edit- 1 thing about this buffering:
AFAIK you can avoid buffer swapping to a degree,
if you are willing to sacrifice 1 sample,
you can read a single buffer 1 sample later than it is written

[obiwanjacobi]

I'm sorry - we work on a need to know basis - and you just don't need to know.

I have a open source VST project called VST.NET. To have a code example of something that approaches a real host application, I started coding one some time ago. I would also develop a Host Framework for VST.NET something that is missing now (there is a plugin Framework). We'll I sort of got Midi files loaded and tracks created and it also played (as in generated the correct midi events at the correct time), but I couldn't get the audio to work.

So the simple version will be a code sample and if I develop it further it will be a product for me to use at home and perhaps sell - when its good enough. Main thing is that I want to learn more on the technical difficulties involved. (I believe Hermann developed his Vst/SaviHost for similar reasons.)

Another factor is VST3. I'm currently looking into supporting it and at the same time also fixing the major drawback of my current solution: cross-platform portabiliy. So in order to learn more on the new VST3 interfaces - writing a host and a sample plugin (just porting one of my current sample plugins) would be an educational experience.

[nix808]

Thanks for the detail.
If you need a tester let me know(Mac&Win).
8D

[AdmiralQuality]

Another factor is VST3. I'm currently looking into supporting it and at the same time also fixing the major drawback of my current solution: cross-platform portabiliy.

Well C# won't help you there because it doesn't exist on the Mac.

But whatever, I don't need to understand. Carry on! (But I DID tell you so. )

[obiwanjacobi]

Mono runs on Mac and has COM wrapper support (technology I will use for VST3 interop)..?

Cross Platform - Mono is built to be cross platform. Mono runs on Linux, Microsoft Windows, Mac OS X, BSD, and Sun Solaris, Nintendo Wii, Sony PlayStation 3, Apple iPhone. It also runs on x86, x86-64, IA64, PowerPC, SPARC (32), ARM, Alpha, s390, s390x (32 and 64 bits) and more. Developing your application with Mono allows you to run on nearly any computer in existance (details).

Source

[AdmiralQuality]

Mono runs on Mac and has COM wrapper support (technology I will use for VST3 interop)..?

Cross Platform - Mono is built to be cross platform. Mono runs on Linux, Microsoft Windows, Mac OS X, BSD, and Sun Solaris, Nintendo Wii, Sony PlayStation 3, Apple iPhone. It also runs on x86, x86-64, IA64, PowerPC, SPARC (32), ARM, Alpha, s390, s390x (32 and 64 bits) and more. Developing your application with Mono allows you to run on nearly any computer in existance (details).

Source

Ah, never heard of that. Will look into it. Claims to be compatible with many languages (of course none of which are C++). Maybe I can start writing plugins in PHP. (Joke!)

Let us know how it goes. Frankly I fear all the moving parts and third party dependency of big frameworks like this, but again, ready to be surprised.

[obiwanjacobi]

Ah, never heard of that. Will look into it. Claims to be compatible with many languages (of course none of which are C++). Maybe I can start writing plugins in PHP. (Joke!)

Let us know how it goes. Frankly I fear all the moving parts and third party dependency of big frameworks like this, but again, ready to be surprised.

No C++ because they are all managed languages (compiling into an intermediate language). Those dll's are compiled to the specific platform at either install time or run time (just-in-time-compilation). A common library implements the OS features - parts specific to each platform.

At least that is the way it works on Windows - not very much experience with other platforms yet. I just downloaded my Ubuntu and Mac VMWare images, so...