Originally Posted by thinktink
The new versions yes but not the old ones.
Let's take a mental exercise into this proposal:
Take the classic DSP stacker. Let's say the Multiple DSP Stacker. It still get's installed into the original "Plugins" folder. Now let's conjure up a new third party plugins folder IAW your proposal, let's call it "ThirdParty" and put it into either the root of the Winamp install path or even as a subdirectory of the original "Plugins" folder. Now let's invent us up a brand new DSP plugin that is "new third party API aware" called say "TheAmaZingThingaMaDSP" and install it into the new folder.
With this setup now implemented the popular "Multiple DSP Stacker" won't be able to find the new fangled "TheAmaZingThingaMaDSP" to be able to stack it because it's 1) not aware of the new API 2) doesn't know about the new install folder to search in it to find the new DSP.
This will be true for any plugin that either hooks, chains, or otherwise directly fondles other plugins. There is no API mechanism for direct inter-plugin communication or awareness, therefore any changes of any kind to the storage mechanism of plugins that developers originally expected to deal with when the plugin was originally created will break various plugin's original intended functionality, rendering them (at least partially) impotent. In this example, the "Multiple DSP Stacker" won't be able to stack "TheAmaZingThingaMaDSP".
Originally Posted by DrO
which is why i'm not bothering with it as on thinking it through (before i'd seen the above), it completely screws up any 3rd party assumptions which is bad. also it doesn't work reliably with 1st party without a load of extra work. was a nice idea but not going to happen.
ok... so, I am either explaining myself poorly or i'm just totally wrong, and as i'm not a dev you guys would know better than me.
however, I think you might misunderstand what I am saying.
I am NOT asking that any current functionality be removed or discontinued. I am saying that a "new layer" or approach be ADDED to existing functionality.
now, I understand your point that simply moving the plugins into different, yet more sensible, folders will break many plugins absent any code changes to account for it, (code changes to both the API and the plugins). that's def a valid point.
but what I am saying is it is worth it to do that, if two things are viable:
1. the new system actually works, and sensible folder organization is achieved, itself a worthy goal.
2. legacy functionality is maintained, by simply moving (or keeping) all the legacy plugins manually back to their (current) locations.
if no one cares about plugins, as is often said here, making such a change going forward shouldn't be hard adoption wise, and having a legacy way back shouldn't make it too painful for the hardcore.
I happen to think it would be a good thing to actually make such a change, so that there was a clear line of demarcation between "current" plugins and legacy ones, as well as "official" or stock, and 3rd party.
now I may be approaching differing issues here in a non-optimal way, or I may be wrong about what is or isn't possible in coding/capability terms. but I can see a lot of benefits from this, like a pref for allowing legacy plugins or not, or 3rd party plugins or not, etc, based solely on their location. I also think it would be good to see what plugins are being actively developed still vs which ones aren't. jmho, I don't want to upset anyone!
anyway, again, sorry to pull your thread off topic TT!