[lavabiopsy]

That's the thing though, not having plugins would not mean that you can't delegate development duties for a synth or reverb out to another company. I am not sure where you are drawing that conclusion from. It just means that the development would be happening within the DAW.

[tomc1985]

A large part of the reason those developers can exist independently is because they can target every DAW. So either you will have to hire them all or find new specialists, or develop that specialization yourself.

Even in the case of developers only targeting one DAW (Pro Tools), at least one company (AIR music) saw that it was worth the extra effort to release its products in other plugin formats like VST.

Honestly, I would not like to see new developers trying to oust the plugin standard. It's one of those quirks about music software that exists for very good reason.

[lavabiopsy]

I'm sorry, I don't get where this is coming from, the specialists don't need to be hired to write the same code again. The old code can just be re-used. If I could guess, I think this is stemming from a misunderstanding that "no plugins" means "no code re-use" which is an understandable misunderstanding (say that 5 times fast) but it isn't the case.

In my opinion, plugins only exist because it's convenient to package a synthesizer/reverb/whatever for users that way, but there is no reason that can't be supplanted with something that is more convenient. Of course if it's less convenient then that wouldn't be worth doing, if that is your concern then I agree with you there.

[tomc1985]

Not saying no code reuse. But if you're going to reuse code across multiple DAWs, then a plugin system is the established standard.

Do you think those existing developers are just going to drop their code into your environment and hit compile? How do you plan on getting all these musical components into your DAW? It doesn't work like that. Someone is going to have to write something, or you're going to be acquiring the rights to existing code somehow, which is still going to have to be ported to your environment.

Or you could skip all that and implement VST. There are even libraries that present a standard interface and output plugins in all the major formats, so you could target that instead. (I forget the name of the framework I'm thinking of but it was written by the Cockos guy and his DAW's ReaPlugs effects suite targets that library)

How would you motivate a synth/effects developer want to spend time on your project? Unless you hire them, and if you're going to ask them to "write reusable code," they're going to point to their existing portfolio of plugins.

[lavabiopsy]

It doesn't really matter who does the work, if you were writing a new DAW, you'd probably do it. But if you were working on an established & popular DAW, plugin developers could be convinced to do it if there was benefit to them (more optimizations, more features, more convenience, less bugs, etc).

I don't think it is currently popular for plugin developers to implement against VST themselves, the libraries you mention seem to be gaining a lot of traction, at least from my experience from trying to catalog open-source plugins on github.

[PaulDavisThe1st]

Why would people who can sell (or at least pitch) their plugin(s) to the users of 12-20 excellent DAWs decide to go work for just one of those DAWs ?

[lavabiopsy]

I don't understand why you are saying that either, please explain. Nobody needs to work for just one, as any code can be linked into any number of DAWs.

[tomc1985]

How is that much different from a plugin system? Because now you have developers writing bespoke code with a shim for each host DAW. At that point you've pretty much developed your own modular component protocol... literally a step away from a plugin system

[lavabiopsy]

It's not different, and in fact most DAWs are already doing something along these lines internally to actually implement an abstraction layer that can load various plugin formats and have them all interact. That's actually my key point: it wouldn't be significantly different for users.

[PaulDavisThe1st]

But there are (at least) 12-20 DAWs, each with their own (internal) abstraction designs. It's bad enough having to write (or being able to write) plugins for:

   AAX, VST, AU, LV2 (at least)

Now you'd be talking about 12-20+ different "plugin APIs". That's not going to fly.

[lavabiopsy]

As per your other comment, it seems things are already going in that direction, if developers are treating their plugins as being written in a format that could be described as "AU that is compatible with Logic but nothing else" or something like that (substitute for any format/DAW combination that the developer wants). So I would say that in a way it has already flown regardless of how we feel about it.