How common is it to use in-house plugin formats for development?

[xos]

I spent a few weeks making my own plugin format. But how sane is that?

I can make a plug with all custom metadata in less than 50 lines of code for rapid prototyping. And a simple synthesizer with sample exact timing in something like 200 lines of code.

Last 2 days I created a generic wrapper for the format, that makes the plug act as a CLAP plugin for audio effects and synthesizers with fully working note ID and voice modulation. And it has bells and whistles like different parameter representations and things like that, and fill in all metadata correctly for the CLAP plug, so it's not just a gimmick. And I'm quite sure a working VST3 wrapper can be made in less than a week. This was just some skunk works, but I think it still holds water.

I think that the concept here is to let the wrapper do correct core optimizations. Why push optimizations and correct formalism to the plug coder?

And in the DSP process loop has a lot less calculations than a standard CLAP plug. This thanks to translating messages in bulk to a smarter and less CPU intensive format with less DSP calculations and function calls inside the main process loop.

It also gives a plug with automatic memory allocation, and automatic garbage collection, and no calloc or malloc after init of the first plugin instance.

And I can make a GUI editor for it in 15-30 lines of code with custom animated graphics. But that has nothing to do about the plugin format but thanks to a custom graphics lib.

Another benefit is that AI has no problems generating fully working plugins with this plugin format. It's quite strange, as normally AI is not even close to being right all the time, it's more like AI creates garbage code normally. I never seen AI work this well before.

If this could be done in this short time span, it makes me a bit confused. How common is it that companies use their own plugin formats to get faster plugins with a huge amount of less code?

Why even bother to make plugins for the original plugin formats directly, when it produces a lot less performant plugins by default without a lot of nitty picky strange code?

How common is it for companies to use their own plugin formats?

If something like this can be done in such a short time, it makes me a bit confused about the state of the industry. Curious to hear your thoughts.

To be honest here. I think it's not just to make a new plugin format. But if you know what other formats do, and needs to write a lot of boiler plate code every time just to get all the details right on a high consistent level. This is a real alternative. Why not freedom to focus on creativity instead of wrestling with boilerplate code over and over just because all plugin formats is sub par?

Move things to a message converter. And the inner code will get faster and with a lot less code.
It can not just be a fluke. How many of you have your own plugin format in the woodwork of your inner soul of your plugins?

[rafa1981]

I'm no expert in this exact field, but there probably is a difference between a project working at the home project self-learning level and going commercial multiplatform multiple DAWs.

So you have a risk of having things working, just for at random times issues/chores that aren't your core-business to come up. Take as an example U-he dedicating all their limited-at-the-time manpower during 1 to 2 years to redo their framework because or Apple, VST2, etc.

So I assume many players in the industry externalize this to OSS libraries/frameworks where there is a joint effort like, Juce, iPlug, etc. or are big enough for having dedicated people to framework stuff and still make a win compared to using a 3rd party framework.

I e.g. considered Juce both horrible and nice at the same time. As a library felt a very dated design, the CMake juceaide stuff is (or was) horribly slow, needed inheritance to handle UI events (90's Java-like), etc. but on the other hand it abstracted real problems away and it has a community to help.

All projects have a cycle: they start small and elegant then they face production and accumulate fat.

[FigBug]

Probably everybody? I can't imagine anybody is writting their plugins up to 6 times. I assume most older companies are writing VST2 plugins still, and then have wrappers for the other formats. More modern companies are probably using juce or their own framework that gets wrapped in the different formats.

> when it produces a lot less performant plugins by default

I don't agree with this, using the native plugin format will always be more performant than adding another layer. However, it total doesn't matter, it's be a few extra functions calls per process block. Completely unmeasurable difference on a modern processor.

I could make my own plugin format, but juce is fine. I'd rather put the effort into my product than figuring out the quirks of aax, au, vst, vst3, clap, macOS, Windows, hidpi scalling, screen readers, etc.

[xos]

Why would a native plugin format always be more performant? That is a rhetorical question.

I have made my own languages and compilers so I don't say this out of nowhere. Modern C/C++ compilers have no problems to reduce simple shims to no code at all. In practice it almost become like changing the name of something.

For example, I practically use the same sample buffer structure and call mechanisms as CLAP. And there is not totally opposite ways to do this. A shim can be reduced down to nothing if done right. This is not true if you compile in separate stages.

So that other buffer structure that is practically the same and gets no overhead.

And DSP is more expensive than messages. Convert like 200 messages compared to generating like several thousands of samples that in every case has a lot of more calculations. I do not know what to say, but lines of code in a complete program, do not equal performance. Think about that

So take this together. How can that even be true that a native format is always more performant? I throw this out there to the wolfs

Ok! what if now I'm more performant than standard CLAP plugins. Would that compensate for using a second shim to another format?

This is meta I know But if everything is compiled in the same go. Do anyone have any experience of this? I'm talking about shims within shims. Technically this can totally go away in number of instructions, if the conditions is right.

Lets research how long the rabbit hole goes. Any practical experiences?

[FigBug]

Now you are changing your original claim. You said your wrapper was more performant than writting a native plugin. That's impossible. Your shim may have some performance impact, it may get optimized away so the impact is 0. But the shim can't increase performance.

[xos]

Now you are changing your original claim. You said your wrapper was more performant than writting a native plugin. That's impossible. Your shim may have some performance impact, it may get optimized away so the impact is 0. But the shim can't increase performance.

Well it can and I described how from the beginning.

I have messages that CLAP (in this case) don't have, that is calculated with CLAP messages and becomes another type of messages to my plug. I parse the CLAP messages and converts them in bulk before the the audio loop.

With this I move some types of calculations from the process loop to the message buffer. And I need less DSP calculations in the process loop. And end up with code that is cleaner and easier to read and maintain.

[Marvinh]

I’d be interested in learning how to create a format within the existing formats

So users can extend the plugin

Or a better way to manage larger plugins

Sort of like vcv rack for fixed architecture synths

[imrae]

There's YSFX, a host for JSFX plugins (including code editor). YSFX is itself open-souce: https://www.realinks.net/links/ysfx/

[Jeff McClintock]

Yep, I have my own format. But also use JUCE in my 'day job'.
Maintaining your own format is a mixed-bag. The advantage is that you can improve on JUCE in areas like sample-accurate parameter support and cleaner separation-of-concerns. Plus, ditch the rigid and fragile object-oriented approach to graphics.

And like your approach, I can build a basic plugin in a single file, in 51 lines of code, with fully sample-accurate automation and automatic save/load state, then wrap it to VST3, AU, or SynthEdit.

The downside of course is that you have to do a LOT of work to even approach the functionality of something like JUCE or iPlug.

[mystran]

I'm not convinced having a custom "plugin format" as such is either useful or necessary.

I think one should definitely have a custom plugin API layer where you can write your plugins once and then have them automatically wrapped into whatever formats you want to support, but there's a big difference between having a custom API vs. having a custom plugin format that provides a stable ABI across module boundaries ... and frankly I don't think the latter really makes much sense.

I think it's important to make the distinction between the two, because the design considerations can be quite different.