Do you ever think of developing in other languages than C++?

[soundmodel]

I don't like C++. It's unnecessarily complicated.

I'd switch it to a higher level language such as C# or even Python, if it was possible.

Do you ever think of doing VSTs in another language?

[Audiority]

phyton is a scripting language, while C# is interpreted (not compiled). I don't think any of them would be suitable for commercial plugins, even tho C# is actively used for game programming and phyton for sound design / research software.

my 2 cents,
Luca

[PurpleSunray]

Do you ever think of doing VSTs in another language?

No, multiple reasons for it:

- Foodprint. My VST binaries usually have size of between 200kB and 800kB.
I just see no point on forcing the user install 100+ MBs of .NET framework, python interpreter+libs ect to run that little binary.

- Peformance (high level)
While one could argue that C# can reach faster integer-calc performance than C because of JIT compilation, hotspot optimization, ect.... this kind of features are a no-go in DSP because they come with a cost: a lot of management overhead.
JIT compilers, garbage collectors, ... this is all stuff that leads to an (even more) unpredictable behavior when it comes to timing. Your FFT needs to transform that block in time.. not like, the first transform will take 1second because we need run JIT'n'stuff first.. be next will be MUUUCH faster (unless grabage collection runs at the same time .. -.-)
The best thing you can have for DSP is a real-time system. Code that runs on a framework like .NET or Java, with JIT, garbage collection ect enabled, is the exact vice versa of a real-time system. It is unpredictable in every regard when it comes to timings.

- Peformance (low level)
Some DSP coders like to use low-level CPU assembly instructions to speed up certain things.
Try to run SSE/NEON/AVX/... code from your python script

[Miles1981]

C++ is the definite best language for lots of things: performance, modularity, efficiency, big applications...
That being said, C++ is not the best for prototyping, and the learning curve can be steep, depending on the target (pure templates code would be harder than dynamic polymorphism-based apps).

[chroma]

you might be able to get away with a mix of python and C++, but i don't know if i'd recommend it.

python is actually use a lot in the scientific and 'big data' analysis communities, _but_ most of what they run isn't _really_ python... one big strength of python is being able to use other libraries natively, and the reason python is good at numerical analysis is the C++ numerical python (numpy) package.
without the C++ acceleration, python is almost always much, much slower (up to 100x slower) than straight C++, but it works.

It's not a bad model... parts of the code that need optimized go to the fast but more difficult (and dangerous layer, parts that don't need the performance can be implemented in a higher-level, easier to program language (like library management maybe - python makes it dangerously easy to create an sqlite DB on disk, for example). but I'd imagine that in a VST, nearly everything is on the critical path, and it is a lot of overhead to include the interpreter.

[Miles1981]

numpy is pure C code :p

[helium]

Rust would be my first choice. D and Nim would be two further candidates for plugin development. I think at least one person on this forum actually developes his plugins in D.

C# is interpreted (not compiled).

Unlike Java C# always gets compiled before execution. (C# code gets compiled into il, il gets compiled into native machine code before execution.)

[avasopht]

What is it exactly you find complicated about C++? Maybe you could consider coding in plain C for a while.

[PurpleSunray]

numpy is pure C code :p

We should have brought up this point earlier .. if C++ seem to be unnecessarily complicated, why not sticking with C?
Besides performance, modularity, efficiency .. there is one more thing C++ is really good at: it allows you to make easy things, extraordinary complex.
Templates, (multiple) inheritance, operator overloading ... can be cool things, but also bring unnecessary complexity if used just for the sake of using it.
Example?
I need a sine generator...
example C++ approch:
hm.. I need add wavetable class, and wavetable class factory to init with sine, and a interpolation class, which is then used by OSC class which writes to the Amp envelope class... maybe should design a IStream interface, so OSC and Amp cna be replaced .....
example C approch:
void create_sine_samples(float* buffer, int nbuffer, float frequency, float phase);

hope you get what i mean

[foosnark]

In my day job I write C++ and C# regularly, plus a bit of maintaining other peoples' VB and Fortran. Previously, I also worked with Java, and a couple of graphics shader languages and proprietary languages. In my hobbies I write in C and C++. Of them all I prefer C++.

Example?
example C++ approch:
hm.. I need add wavetable class, and wavetable class factory to init with sine, and a interpolation class, which is then used by OSC class which writes to the Amp envelope class... maybe should design a IStream interface, so OSC and Amp cna be replaced .....
example C approch:
void create_sine_samples(float* buffer, int nbuffer, float frequency, float phase);

Your C++ example is just overdesign (unfortunately all too common). I think Design Patterns was one of the worst ideas in the business because it leads people to think "which patterns can I use to do this thing?" instead of "what is the clearest, simplest way to do this thing?"

But it's not something language-specific. It could be argued that C inherently discourages that kind of insanity, but C++ doesn't specifically encourage it.

[PurpleSunray]

But it's not something language-specific. It could be argued that C inherently discourages that kind of insanity, but C++ doesn't specifically encourage it.

I haven't said that You can do that create_sine function in C++ too.
It's more of what you said above - the typical C++ coder thinks like an architect, the typical C coder like a bricklayer.
Now it depends what you want to build.. if you just want to build 4 walls and a roof, you don't need an architect.. actually the bricklayer will be finished with that house while the architect is still working on the preview model.
IMHO most VST plugins fall into the 4-wall and a roof type of program.. no need for an arhcitect, just get the stuff done..
But again.. nothing directly related to C++, but more to the mindset of the C vs C++ programmer.

[avasopht]

I don't think the problem is design patterns, because they are very necessary where needed, it's simply inexperience and bad schooling.

With experience in working with arrays you will have no trouble writing code that works directly on data pointers. With experience in using the right c++ libraries you'll be able to write array-safe code. With experience and proper schooling in using design patterns and OOP you'll know when it is necessary to use each particular feature.

Knowing your std::map inserts at O(log N), meaning inserting M elements is M log N, compared to bubble insert's M*N is one thing, but then there is the wisdom to realize that this particular piece of code you are writing has relatively few inserts so you could just bubble insert.

Software Engineers are often told not to directly access arrays, instead using std::vector or std::array for built in bounds checking, plus safe inserts, which is cool, less error prone, but can cause people to go through hoops trying to adhere to that religiously where it is could / should be ignored (particularly if they have to write C code ).

[avasopht]

I haven't said that You can do that create_sine function in C++ too.
It's more of what you said above - the typical C++ coder thinks like an architect, the typical C coder like a bricklayer.
Now it depends what you want to build.. if you just want to build 4 walls and a roof, you don't need an architect.. actually the bricklayer will be finished with that house while the architect is still working on the preview model.
IMHO most VST plugins fall into the 4-wall and a roof type of program.. no need for an arhcitect, just get the stuff done..
But again.. nothing directly related to C++, but more to the mindset of the C vs C++ programmer.

Good point, when working lower level you tend to think bottom up, high level, top down. I remember this point being made with RosAsm.

[earlevel]

I don't like C++. It's unnecessarily complicated.

You're not going to get the joyful blend of simplicity and power of Python (nor the slowness, fortunately), but for the "unnecessarily" part, have you tried C++11? For me, it made C++ noticeably less tedious. (Further improvement in C++14, but '11 was the biggest increment.)

Of course, with the popularity of C++, you get plug-in frameworks, all kinds of libraries including templates, efficient compilers. So, a nicer language may end up a more tedious development project overall. I guess you know all this—I mainly wanted to point out C++11 improvements.

[soundmodel]

I don't like C++. It's unnecessarily complicated.

You're not going to get the joyful blend of simplicity and power of Python (nor the slowness, fortunately), but for the "unnecessarily" part, have you tried C++11? For me, it made C++ noticeably less tedious. (Further improvement in C++14, but '11 was the biggest increment.)

Of course, with the popularity of C++, you get plug-in frameworks, all kinds of libraries including templates, efficient compilers. So, a nicer language may end up a more tedious development project overall. I guess you know all this—I mainly wanted to point out C++11 improvements.

C++11 might be it, but in my beginning journey of programming in C++ I've been mostly just confused about the amount of structures that one must manage, compared to say Java or C#. It takes the fun out of programming having to type all sorts of nonsensical things (syntax) not related to the problem.