[lavabiopsy]

I think you are misinterpreting that comment, I believe the idea there would be to have built-in functionality that would be equal or surpassing to those plugins, possibly by merging the actual plugins with the DAW. Of course doing that in a way that will please everyone is a lot harder to do than it sounds and is likely not even feasible, but the supposed benefit would be that the DAW could better integrate that functionality and would not have to deal with a lot of the reliability issues that exist with plugins. (Disclaimer: I agree with the GP comment in the sense that dropping plugins from DAWs would be a great thing to do if it were at all possible, but it currently really isn't)

[tomc1985]

The thing is, doing something that would 'be equal or surpassing' is pretty much impossible at an acceptable cost. You can probably write something that's 'good enough' that some people might be happy with -- that is what most all-in-one DAWs do -- but the beauty of the plugin system is that you can delegate development duties for those components to someone who a company who specializes in effects, for example. Or even a specific effect! There are developers who just write synths, or just write reverbs, or whatever. And we want to use their products!

[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]

It wasn't really a misinterpretation.

Merging plugins "with the DAW" is entirely feasible in the open source world where I live and work, and we do that sort of thing when appropriate.

But the reliability issues do not come from the fact that plugins are dynamically loaded shared objects (mostly); they come from the vastly different levels of skill AND very different interpretations of subtle aspects of plugins APIs (notably threading, GUI<->DSP communication and more). These are hard to get rid of if you've really got a diverse, distributed and largely independent "team" of developers working on something.

[lavabiopsy]

I still don't get how that is related, in my opinion, that is unlikely to change until there are tools that make it easy to resolve all those various threading/communication/latency issues on the developer side before a plugin is even distributed. So as long as you can just distribute any old shared object to get around that, I don't expect to see it to improve.

Maybe someone could come up with another way to do it that works across DAWs, and then plugins could still happen, but I consider this unlikely because with that there is never going to be a reliable way for the host to verify it that works better than what we have now (user reports X plugin works with Y host, etc).

[PaulDavisThe1st]

It's not hard to stress test plugins. There are a few good tools for some formats out there. They can verify things that most DAWs will not (e.g. by deliberately cross-threading calls and so forth).

The problem is getting people to care. For years, on macOS, the "standard" for plugin developers has been "does it work in Logic?" There were even plugins that would fail auval(1) (the command line AudioUnit validator), but somehow pass in Logic. As far as their developers were concerned, the plugin worked. Working on Ardour, I've seen at least a dozen plugins that used ambiguity in the AU spec to justify why "well, it works in Logic even if it doesn't follow your interpretation of the spec" was the end of their interest.

[lavabiopsy]

That's what I mean. The solution there would be to get Logic to run "auval" before loading the plugin which ensures that developers don't do that. But for users of Logic doing that serves no benefit as it doesn't actually guarantee the plugins run more reliably, so it won't happen. And even if it did happen, there would be no guarantee that the stress testing tool wasn't also written against other ambiguities in the spec.

Edit: I also think testing is hard in general for plugin developers to use correctly. I personally would prefer to see plugin APIs designed in a better way that make it so it's hard to accidentally cause race conditions.

[PaulDavisThe1st]

Logic does actually use auval these days, so things are improving. But this still doesn't catch the cases where the issue is something that auval can't or doesn't test (e.g stuff related to GUI interaction).

Plugin API design is an art, indeed. There was recently a brief bubble of activity on KVR among a number of independent plugin devs who found many things to dislike about VST3. A long discussion ensued, there was some talk of picking up LV2 instead, then it all evaporated and nothing was left. The last time the industry tried this was in around 2003, and nothing came (directly) of that effort either.

[lavabiopsy]

That's also another aspect where the plugin API vendors have not much incentive to fix things, because users can just use another thing on top of it (JUCE, DPF, etc) that makes better progress towards solving these issues from the developer perspective, but still DAWs are left with the tractability problem for other plugins that don't use that.

To me, if there is any interest in solving that, I would just expect someone to put a new plugin backend in JUCE/DPF that is specific to the DAW and then compile that together with the plugins into a big giant build. That's more what I mean by "dropping plugins", it's how you avoid the MxN problem too. But I think that many DAWs (including Ardour) gain little benefit from doing this at this time, so if that was what your original sentiment was, I agree.