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

[soundmodel]

Reaktor, Cabbage/CSound, Faust, Max/MSP, VST C++, Web Audio, ...

Wouldn't it be cool if one could develop in one and then be able to port it everywhere?

[Miles1981]

In that case, what you need is a source to source compiler. But the main issue you will face is different support for different algorithms anyway, and in such a compiler, you can't read the generated code. When you check what Faust generates (which is "VST" C++, I don't understand what VST stands for here), it's ugly, but it is C++ code.

[soundmodel]

VST C++ means C++ using some VST SDK.

[whyterabbyt]

I think at this point its down to that 'demonstration' thing.

If you can achieve any of this, then you'd be on a better footing to justify the idea to the folk here who, whether you like it or not, have a much, well lets say 'different' notion of the problem space from you.

However, from my perspective, I'd suggest you're taking a very surface look at multiple different approaches to audio processing frameworks and solutions and deciding that all the bits you like should be integrated into a single uber-solution, and that because they all exist, that feature-mashing can be done relatively easily. I think you'll find that there's a large element of Dunning-Kruger affecting that analysis.

In actuality, you'd be reinventing every single wheel of every single one of those widely varying designs and paradigms in order to get any of it working.

So like I say, its up to you to demonstrate that your ideas are possible, not just argue that it 'should' be and that it thus should be a 'standard'.

[soundmodel]

I'll have a look at source-to-source compilation.

[whyterabbyt]

I'll have a look at source-to-source compilation.

To what end? What does that have to do with a plugin-standard or extension, or modularity, or plugin chains, or macro controls, or plugin substitution or changing plugins standards to support blockless sample processing or anything else you mooted as your idea?

[soundmodel]

I'll have a look at source-to-source compilation.

To what end? What does that have to do with a plugin-standard or extension, or modularity, or plugin chains, or macro controls, or plugin substitution or changing plugins standards to support blockless sample processing or anything else you mooted as your idea?

Well don't you think that such could be ideally part of DSP specifications?

That when one writes a VST, then it's designed to allow cross-compilation to different platforms?

[whyterabbyt]

I'll have a look at source-to-source compilation.

To what end? What does that have to do with a plugin-standard or extension, or modularity, or plugin chains, or macro controls, or plugin substitution or changing plugins standards to support blockless sample processing or anything else you mooted as your idea?

Well don't you think that such could be ideally part of DSP specifications?

What 'that such' are you talking about? Compiler technologies have zero intrinsic overlap whatsoever with DSP or DSP specifications, so no, its a complete non-sequitur.

That when one writes a VST, then it's designed to allow cross-compilation to different platforms?

Inadequate question. When one writes a VST its already designed to allow cross-compilation to different platforms, ie any OS platform for which there is a VST implementation.

However, making the big step of assuming you're merely getting terminology all fuzzy and vague, possibly because youre grasp of things is, then lets be clear. Ensuring one's audio plugin is compatible with multiple plugin standards has nothing intrinsic to do with source-to-source compilation either. Company after company, developer after developer, for nearly two decades, have all managed to target multiple plugin standards without needing such a thing.

So, again, exactly what does this have to do with your proposed idea? How does this help with modularity, or plugin chains, or plugin substitution, or macro controls or any of those other things? And I mean, specifically, not hand-wavingly 'because cross compiler is woo.'

[PurpleSunray]

Reaktor, Cabbage/CSound, Faust, Max/MSP, VST C++, Web Audio, ...
Wouldn't it be cool if one could develop in one and then be able to port it everywhere?

It would be cool, in theory. In partice this kind of constructs never work relaiblity.
They combine the disadvantages of all platform and you loose the advantages of it.
Example: Web Audio.
If you want to support that, you standard needs to add restrictions so that you can actually translate the pseudo-code it into a piece of JScript code that runs on your browser.
What if my plugin should support a very specific DSP chip? No way to talk directly to a driver from within your browser.

Your standard must aggregate restrictions of the supported platforms, so that it can run on all of it.
If you don't want to restrict, you need allow direct access to the system or add more functions your API. So you are down on implementing a platform abstraction framework. Welcome the in world of Java, .NET & co (the tasks to do on this are not related to DSP at all)

[antto]

all of this.. so "musicians" can make tracks using identical fx processing chains ..

reaktor is modular but doesn't load VST?
i guess you haven't heard about synthedit.. it's modular and can host VST plugins, and it's written in C++

for the record: i'm also skeptical.. this is a very complicated idea..

[aciddose]

I think it's a very simple idea: too simple.

[stratum]

Reaktor, Cabbage/CSound, Faust, Max/MSP, VST C++, Web Audio, ...
Wouldn't it be cool if one could develop in one and then be able to port it everywhere?

The day "portability" has died was the day java vm was introduced, and you are talking about entirely different things. Port c# code to jvm the way you could port C code from one operating system to another. Impossible. Somebody has to write a c# compiler for the jvm, first, or you have to rewrite the whole code.

[arkmabat]

all of this.. so "musicians" can make tracks using identical fx processing chains ..

reaktor is modular but doesn't load VST?
i guess you haven't heard about synthedit.. it's modular and can host VST plugins, and it's written in C++

for the record: i'm also skeptical.. this is a very complicated idea..

This makes me wonder if some of the really good freebies are actually reskinned commercial plugs... could it be?

[Mayae]

all of this.. so "musicians" can make tracks using identical fx processing chains ..

reaktor is modular but doesn't load VST?
i guess you haven't heard about synthedit.. it's modular and can host VST plugins, and it's written in C++

for the record: i'm also skeptical.. this is a very complicated idea..

This makes me wonder if some of the really good freebies are actually reskinned commercial plugs... could it be?

I highly doubt that. It's extremely easy to detect and very illegal (and you would have to crack any copy protection). You would also have to write a host wrapper around the plugin - you can't "reskin" compiled binaries.