Our Community Plugin Format

DSP, Plugin and Host development discussion.
Locked New Topic

Poll 1 - Let's give it a name (Acronym)

HOT Plugins
0
No votes
WAR Plugins
0
No votes
TOP Plugins
0
No votes
OUR Plugins
0
No votes
PRO Plugins +1 Point
1
3%
EVE Plugins
3
10%
ION Plugins
3
10%
IVY Plugins
2
7%
MAN Plugins +1 Point
0
No votes
WTF Plugins +2 Points
1
3%
KVR Plugins (permission issue?)
2
7%
DIY Plugins
1
3%
COP Plugins
1
3%
API Plugins (Amazing Plugin Interface)
0
No votes
TPIA Plugins (This Plugin is Amazing)
0
No votes
OPI Plugins (Open Plugin Interface)
8
27%
OPS Plugins (Open Plugin Standard)
8
27%
 
Total votes: 30

RELATED
PRODUCTS

Post

Youlean wrote: Fri Jul 03, 2020 7:31 pm I am sure that DAW makers can't wait to add another plugin format to support. 😄
If there are VST, AU, AAX, etc. wrappers to go with, I'm all for it. Meaning, compile my plugin in the proscribed format as a standard library, then drop them into the pre-compiled wrappers and serve. Maybe, DAW manufacturers will eventually allow the native format too.
I started on Logic 5 with a PowerBook G4 550Mhz. I now have a MacBook Air M1 and it's ~165x faster! So, why is my music not proportionally better? :(

Post

Youlean wrote: Fri Jul 03, 2020 7:31 pm I am sure that DAW makers can't wait to add another plugin format to support. 😄
I get the impression it is made to replace all others because it is THE ONE :D Let's see where this goes and when the first 50/50 devs are of opposit opinion, how it is solved and when this community format is going to branch into 2 :clown:

Post

Here are discussion points so far:
  • Let the host do all memory allocation, and the plugin only uses hosts' pointers
  • Naming Ideas and Branding
  • There should be clear and simple ownership rules. (e.g. VST's effGetChunk result buffer ownership rule is not simple and not clear).
  • Several plugins in single binary
  • Sample accurate automation
  • 64-bit processing
  • Separate GUI that can run on other machine or in other process and communicate with processor via virtual communication channel
  • Pins (VST2 like) or buses (VST3/AudioUnit like)
  • GUI window should allow shapes other than rectangle/square
  • VST, AU, AAX, etc. wrappers to go with
SLH - Yes, I am a woman, deal with it.

Post

I personally would love to see:

proper shader support - GL/DX or whatever for funky UI stuff.

and

GPU Compute kernel support for bonkers experimental stuff :)

Post

I had this torx head drawn already,
an icon/logo thought
I'm still thinking of a bolt on module representation
Torx Conc3pt.png
+1 on GPU access, it is advantageous to be able to create truly multi-media apps
GDI is nice, but it can get so CPU heavy unless minimally drawing

what about a wrapper that is an executable? The format could attract a wide field of use-cases, outside audio too (engineering,visuals)

I tried to make an acronym of BOLT (why not?) for a name. The best I could do was Binary Operable Leverage Tool :D
You do not have the required permissions to view the files attached to this post.

Post

shabby wrote: Fri Jul 03, 2020 9:02 pm proper shader support - GL/DX or whatever for funky UI stuff.
GPU Compute kernel support for bonkers experimental stuff :)
These are not a job for plugin format.

Post

My take on the name would be Open Audio Extension.

Post

Vokbuz wrote: Fri Jul 03, 2020 10:58 pm
shabby wrote: Fri Jul 03, 2020 9:02 pm proper shader support - GL/DX or whatever for funky UI stuff.
GPU Compute kernel support for bonkers experimental stuff :)
These are not a job for plugin format.
What do you mean and why?

Post

Vokbuz wrote: 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).
The host would know about the plugin via the functions the plugin calls to request (and remember, shared) system resources. The potential for leaks is there, but it would require some thought for sure.

The plugin would make requests for some system level stuff instead of doing it directly. This way all plugins would play nice together, wait in line, etcetera, doing it the host (and platform) way. allows plugin devs to focus less on platform specifics.

A simle example could be, if the plugin made a large allocation. Instead of just doing it, and letting the system figure it out, the host could confirm that it's readily available to make first. And if it wasn't, prompt for confirmation. By centralizing those requests in the host, no plugin need to figure out the same things over and over in each instance. That would be the main advantage.

Post

camsr wrote: Sat Jul 04, 2020 5:20 am The host would know about the plugin via the functions the plugin calls to request (and remember, shared) system resources
This description is too vague.
camsr wrote: Sat Jul 04, 2020 5:20 am A simle example could be, if the plugin made a large allocation. Instead of just doing it, and letting the system figure it out, the host could confirm that it's readily available to make first.
What do you mean by "available"? Allocated by another plugin or host? It is probably used. If it is not used by others, why is it still allocated???
Last edited by Vokbuz on Sat Jul 04, 2020 7:18 am, edited 2 times in total.

Post

shabby wrote: Fri Jul 03, 2020 11:36 pm What do you mean and why?
Plugin format is just an interface not fully featured framework to solve all application programming problems. All these things can be used without bloating interface with them. Or let's add archiver and database support to the interface too?

Post

Vokbuz wrote: Sat Jul 04, 2020 7:16 am
shabby wrote: Fri Jul 03, 2020 11:36 pm What do you mean and why?
Plugin format is just an interface not fully featured framework to solve all application programming problems. All these things can be used without bloating interface with them. Or let's add archiver and database support to the interface too?
I see - don't joke about the archiver and database - I have actually done that - my last VST initially used sql-lite to load in impulses and 1,000,000 midi files (used sql-lite for the select searching). I eventually switched to using multiple .zip files (4gb limit). (that's all true btw - I have over 4,000 impulse files - cabs,reverbs and echos, and about 1.1 million midi files). The reason I put them in a archive was because it much easier to transport between systems. The downside is - the midi files take over 8 hours to extract lol

Post

In one way I applaud the initiative, though I don't think we should have any illusions about how wide or quickly it will be adopted. Defining a good plugin format is not easy. The devil is in the details and the XKCD strip above is right. Though having implemented a couple of the common plugin formats from both the plugin side and the host side I guess I feel justified in having some opinions to share :hihi: .

A strong point I would suggest is to leave all threading and synchronisation between the audio thread and other threads to the host implementation. Vst2 got this very wrong by not having any thread safety concerns and not clearly specifying which functions should be called from a realtime thread and which should be called from a lower priority thread. I would also suggest to include a feature from LV2 and RE, which is the ability to request non-realtime work from the realtime thread.
Vokbuz wrote: Fri Jul 03, 2020 7:01 pm 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)
Imo, Steinberg were very forward thinking in doing this and I do think it is a good idea even though the particular use case of running them in separate processes didn't really take of. Having a clear separation between the dsp and editor parts is a good thing.

Though most devs (including JUCE) eventually went with the Single Component Effect model when implementing vst3 plugins, where the same class implements both interfaces, which effectively makes this a lot less useful. I can totally seem why though, as having completely separate editor and processor requires duplicate states and is generally more difficult to work with if you're used to having only one object with a single state. In a system like ELK*, where the dps processing runs on a different machine that the GUI, having a "detachable" editor that works regardless if the dsp runs on the same cpu or on another device, would be a really attractive feature when porting the code.
shabby wrote: Fri Jul 03, 2020 9:02 pm I personally would love to see:
proper shader support - GL/DX or whatever for funky UI stuff.
The editor interface should be just that, an interface for controlling the plugin, whether to use HW accelerated drawing or support for certain technologies is not something that the plugin format itself should be concerned with.

Though on that note, it would be interesting to try do something about the window behaviour. In both vst2 and 3 the host passes a native system window handle (HWND, X11 Window, etc) to the editor. To integrate that with existing gui frameworks usually requires a lot of custom, platform specific and sometimes outright ugly code for embedding or re-parenting the window given by the gui framework. As most gui frameworks don't support that particular niche use case.

I don't have any good suggestions how to fix it though, particularly not without forcing a specific gui framework, which is not a what the plugin format is supposed to do.
Vertion wrote: Fri Jul 03, 2020 8:58 pm
  • Sample accurate automation
In addition to having sample accurate note events and parameter changes, it would be beneficial to have access to the full list of changes in the process callback. Vst2 got this wrong imo with separate setParameter() and processEvents() functions. To get access to the full list of parameter changes the plugin would need to cache them in setParameter(), which would mean extra work and thread safety issues as setParameter() was not guaranteed to be called from the audio thread.

I addition i think that Vst3 got it right with having all parameters as normalised doubles (for sensible automation and controller mapping) and the editor providing functions for converting back and forth between a normalised representation to a human readable representation, i.e. filter cutoff in Hz or gain in dB.

While I do get the feeling that what most people here are after is something minimal that can be expressed in 1 or a few header files. Sort of like vst 2 but with the kinks ironed out. It would be worth taking a look at the Rack Extension SDK for inspiration. It is in one way a much more complex plugin format, and it requires a hosting library to do a lot of the behind the scenes work. But it also completely abstracts away all threading issues, all platforms specific issues (it is a true write once - use everywhere format), allows for declarative definitions of parameters and everything else related to the data model, properly sandboxed plugins, etc. Imo it's one of the most well-engineered and future proof formats out there.

(*) Full disclosure: I work for ELK and has build a lot of the plugin hosting code in ELK.

Post

Vokbuz wrote: 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)
I think this is mostly bloat.
2) Sample accurate automation? (I would say: it would be nice to have)
Automation events with delta timestamps is probably the single biggest thing actually missing from VST2 (at least how it's commonly supported). Going beyond that risks complexity that might result in problems with different implementations being different.
3) 64-bit processing? (I would say: I don't really care)
You mean double-precision buffers? They are essentially useless for transport (except as far as you might save a conversion if the plugin is processing in double precision), but some people seem to think it's an important buzzword feature.
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)
In my opinion the problem here tends to be the virtual communication channels more so than anything else. Especially when the underlying transport (eg. IP) is unreliable, you really need that unreliability exposed down to the application level and with real-time applications in particular, the way you want to implement retransmission often depends on the specific data you are trying to send (eg. some data must be reliable in-order, other data is "only the most relevant matters" and then you might have some data that wants to make some sort of a trade-off between the two, all in the same plugin)... but forcing this level of complexity on every plugin is not exactly ideal either.
5) Pins (VST2 like) or buses (VST3/AudioUnit like)? (I would pick buses)
Related channels should be grouped together (so the channel count within a bus can then be flexible, without making a huge mess).

Post

Vertion wrote: Fri Jul 03, 2020 8:58 pm
  • Let the host do all memory allocation, and the plugin only uses hosts' pointers
I assume this refers to memory used on the ABI level (and not all plugin internal memory), but even then it can complicate the interface slightly in cases where the plugin is the only one that actually knows how much memory is required.

For example with the effGetChunk example, even the plugin might not always know the size of the chunk before actually figuring out it's contents. This is not a big deal when you write the chunk into something like an std::vector, but it means that you then need something in the ABI that lets you tell the host to allocated a buffer of the correct size while the chunk request is being processed.

I don't really have a strong opinion on what would be the best way to handle things like this, just that all memory management should be specified one way or another and preferably without involving any fixed-size buffers.
  • There should be clear and simple ownership rules. (e.g. VST's effGetChunk result buffer ownership rule is not simple and not clear).
When you have an ABI by two components potentially compiled using different compilers and potentially using separate heaps, the only ownership rule that can ever actually work is that "whoever allocates will also deallocate" because otherwise it might just randomly crash. The only workable alternative is to add allocation into the ABI itself (ie. for plugin to ask the host for a block of memory).

The problem with VST2 is just that in many cases there is no clear specification in terms of exactly when the plugin is allowed to deallocate a previously allocated piece of memory.
  • GUI window should allow shapes other than rectangle/square
This is a joke, right?

Locked

Return to “DSP and Plugin Development”