KVR Audio

aciddose · Post by **aciddose** » Mon Jul 10, 2017 7:22 pm

You need to be filling a gap which needs to be filled; If nobody needs your feature why would it be worth anything to anyone at all?

Some simple shortcomings of VST and other formats:

Dispatcher uses fixed "opcode" indices and data structures
This one isn't a really big deal but it does make the API needlessly complicated. Features that aren't needed in most cases are stuffed into the code of every existing plug-in. The methods used are easily extensible but a lot of risk is associated with making such extensions: once adopted they are very difficult to replace or remove. This could be fixed via existing methods for handling extensions. More on this with #3...
String handling uses limited fixed-length strings; not suitable for UTF-8
All functions and structures associated with strings should pass a pointer and length. No fixed arrays.
Meta-data associated with most data elements is for the most part redundant or obsolete in most cases.
For example (related to #1) being able to associate XML-like markup with parameters, presets or other elements would allow something like "category=filter", "widget=knob", "color=blue", "tags=fat,bass,analog". This data could be ignored entirely but in hosts which want to categorize presets or neatly arrange GUI widgets into sections or pages by group it would suddenly be possible. See CSS for example...
Notes and parameter values aren't possible to associate with voices. There is no concept of polyphony or voices. It isn't possible to interpolate parameter changes and they are instead limited to block edges.
Self-explanatory in my opinion.

Those are some things that I'd personally find very useful to improve the functionality of my plug-ins. I use such systems internally but VST provides no mechanism to communicate that info to the host. Most hosts do not support such features and we're left with flat lists containing 1000s of presets in many real-world cases.

They decided to abandon VST2x and implement some of these (partially) in VST3 and just look at how widely supported that format has become: not very widely at all.

So it's clear that these features and others are not nearly as valuable to others as they are to me.

If you're not willing to tell anyone about what you want to see implemented; the odds of it being implemented are zero. Just flat out not going to happen.

If you want to simply say "hey I've got this idea for this feature, it works like this: ..." and give comparisons to demonstrate the shortcomings of existing formats vs. the benefits associated with the feature you'll only start to climb the very first speed-bump: being acknowledged at all. Being accepted as a "good idea" is the next step and that cliff-face is very steep and free of footholds.

spunkmuffin · Post by **spunkmuffin** » Mon Jul 10, 2017 7:25 pm

Just fluke it Fluky!

soundmodel · Post by **soundmodel** » Mon Jul 10, 2017 7:31 pm

Okay since this idea is supposed to be a community project and since it has some overlap with some existing offerings, here's a brief introduction:

aciddose · Post by **aciddose** » Mon Jul 10, 2017 7:41 pm

This is essentially what existing plug-in formats already are.

So you're talking about three things:

Modularity of a specific format or format by imposing a standard set of features required to support it.
For example VST2x is almost entirely modular. They even had it in mind originally to allow communication between plug-ins without host involvement.
A set of standards for storing information about a collection of modules, their arrangement and interconnections and associated properties.
Many hosts do this. It's called a project file. Reaper supports sharing "effect chains" too like you point out. No standard exists for this information. Making such information generic enough to apply to different plug-in formats would require a common lowest-common-denominator set of features (see #1) in every plug-in standard.
Improving the efficiency of the implementation of each plug-in format to enable very low-level modules (filter, oscillator) to communicate very detailed and implementation-specific data in generic ways.
This last point is self-contradictory. You can't create a simple and generic standard by which complex implementation-specific data can be flexibly and efficiently communicated.

So those are the problems you have to solve. Start with the biggest and most essential one: #3.

soundmodel · Post by **soundmodel** » Mon Jul 10, 2017 7:47 pm

Most DAWs have the ability to save effects patches. However this has at least two problems:

1) In order to use the patch the user needs to have the same DAW as well as the same plug-ins.
2) If the DAW doesn't support defining of "macro controls", then utilizing such patches is still rather complicated.
3) What's needed might exist in some modular environment (e.g. Reaktor), but some other parts might exist in other VSTs. Are these interconnectable?

aciddose · Post by **aciddose** » Mon Jul 10, 2017 7:54 pm

Yes and no.

Yes: if the author implemented it in every existing implementation you're interested in. That's just a ridiculously huge load of work for everyone.

No: The interconnection standards are fundamentally different in that they're designed to accommodate different levels of modules. Both VST and Reaktor are modular systems but one is more "complete system" level while the other is "individual component" level, such as an addition or subtraction. The two are incompatible for the simple reason that they are only efficient methods for the purpose for which they are designed and can not be adapted. The type and amount of data being communicated determines the best method of communication. You can't get "the best of both worlds".

aciddose · Post by **aciddose** » Mon Jul 10, 2017 8:03 pm

For example:

1) An object based design:
A "voice" object contains "oscillator", "filter" and "modulator" objects. The "mainboard" object contains an array of voices and a voice-allocator object along with a parameter routing "mod-matrix" object.

When you want to add or remove a voice you can simply allocate or delete that data and reset the corresponding entries in the other "mainboard" objects. Easy.

2) A data based design:
We have different types of objects: "oscillator", "filter", "modulator", "voice-allocator", "mod-matrix" and so on. Each object contains an index into an array of voice-specific data. This may even be allocated as a single aligned lump for a set of modules or all modules depending upon what is most efficient.

When you want to add or remove a voice... uh oh. You have to allocate or delete the whole thing including every voice and reset or rebuild all state data.

So you should see the two strategies have differing issues. Start factoring in additional complexities like the scale of each module; how polyphony or other complex voice-allocation and communication of associated data occurs; different audio-rate (by block?) and modulation-rate (by event?) communication rates and data-types; suddenly it's all very, very complicated and doesn't make much sense to even consider attempting a generic lowest-common-denominator.

More regarding: "1) In order to use the patch the user needs to have the same DAW as well as the same plug-ins."

So what are you proposing? Distributing a "patch" which is in fact a whole binary blob containing every plug-in? Now you have issues with licenses and anyone distributing the patch is a distributor for every component part.

I agree that it would be nice to have a generic "project file" standard which allows itself to be extensible enough to support all hosts... but then you're right back where you started because host Y can't load host B's extensions. At least it would be possible to directly replace a plug-in you need with another compatible plug-in on the system; and yet most hosts don't even have the capability to do this now with two different versions of the same plug-in. That's not a good sign.

In order to get it done all the authors of all the hosts out there would need to sign up and implement this standard. Not going to happen.

soundmodel · Post by **soundmodel** » Mon Jul 10, 2017 8:11 pm

aciddose wrote: More regarding: "1) In order to use the patch the user needs to have the same DAW as well as the same plug-ins."

So what are you proposing? Distributing a "patch" which is in fact a whole binary blob containing every plug-in? Now you have issues with licenses and anyone distributing the patch is a distributor for every component part.

Yes.

Perhaps using commercial DSP should be allowed (rather than the entire framework having to be open), but one should be able to replace it with some equivalent non-commercial, if it's not available on the users computer.

Actually, since I recently read that CSound allows the loading of VSTs, Cabbage seems viable framework for what I'm proposing. If one adds the feature to replace commercial DSP with alternatives (if they don't exist on the users computer).

aciddose · Post by **aciddose** » Mon Jul 10, 2017 8:13 pm

That's just not going to happen. You can't just copy ... what's some popular synthesizer plug-in ... _well imagine I named one_'s filter in a preset and load it up on another DAW without a license. That doesn't make sense. Why don't all the authors of commercial plug-ins just open-source everything and give up?

soundmodel · Post by **soundmodel** » Mon Jul 10, 2017 8:15 pm

Well what I was speculating above in the picture before "this might fundamentally be breaking some rights" was if "hiding" commericial DSP in such patch would make the output complicated enough that commercial DSP is non-distinguishable. This is sort of "grey area", because technically one might be ripping commercial DSP, but if the patch is given in a way that it's not interpretable from the output, nor from the binary, then there's no way for anyone to display rights infringement. It sort of reminds of sampling from commercial records. If one processes the sample so that it's non-recognizable, then it's very difficult to display copyright infringement.

aciddose · Post by **aciddose** » Mon Jul 10, 2017 8:16 pm

No it isn't.

soundmodel · Post by **soundmodel** » Mon Jul 10, 2017 8:18 pm

aciddose wrote:No it isn't.

What isn't?

An easier and certainly correct alternative would be to let the patches be designed so that it always has some open alternative in place of some commercial DSP that the creator has used. It might be lesser quality using the open one, but at least the patch would work.

aciddose · Post by **aciddose** » Mon Jul 10, 2017 8:19 pm

Sure but you're just back to the beginning again: the local DAW needs a local copy of every plug-in used in the preset.

soundmodel · Post by **soundmodel** » Mon Jul 10, 2017 8:21 pm

Ship the ones that can be shipped with the patch and if there are commercial DSPs then allow the user to specify their location, when the patch is loaded?

aciddose · Post by **aciddose** » Mon Jul 10, 2017 8:24 pm

Who in the right mind would ever want to implement such a system? Who would it benefit?

This is just a non-idea. Unfortunately while some of the complaints you bring up make sense, they're common and very difficult or impossible to solve.

You could try to implement something yourself but I would warn you it sounds like a waste of time.

I have a new idea for a plug-in standard/extension, what should I do with it?