VST development libraries.

[webmasterpdx]

First, am I on the correct forum or should I get a developer membership and do you have a different forum for developers? I'm a very experienced software engineer with a big interest and education in music. In particular synthesis. One thing I see a lot of is that VSTs and software synths in general take a lot of CPU bandwidth. I was wondering if someone who has more knowledge in the publically available VST libs can answer a question I have. I am aware of the Steinberg SDK. Is that the source that everyone is using? or is there a different one? In addition, is the source code available? I've been thinking that a lot of the CPU bandwidth issues is due to inefficient libraries. I come from a strong embedded software background which gives me unique insight into ways to speed up such algorithms, such as switching from Floating point to integer arithmetic, and finding ways to combine multiple architectural steps into one using techniques like creative algorithm minimization using the psychoacoustic limitations of the human ear, lookup tables, and so forth.
So, please, if you can answer the questions as follows.
1. About the libraries.
2. Source code?
3. Is there room for algorithm optimizations.

What I might do is take an existing synth that uses these libs and then I can rewrite functions in the library and make them MUCH faster.....and then get the managers of that synth to rebuild using my new library to see how well it is improved. I'm just throwing out ideas right now, not promising anything
I'm a software engineer with a degree in hardware engineering (electronics) and about 30 years experience, mostly in embedded systems but I've done just about every level of development, including hardware synthesis (verilog). I know most programming languages and most OS's including RTOS's (real time operating systems).

Ultimately, it might also be cool to take a micro-itx board and use it as a bare RT PC running something like QNX and then porting some package like Ableton live to that platform and then porting VST library to that platform. The result would be a screaming PC that is much faster handling VSTs....making an ideal VST music engine.

Anyways, for starters, I'd love to get my questions answered.

Thanks to all who reply.
-Donald

[Xenakios]

This is the more correct forum :

http://www.kvraudio.com/forum/viewforum.php?f=33

Most commercial grade VST plugins (and host applications) are closed source, so you won't have anything from them to start working on. The Steinberg VST SDK is just the plugin platform and has no actual (worth mentioning) audio processing code that would affect CPU efficiency from the get-go.

"Porting Ableton Live" is a complete fantasy. Unless you happen to get a job at Ableton and convince them that a port to a new platform will be worth it for them financially...

[Keith99]

I really don't think the libraries are inefficient and I am sure all the optimisations you have described are used. DSP programming is very complex and skilled and anyone capable of that programming is also going to be aware of optimisation issues.

[webmasterpdx]

This is the more correct forum :

http://www.kvraudio.com/forum/viewforum.php?f=33

Most commercial grade VST plugins (and host applications) are closed source, so you won't have anything from them to start working on. The Steinberg VST SDK is just the plugin platform and has no actual (worth mentioning) audio processing code that would affect CPU efficiency from the get-go.

"Porting Ableton Live" is a complete fantasy. Unless you happen to get a job at Ableton and convince them that a port to a new platform will be worth it for them financially...

Thank you for the link....very useful.

As for the Ableton thing...yes, you are correct, however, if I am able to do this, I could prove the concept with a public domain/open source synth and if it were successful, I could then offer it to them and they might be interested in using it to do just that....anyways, like I said, is a long long term concept...was just thinking aloud.

Thanks again.
-Donald

[webmasterpdx]

I really don't think the libraries are inefficient and I am sure all the optimisations you have described are used. DSP programming is very complex and skilled and anyone capable of that programming is also going to be aware of optimisation issues.

I wouldn't bet on that. It's been my experience that people who are used to doing PC development dont' think in terms of squeezing every cycle out of their routines. I am also very experienced in DSP development, and things like not using FP operations are rarely done, as are the other optimizations. I could be wrong, but as I said, it's been my experience that PC apps rarely are optimized in such areas. There was only one place where I did see such optimizations and that was for the modelsim verilog simulator by Mentor Graphics. They took over the system allowing a very small time-slot for the user interface to break out of the program, and then ran their own RTOS under the highest priority process and ran their own app under that, thus achieving the advantages of an RTOS while still using Windows.

Anyways, again, is something that I thought might be worth at least checking out, as the most common complaint is that for your typical laptop, the performance of VSTs are not high enough to allow people to synthesize what they want without upgrading to the fastest CPU availale....if I can help in that area, I'd be interested in doing this.

Thx
-Donald

[davidguda]

Going from floating point to integer requires transforming from float to int and then back again for every sample that is being processed if you are still going to be VST compliant. Other then that I suppose you could do everything in integer math instead of ffloating point, if the gains are really that big on modern processors anyway.

"Room for algorithmic optimization"
There are lots of things than can be done for increased performance, and lots of thing are done for increased performance. I would say that most plugin developers constantly have in the back of their minds, "will this be fast enough" whenever doing DSP. Lookup tables are used of course when applicable and when gained from it and psychoacoustic concepts probably in many developers heads at most times as well, at least in mine! I know many incorporate SIMD instructions where applicable and other small coding tricks.
That said there are probably more to be done but unless you are extremely skilled and new thinking don't expect to make revolutionary improvements.

[Caco]

Take a look at LMMS and Linux Sampler which are both open source projects, they should make good examples to act as proof of concept for you to start out with

http://www.linuxsampler.org/

http://lmms.sourceforge.net/

[webmasterpdx]

Going from floating point to integer requires transforming from float to int and then back again for every sample that is being processed if you are still going to be VST compliant. Other then that I suppose you could do everything in integer math instead of ffloating point, if the gains are really that big on modern processors anyway.

"Room for algorithmic optimization"
There are lots of things than can be done for increased performance, and lots of thing are done for increased performance. I would say that most plugin developers constantly have in the back of their minds, "will this be fast enough" whenever doing DSP. Lookup tables are used of course when applicable and when gained from it and psychoacoustic concepts probably in many developers heads at most times as well, at least in mine! I know many incorporate SIMD instructions where applicable and other small coding tricks.
That said there are probably more to be done but unless you are extremely skilled and new thinking don't expect to make revolutionary improvements.

Floating point was just one example. You'd stay in integer. You are right of course, it may not be worth changing from floating point as many CPUs today have floating point in hardware. It depends on the process and what it's doing and if it' using double precision and if it's an ill conditioned equation (in which case it would require FP)....again....just one idea...

On your second point, what you say is true which is why I'd want to concentrate my efforts on the libraries....not in the main app. If I can compile an existing app and double it's performance through library changes, I'd have achieved my goal...

I think that most developers tend to focus on their own code such as their audio engine, and not the libraries....

Thx
-D

[webmasterpdx]

Take a look at LMMS and Linux Sampler which are both open source projects, they should make good examples to act as proof of concept for you to start out with

http://www.linuxsampler.org/

http://lmms.sourceforge.net/

I shall...Thank you very much.
-Donald

[Xenakios]

On your second point, what you say is true which is why I'd want to concentrate my efforts on the libraries....not in the main app.

This isn't going to be possible in 99.999% of cases. The plugins and applications are almost always binaries that you get as they are and you can't just plug in (pardon the pun) some other code for them to use. (Or have I understood you wrong and you want to write DSP libraries for the other developers to use...? You would give your code libraries for free or sell them or so...? I can see a problem with this approach : developers often want to
do their own customized stuff for better integration with their own code bases as well as hopefully to achieve their own unique sounds.)

I think your quest is a bit ill-conceived. A musician who wants the best possible experience for their music making is just going to get the latest and greatest hardware. It's not always possible for everyone to do, but sometimes some limitations on what can be done on the current equipment might even be an inspiration for real artists.

CPU efficiency isn't IMHO the problem with today's host applications and plugins. It's the lack of innovation in the kinds of sound processings that are possible to do(*) and the workflows in achieving them.

(*) For crap's sake, how many "new" equalizers and compressors we are going to see in the coming decades...?

[whyterabbyt]

I think that most developers tend to focus on their own code such as their audio engine, and not the libraries....

Why do you think 'audio engines' arent the audio generation and processing code? What DSP do you think that they're not doing that is instead farmed out to 'libraries' which are being left unoptimised?

[mystran]

One thing I see a lot of is that VSTs and software synths in general take a lot of CPU bandwidth.

Reality check: when something takes less CPU than expected, it's time to add features and/or improve quality. It's not like there's a fixed target to meet with the minimum amount of CPU. It's a question of how much can you do with a given amount of CPU power.

[camsr]

Going from float to int in your signal automatically reduces your dynamic range.

The FPU single type has 23 bits precision for every exponent level, which has 8 bits of range. Each exponent level represents a gain of 6dB starting from 00000001. In reality, this is 762dB of dynamic range for a single precision floating point, with accuracy of 23 bits every 6dB. The best DACs use 24-bit integer datatype, where the incoming floating point must be multiplied by 2^24 and then typecasted by the driver. 24 bits of integer dynamic range is 144dB of dynamic range, linear. This is all that is required for a properly gained analog device.

In other words, unless you need maximum speed from your algorithms, you are sacrificing a lower noise floor by using integer to calculate DSP.

With the FPU, noise does eventually creep in, however it is far different from what happens in integer.
Logarithmically, which is how we perceive volume, the integer has more precision at the top of it's range. The float has the same precision every 6dB, but with a halving of precision per exponent level. How this noise manifests itself through gain change, you figure it out

[Attic]

Go talk to the Synthmaker company Outsim and see if you cant make their stuff run faster after compile.

[AdmiralQuality]

@ OP.