VST Plugins Installation and Usage

Hello,

I am curious to know how many SAC users - or SAW users for that matter, store the VST plugins in the "root" of the VST_PlugIns folder?

As this is the procedure that I used with other software, I initially did the same with SAC - until I learnt what I consider to be a better method.

So, have a look-see: VST Plugins Installation and Usage

Again, I am curious to know how many users store the VST plugins in the "root" of the VST_PlugIns folder? Okay!

PS: This procedure does work for Native plugins - so I would recommend not "tampering" with those?

[QUOTE=mr_es335;216569]Hello,

I am curious to know how many SAC users - or SAW users for that matter, store the VST plugins in the "root" of the VST_PlugIns folder?
/QUOTE]I install them in the VST_PlugIns folder Dell. What are the benefits of using the ini file approach?

Bruce,

Download the article and see...

Bear in mind, boys, that the main benefit of the INI approach to VSTs in SAW is that you can allow the plugins to install their DLLs where their developers intended, which is often critical to whether or not they'll work right in the DAW host. If there are additional benefits, great. :cool:

Dave,

Quote:

---

Bear in mind, boys, that the main benefit of the INI approach to VSTs in SAW is that you can allow the plugins to install their DLLs where their developers intended, which is often critical to whether or not they'll work right in the DAW host.

---

... This being said, over the years I have tested over 300 plugins and all of this plugins I have been able to store in the VST_PlugIns folder. Some plugins even allow for the redirection of other folders via registry tweaks - of which I place in the VST_Presets folder - though may not appropriately so.

Quote:

---

If there are additional benefits, great. :cool:

---

... If you read the above article - you will discover that there are!

Quote:

---

Originally Posted by mr_es335

If you read the above article - you will discover that there are!

---

I did read your paper. I'd be interested to see timings of opening SAW in the different circumstances, empirical data. I find it hard to believe that redirecting via INI files would be faster.

Dave,

Quote:

---

Originally Posted by Dave Labrecque

I did read your paper.

---

... Are you sure you read it?

With a plugin stored in the root of the VST_PlugIns folder a dialog appears. However, when that same plugin is stored in a subfolder of the VST_PlugIns folder - the dialog does not appear. As I noted, could we not assume then that SAC peeks at the VST_PlugIns folder to discover what .dlls are located in that folder. This must be the case as SAC does indeed launch much quicker.

This is not difficult for you to test for yourself. Install a demo version, pop a plugin in the VST_PlugIns folder - and see what happens. Then move that plugin into a subfolder and then see what happens.

Being "anul-ly" organized, I prefer to create folders based on the type of plugin and then have the plugins of that type stored in their respective folders.

Each to their own - I know!

Quote:

---

Originally Posted by mr_es335

Dave,
... Are you sure you read it?

With a plugin stored in the root of the VST_PlugIns folder a dialog appears. However, when that same plugin is stored in a subfolder of the VST_PlugIns folder - the dialog does not appear. As I noted, could we not assume then that SAC peeks at the VST_PlugIns folder to discover what .dlls are located in that folder. This must be the case as SAC does indeed launch much quicker.

This is not difficult for you to test for yourself. Install a demo version, pop a plugin in the VST_PlugIns folder - and see what happens. Then move that plugin into a subfolder and then see what happens.

Being "anul-ly" organized, I prefer to create folders based on the type of plugin and then have the plugins of that type stored in their respective folders.

Each to their own - I know!

---

Yes, I read it.

Sorry, Dell -- I'm not sure I know what your point is, here. Of course SAW and SAC look in their VST_PlugIns folders upon launch. That's where they keep their VST plugins. Are you sure SAC opens faster with the INI files in place of the DLLs?

OK, then here's my guess as to what's going on (total amateur guess): upon launch SAW/SAC looks in its VST_PlugIns folder for any DLLs, and when it sees none, it skips the whole bit where it loads them, cuz they're not there, and so there's no prompt about loading them. It does, however, "load" the pointer info contained in the INI files, which is much quicker a thing to do. This populates the FX list box, which is a simple matter. Then, when you go to patch a plug-in, SAC/SAW use the pointer info to actually load and patch the needed plug-in. So, in theory, patching may take longer using the INI route than using the native route. Albeit inperceptively longer for a single plug-in.

So that's my guess. :rolleyes:

Hello,

Here is a very poor video sample - using my office computer. The loading is much quick on my live rig system.

00:00-00:05, without folder, 00:006-00:10, with folder ... [click_me]

Hi Dell;

Apart from saving some loading time, There already a solution provided with Sac / Saw in that you can already organize your plugins! Click on the group button and you can rename and creating different groups and assign plugins to it, the advantage is that you can have a plugin assigned to multiple groups.
which is not possible following the named sub-directory method.

Appears Bob already provided a solution :rolleyes:

Cheers

Robert,

This entire post was focused on a single points - with two sub-points. The single point was the efficient loading time of the plug-ins. The other two points were, 2) the storing of all of the plugins in like folders within the VST_PLUGINS folder, and 3) plug-in organization.

I am well aware of the plug-in Group functionality of SAC and SAW - and have used that functionality in the past.

However, this Grouping functionality has nothing at all to do with how the plug-ins are initially organized. If .ini files are not being used, then the "Initializing VST Plug-Ins" dialog would then be invoked. This was the main point in providing this post.

This being said, using Bob's method would permit all plug-ins to be stored in a single folder within the VST_PLUGINS folder - using .ini files to point to those plug-ins.

Also, this posting really had nothing at all to do with finding a solution to anything - and I must admit that I dumb-founded to ascertain how this point could have been construed from my initial posting?

As I do not use a lot of plug-ins - an amp sim, a wavefile player, and two reverbs, I see no immediate benefits of using SAC's Group methodology.

Maybe I am not clearly understanding your point, Robert – and it would appear that you are not understanding mine.

Quote:

---

Originally Posted by mr_es335

Robert,

This entire post was focused on a single points - with two sub-points. The single point was the efficient loading time of the plug-ins. The other two points were, 2) the storing of all of the plugins in like folders within the VST_PLUGINS folder, and 3) plug-in organization.

I am well aware of the plug-in Group functionality of SAC and SAW - and have used that functionality in the past.

However, this Grouping functionality has nothing at all to do with how the plug-ins are initially organized. If .ini files are not being used, then the "Initializing VST Plug-Ins" dialog would then be invoked. This was the main point in providing this post.

This being said, using Bob's method would permit all plug-ins to be stored in a single folder within the VST_PLUGINS folder - using .ini files to point to those plug-ins.

Also, this posting really had nothing at all to do with finding a solution to anything - and I must admit that I dumb-founded to ascertain how this point could have been construed from my initial posting?

As I do not use a lot of plug-ins - an amp sim, a wavefile player, and two reverbs, I see no immediate benefits of using SAC's Group methodology.

Maybe I am not clearly understanding your point, Robert ***8211; and it would appear that you are not understanding mine.

---

Dell, I might suggest you'd be better off making these postings to your own blog instead of this forum. There, your tips and tricks would be organized into one collection and would make a much better reference for those who might benefit from your research and experience. A forum isn't really a good platform for this type of posting because forums are interactive. You can't control the dialog. Your message gets lost in the noise.

If you really are curious as you state in your OP, then post a survey. Allow people to respond and then count the votes.

I think you'll find the majority use mostly the standard method and only go to the ini method when a plugin requires it (to install and run correctly) or when it's more convenient to do so.

Quote:

---

Originally Posted by mr_es335

Dave,
... Are you sure you read it?

With a plugin stored in the root of the VST_PlugIns folder a dialog appears. However, when that same plugin is stored in a subfolder of the VST_PlugIns folder - the dialog does not appear. As I noted, could we not assume then that SAC peeks at the VST_PlugIns folder to discover what .dlls are located in that folder. This must be the case as SAC does indeed launch much quicker.

This is not difficult for you to test for yourself. Install a demo version, pop a plugin in the VST_PlugIns folder - and see what happens. Then move that plugin into a subfolder and then see what happens.

Being "anul-ly" organized, I prefer to create folders based on the type of plugin and then have the plugins of that type stored in their respective folders.

Each to their own - I know!

---

For the record I haven't clicked your links. Haven't read your article and I haven't watched your video. I have no interest in testing this myself.

You're making a point that SAC launches more quickly when it has no plugin dlls to initialize. This we already know.

You're also suggesting the ini method is beneficial because it allows the plugins to be organized in folders. This too we already know.

If I'm understanding correctly you're also suggesting SAC will launch more quickly if we use the ini method to install our plugins. I've never used the ini method to install a plugin because I've not needed to so I'm curious...

Have you tested both the ini method and the standard method with the exact same batch of plugins, and compared the load times? If the ini method is indeed faster, did you then load the plugins in an FX slot to see if they're slow on the first instantiation of a particular plugin?

I think you'll find there really isn't a 'free lunch'. The plugins need to be initialized at some point. :)

Quote:

---

Originally Posted by Naturally Digital

Have you tested both the ini method and the standard method with the exact same batch of plugins, and compared the load times? If the ini method is indeed faster, did you then load the plugins in an FX slot to see if they're slow on the first instantiation of a particular plugin?

I think you'll find there really isn't a 'free lunch'. The plugins need to be initialized at some point. :)

---

This is what I was trying to get at.

Good day,

May be we can get Bob to tell us what is the function or purpose of "Initializing VST Plug-Ins"?
* There is nothing that I could find in either the SAW 5.6 or SAC 4.3 manuals.