KVR Audio

Vertion · Post by **Vertion** » Fri Jul 03, 2020 9:55 am

// Description: An open community audio plugin format
// Due on: August 1st, 2020

On August 1st, we will make it happen. We will release a new free and open community plugin format. Solid, simple, free, and reliable.

How many hours have you wasted in code simply because of the whimsical changes to a corporate controlled plugin format, software development kit, or security implementation? Tired of being led around and forced to pay more simply to use what could be free? Ever feel like there could be just one standard, always reliable, always free, and designed by developers like you?.

Let there be fierce discussions, wild coding arguments, creative solutions. Everyone will be credited for there work (in code comments). I will will help push everything along.. During this time, if there are design impasses, I will make the call to move things along. On July 1st, every year we vote on a new director keep things moving.

Github:
https://github.com/The-Originator/CommunityPlugin

Vokbuz · Post by **Vokbuz** » Fri Jul 03, 2020 10:51 am

C or C++?

Benutzername · Post by **Benutzername** » Fri Jul 03, 2020 12:06 pm

Vokbuz wrote: ↑Fri Jul 03, 2020 10:51 amC or C++?

No C++ in the interface! That is an absolutely no go!

It makes using other languages almost impossible. Just look at the VST3 disaster in this regard. Use C and add a C++ wrapper around the whole thing if you have to to use C++.

hugoderwolf · Post by **hugoderwolf** » Fri Jul 03, 2020 12:35 pm

Vokbuz · Post by **Vokbuz** » Fri Jul 03, 2020 1:01 pm

Benutzername wrote: ↑Fri Jul 03, 2020 12:06 pm Just look at the VST3 disaster in this regard. Use C and add a C++ wrapper around the whole thing if you have to to use C++.

Please stop, VST3 disaster is not in language. People who used VST2 C++ wrapper all the way still complain about VST3. If the problem would be in the language, they would not complain.

I totally agree that it should be C interface but not because of the reasons listed above. ABI compatibility is the primary reason. Everything else is not a showstopper.

Z1202 · Post by **Z1202** » Fri Jul 03, 2020 1:14 pm

There are 14 different competing ABI standards for C++. We need to develop one universal ABI standard.

Couldn't resist

Vertion · Post by **Vertion** » Fri Jul 03, 2020 4:37 pm

Unless there are any objections, the interface will be in C.

camsr · Post by **camsr** » Fri Jul 03, 2020 5:35 pm

Well, I guess I will go first with a useful suggestion (if it's feasible). Let the host do all memory allocation, and the plugin only uses hosts' pointers. Some functions for the plugin to request and identify these pointers. It would not be much different than the plugin doing the same work, but it would organize memory-related methods into the host process where more control can be had, for example, well-timed GC, or address space layout.

nix808 · Post by **nix808** » Fri Jul 03, 2020 6:23 pm

I can't help with the function,
but the name could be:-
Native
or
OPS- Open Plugin Standard
or
Function

further- the GUI window could allow shapes other than rectangle/square

Vokbuz · Post by **Vokbuz** » Fri Jul 03, 2020 6:47 pm

camsr wrote: ↑Fri Jul 03, 2020 5:35 pm Well, I guess I will go first with a useful suggestion (if it's feasible). Let the host do all memory allocation, and the plugin only uses hosts' pointers.

Not sure what allocations this rule should apply to (do you have examples?) but generally this is a horrible idea. Host knows nothing about plugin internal structure and lifetime of its objects. There should be clear and simple ownership rules instead. (e.g. VST's effGetChunk result buffer ownership rule is not simple and not clear).

Vokbuz · Post by **Vokbuz** » Fri Jul 03, 2020 7:01 pm

More decisions to make. Should plugin format support:
1) Several plugins in single binary? (I would say: it should)
2) Sample accurate automation? (I would say: it would be nice to have)
3) 64-bit processing? (I would say: I don't really care)
4) Separate GUI that can run on other machine or in other process and communicate with processor via virtual communication channel? (I would say: hell no)
5) Pins (VST2 like) or buses (VST3/AudioUnit like)? (I would pick buses)

Vokbuz · Post by **Vokbuz** » Fri Jul 03, 2020 7:06 pm

nix808 wrote: ↑Fri Jul 03, 2020 6:23 pm further- the GUI window should allow shapes other than rectangle/square

This is a nice request but such feature is not free. It will require more complex API and probably induce portability problems.

nix808 · Post by **nix808** » Fri Jul 03, 2020 7:19 pm

Vokbuz wrote: ↑Fri Jul 03, 2020 7:06 pm
nix808 wrote: ↑Fri Jul 03, 2020 6:23 pm further- the GUI window should allow shapes other than rectangle/square
This is a nice request but such feature is not free. It will require more complex API and probably induce portability problems.

I changed my wording slightly, thanks for considering it!
If the API could accept an annexure that allowed this?-but the simple window would be default?ie. the extension would/could not be included in the compile if not desired. It is a complexity yeppy. I can't say that it would be worth the hassle

following this thread with interest, if we find this has support- I can prepare icons and logos
(I was thinking some sort of hex bolt representation (like bolt this to your host))