4 ms·

> Regarding plugins, I know that I'm not the only lead developer of a DAW who, if they possibly could, would refuse to support plugins entirely. The problem is

by tomc1985 5y ago

> Regarding plugins, I know that I'm not the only lead developer of a DAW who, if they possibly could, would refuse to support plugins entirely. The problem is that most users want more functionality than a DAW itself could feasibly provide (they also sometimes like to use the same functionality (plugin) in different DAWs or different workflows). Honestly the sound quality of most DAWs' built-in effects and synths are garbage. Even the effects section of most VST synths is bad! Best to allow plugins rather than trying to reinvent the wheel; you'll have to pry my beloved serum/iZotope/u-he/softube plugins out of my cold dead hands Also, the "sometimes" is an understatement. Anyone who's been doing this a while likely to be pretty invested in the plugins they have. I would say the majority of working musicians that use DAWs work this way

lavabiopsy 5y ago
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 5y ago
  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 5y ago
    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.
    - PaulDavisThe1st 5y ago
      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 5y ago
        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 5y ago
        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 5y ago
        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 5y ago
        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.
- PaulDavisThe1st 5y ago
  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 5y ago
    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 5y ago
      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.
      - 5y ago
officeplant 5y ago
>Honestly the sound quality of most DAWs' built-in effects and synths are garbage. Have you ever tried Reason? Then again I'm actually using Reason as a plugin (via vst3 to vst2 wrapper) so I can sequence it easily with renoise. Because why not just load a DAW in your DAW.
- tomc1985 5y ago
  Hah, I have a copy of Reason Lite that I got for free that loads as a VST. Mainly use it for ReBirth, but now even that's redundant since FL has its own 303 emulation that's pretty good Back in the day producers used to complain that you could recognize a Reason track from a mile away. FL used to have the same problem. 'Garbage' is probably an overstatement nowadays (at least judging by the FLStudio demo tracks, their quality has been steadily improving over time) but the meme persists.
  - officeplant 5y ago
    For sure, Reason 3 and older especially had it's own recognizable sound. Personally I like using "garbage" plugins in my music. I've gotten some nice strange out of old free vst plugins run through much nicer effects racks.

lavabiopsy 5y ago

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 5y ago
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 5y ago
  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.
  - PaulDavisThe1st 5y ago
    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 5y ago
      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 5y ago
        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 5y ago
        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 5y ago
        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.
PaulDavisThe1st 5y ago
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 5y ago
  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 5y ago
    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.
    - 5y ago

officeplant 5y ago

>Honestly the sound quality of most DAWs' built-in effects and synths are garbage. Have you ever tried Reason? Then again I'm actually using Reason as a plugin (via vst3 to vst2 wrapper) so I can sequence it easily with renoise. Because why not just load a DAW in your DAW.

tomc1985 5y ago
Hah, I have a copy of Reason Lite that I got for free that loads as a VST. Mainly use it for ReBirth, but now even that's redundant since FL has its own 303 emulation that's pretty good Back in the day producers used to complain that you could recognize a Reason track from a mile away. FL used to have the same problem. 'Garbage' is probably an overstatement nowadays (at least judging by the FLStudio demo tracks, their quality has been steadily improving over time) but the meme persists.
- officeplant 5y ago
  For sure, Reason 3 and older especially had it's own recognizable sound. Personally I like using "garbage" plugins in my music. I've gotten some nice strange out of old free vst plugins run through much nicer effects racks.